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:

NGWAF_SKILL_DIR=/absolute/path/to/fastly-ngwaf
bash "$NGWAF_SKILL_DIR/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:

Category	Required Signals
Login Protection	LOGINDISCOVERY, LOGINATTEMPT, LOGINSUCCESS, LOGINFAILURE
Credit Card Validation	CC-VAL-ATTEMPT, CC-VAL-FAILURE, CC-VAL-SUCCESS
Gift Card Validation	GC-VAL-ATTEMPT, GC-VAL-FAILURE, GC-VAL-SUCCESS

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

Error	Cause	Fix
FASTLY_API_KEY not set	Environment variable missing	Configure the key locally, outside chat
API call failed with status 403	Token lacks NGWAF scope	Verify token has global:read permission
No workspaces found	NGWAF not provisioned	Enable NGWAF on the account first
jq is not installed	Missing dependency	brew install jq or apt-get install -y jq
curl is not installed	Missing dependency	Install curl with the system package manager

API References

• List Workspaces
• List Workspace Rules
• Time Series Metrics