Fastly NGWAF Workspace Audit
Audits NGWAF workspaces to verify critical templated rules are configured and enabled. Use the fastly-cli skill to configure rules; this skill identifies gaps.
Quick Start
The bundled assessment requires Bash, curl, jq, network access to api.fastly.com, and a locally configured FASTLY_API_KEY with NGWAF read access.
The manual workflow also requires the fastly CLI.
Configure credentials in the user's local environment or CLI configuration.
Never ask the user to paste an API key into chat or print it in command output.
Set NGWAF_SKILL_DIR to the absolute directory containing this SKILL.md, using the installed skill location supplied by the client.
This is a variable you assign, not a client-provided environment variable.
Run the helper from the user's working directory:
For manual inspection or partial audits, work through the steps below with the fastly CLI.
The CLI ignores FASTLY_API_KEY. Its precedence is --token > FASTLY_API_TOKEN > fastly.toml profile > default
stored token. To reuse the script's credential:
Audit Workflow
- List workspaces — verify the account has NGWAF workspaces
- Fetch rules per workspace — retrieve each workspace's rule set
- Validate critical signals — confirm required rules exist and are enabled
- Flag gaps and search for uncovered endpoints — report missing/disabled rules
- Check attack traffic against blocked traffic — confirm enabled rules are actually blocking
Step 1: List Workspaces
If empty, NGWAF is not configured for this account.
Step 2: Fetch Rules for a Workspace
Both list commands return {"data": [...], "meta": {...}} and cap at 100 items with no flag to raise it. Check
.meta.total; above 100, fall back to GET /ngwaf/v1/workspaces?limit=200 or .../rules?limit=200.
rule list also takes --enabled and --action to filter server-side.
Step 3: Validate Critical Signals
For each workspace, verify these templated rules exist and enabled is true:
Check a specific signal:
Step 4: Search for Uncovered Login Endpoints
When LOGINATTEMPT is missing or disabled, search recent request logs for login-like traffic the WAF isn't protecting.
No CLI equivalent exists (there is no fastly ngwaf workspace requests), so use the API:
Step 5: Check Attack Traffic Against Blocked Traffic
A rule can be present and enabled and still block nothing when the workspace mode overrides it. requests_attack is
what NGWAF flagged; requests_total_blocked is what it stopped. Attacks above zero with nothing blocked means the
workspace is in log or off mode. Report it even when every rule checks out.
Across every workspace at once, grouped by workspace:
The workspace-level subcommand is get, the account-level one is list. They differ in three ways that break audit
scripts:
- Output shape.
getreturns flat objects keyed by metric with atimestamp.listnests them underdimensionsand avaluesarray, hence.values | add. - Bucket size. The CLI only sends
--granularitywhen passed;getthen buckets hourly andlistdaily. Always pass it. - Zeroes.
getreports a quiet metric as0.listdrops it fromvalues, and returns{"data":[],"meta":{"total":0}}when nothing recorded. A missing key means zero, not an error.
Read requests_total_blocked through get. A workspace that blocked nothing is the case this audit is looking for,
and list reports it as an absence.
--from and --metrics are required on both. Timestamps are RFC 3339, not the YYYY-MM-DD that fastly stats takes.
--metrics also accepts XSS, SQLI, HTTP404 and any custom signal name on the workspace, so a rule verified in
step 3 can be checked for real traffic by signal name. Query those through get.
Expected Output
Healthy workspace — all signals present and enabled:
Unhealthy workspace — missing or disabled rules require remediation:
