Fastly Ngwaf

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

Run the bundled assessment script (requires jq and FASTLY_API_KEY):

./scripts/assess_ngwaf_rules.sh

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:

export FASTLY_API_TOKEN="$FASTLY_API_KEY"

Audit Workflow

1. List workspaces — verify the account has NGWAF workspaces
2. Fetch rules per workspace — retrieve each workspace's rule set
3. Validate critical signals — confirm required rules exist and are enabled
4. Flag gaps and search for uncovered endpoints — report missing/disabled rules
5. Check attack traffic against blocked traffic — confirm enabled rules are actually blocking

Step 1: List Workspaces

fastly ngwaf workspace list --json | jq -r '.data[].id'

If empty, NGWAF is not configured for this account.

Step 2: Fetch Rules for a Workspace

fastly ngwaf workspace rule list --workspace-id "$WORKSPACE_ID" --json

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:

fastly ngwaf workspace rule list --workspace-id "$WORKSPACE_ID" --json \
  | jq '[.data[] | select(.actions[].signal == "LOGINDISCOVERY") | {enabled, id}]'

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:

curl -s -H "Fastly-Key: $FASTLY_API_KEY" \
  "https://api.fastly.com/ngwaf/v1/workspaces/$WORKSPACE_ID/requests?limit=100&page=1&q=from%3A-30min%20method%3APOST%20path%3A~%22%2Alogin%2A%22" \
  | jq -r '.data[].path' | sort | uniq -c

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.

fastly ngwaf workspace time-series get --workspace-id "$WORKSPACE_ID" \
  --from=2026-08-01T00:00:00Z --to=2026-08-08T00:00:00Z \
  --metrics=requests_total,requests_attack,requests_total_blocked \
  --granularity=86400 --json \
  | jq -r '.data[] | "\(.timestamp)  total=\(.requests_total)  attack=\(.requests_attack)  blocked=\(.requests_total_blocked)"'

Across every workspace at once, grouped by workspace:

fastly ngwaf time-series list \
  --from=2026-08-01T00:00:00Z --to=2026-08-08T00:00:00Z \
  --metrics=requests_total,requests_attack \
  --granularity=86400 --dimensions=workspaces --json \
  | jq -r '.data[] | "\(.dimensions.workspace)  \(.dimensions.time)  \(.values | add)"'

The workspace-level subcommand is get, the account-level one is list. They differ in three ways that break audit scripts:

• Output shape. get returns flat objects keyed by metric with a timestamp. list nests them under dimensions and a values array, hence .values | add.
• Bucket size. The CLI only sends --granularity when passed; get then buckets hourly and list daily. Always pass it.
• Zeroes. get reports a quiet metric as 0. list drops it from values, 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:

### Workspace: abc123
  [LOGIN Rules]
  - LOGINDISCOVERY: ENABLED
  - LOGINATTEMPT: ENABLED
  - LOGINSUCCESS: ENABLED
  - LOGINFAILURE: ENABLED
  [CC Rules]
  - CC-VAL-ATTEMPT: ENABLED
  - CC-VAL-FAILURE: ENABLED
  - CC-VAL-SUCCESS: ENABLED
  [GC Rules]
  - GC-VAL-ATTEMPT: ENABLED
  - GC-VAL-FAILURE: ENABLED
  - GC-VAL-SUCCESS: ENABLED

Unhealthy workspace — missing or disabled rules require remediation:

### Workspace: def456
  [LOGIN Rules]
  - LOGINDISCOVERY: NOT CONFIGURED (Recommended: CRITICAL: Configure and enable this rule to discover unknown login endpoints)
  - LOGINATTEMPT: IS DISABLED (Recommended: Enable this rule)
  - LOGINSUCCESS: ENABLED
  - LOGINFAILURE: ENABLED
  -> LOGINATTEMPT is not enabled. Searching recent request logs for potential login paths...
  -> Found potential login paths in last 30 minutes:
       3 /api/v1/login
       1 /auth/signin

Error Handling

API References

• List Workspaces
• List Workspace Rules
• Time Series Metrics