Fastly Next-Gen WAF: A Safe Staged Enforcement Tutorial

Published

Jul 14, 2026

Updated

Jul 14, 2026

Reading time

12 min read

Fastly Next-Gen WAF can identify signals in requests and apply actions through policy and rule configuration. It is not a substitute for application authorization, input validation, origin protection, or incident response. Treat it as a security control that needs an owner, a tested scope, meaningful telemetry, and progressive enforcement.

Prerequisites

Prepare these before changing WAF behavior:

• Access to the Fastly Next-Gen WAF account or workspace that owns the target site, plus the service and application owners who can validate traffic.
• A current inventory of protected domains, paths, APIs, administrative endpoints, trusted integrations, deployment method, and origin bypass protections.
• A baseline for legitimate traffic: critical user journeys, API clients, partner IP ranges where justified, browser and bot traffic, expected methods, and normal response codes.
• A log destination or WAF event view with retention, access control, timestamps, request correlation, and a process for reviewing false positives.
• A named rollback operator and a short procedure for disabling or narrowing the candidate policy or rule.

Do not paste production credentials, session cookies, authentication headers, payment data, raw personal data, or live customer request bodies into a simulator, ticket, webhook, or chat. Use synthetic values and redact samples before sharing them.

Acme Shop scenario

Acme Shop is retiring POST /api/legacy-cart. Its application owner confirms no current client should call it. The WAF change is a narrowly scoped request rule for domain shop.example.test, path /api/legacy-cart, and method POST. It begins with the valid Add signal action and Sampled request logging, never as a broad user-agent or country block.

1. Establish policy scope before tuning detections

Create or select the site (workspace) and deployment that protects the intended traffic, following Fastly's Next-Gen WAF setup and configuration guidance. Verify the actual coverage with a controlled request and logs; a policy or workspace name alone does not prove that the hostname, traffic path, or integration is protected.

For each policy, record:

• The domains and environments it protects, and whether the policy is production, staging, or a limited canary.
• The deployment and request path, including which proxy or service forwards traffic to the WAF.
• The application owner, security owner, expected traffic patterns, and protected business flows.
• The change owner, review window, success metrics, and rollback action.

Keep development, staging, and production scopes separate. A permissive integration test exception or a noisy test endpoint should not become an unreviewed production exclusion. If the same application needs different treatment by hostname or route, define and verify the boundaries explicitly rather than assuming policy inheritance.

2. Understand signals and exclusion scope

Signals are labels Fastly uses for request properties associated with attacks, anomalies, bots, APIs, or other behavior. Signal detection and response are separate decisions. Fastly notes that some system signals, including CVE virtual patch, API, and account-takeover signals, must be enabled before they can be used. See Configuring system signals and Using system signals.

Start by observing a small, threat-relevant set of signals on a narrow route. Compare the signals against known-good journeys and expected automation. Record the request shape, signal, action, response, and business effect, not just the count.

Use a signal exclusion only to stop a specific, understood false positive from being tagged by a specific signal. It is not a broad allowlist and it may reduce future detection on every request matching its conditions. Fastly's signal exclusion rule guide explains that exclusions prevent matching requests from being tagged with the specified system signal.

Make exclusions as narrow as possible:

• Bind the exclusion to the single signal that produced the false positive.
• Scope it to stable attributes that express the known safe case, such as a tightly bounded path and method, rather than an entire site or broad user-agent string.
• Set an owner, reason, creation date, evidence link, and review date. Remove it when the application behavior or detection is corrected.
• Retest both the intended legitimate request and a nearby malicious or malformed request so the exception does not mask the threat class.

Fastly supports rule conditions based on request fields and, for signal exclusions, fields specific to the signal. Review the available fields and operators in Defining rule conditions before basing protection on an unreliable proxy header or a loosely matched path.

3. Add request rules for specific, explainable decisions

Use a request rule when you can state the condition, intended action, affected population, and rollback condition in one sentence. For example: “Add the ACME-LEGACY-CART-OBSERVED signal to requests to this deprecated endpoint while we confirm no client depends on it.” Do not begin with a global block based only on a user-agent, country, or an unvalidated header.

Fastly describes request rules as arbitrary request conditions paired with WAF actions. The actions and availability can differ by account features and deployment, so use the current Working with request rules and About rules documentation rather than copying a universal configuration recipe.

For each request rule:

1. Define the smallest route, method, domain, or signal combination that expresses the risk.
2. For observation, use the valid Add signal action and set Request logging to Sampled. Log is not a request-rule action; it is available only for site-level advanced rate limiting rules. Do not move directly to blocking based on theoretical matches.
3. Add a descriptive name and change record that includes the owner, ticket, expected volume, start time, end or review time, and exact rollback action.
4. Test positive, negative, and boundary cases. A rule that correctly catches one crafted request but matches a normal mobile client is not ready to enforce.
5. Review outcome logs with the application owner before broadening the condition or action.

Avoid rules that rely on a client-supplied identity header unless the trusted proxy boundary removes client values and sets that header itself. WAF decisions cannot repair an origin that still accepts direct, unauthenticated traffic.

For Acme Shop, the reviewed observation configuration is:

Conditions:       host = shop.example.test
                  path = /api/legacy-cart
                  method = POST
Action:           Add signal ACME-LEGACY-CART-OBSERVED
Request logging:  Sampled
Expiration:       end of the approved observation window

4. Use the simulator, then validate on real staged traffic

The Next-Gen WAF Simulator is valuable for checking the conditions and actions you expect without sending a sample to production. It can report whether a sample would block or log, the response code, added signals, and redactions. Fastly documents important limitations: the simulator does not support advanced rate limiting, deception, or geolocation, and Edge WAF deployments can differ from the simulator's reverse-proxy implementation. See Testing rule logic with the Simulator.

Build a small test matrix using sanitized samples:

• A normal request for each critical route, including expected headers and methods.
• A request that should match the candidate signal or rule.
• A near match that must remain allowed or logged as designed.
• An authenticated-flow shape represented with placeholder values, never a real token or cookie.
• A response sample when the condition or decision depends on response information.

Simulation is a logic check, not production proof. After it passes, deploy the candidate policy or rule to a limited environment or the narrowest safe production scope. Exercise real synthetic journeys and approved test clients, then compare WAF events with application and origin outcomes.

POST /api/legacy-cart HTTP/1.1
Host: shop.example.test
Content-Type: application/json

{"sku":"DEMO-MUG","quantity":1}

Action: add signal
Matched request rule: acme-retired-legacy-cart-observe
Signal added: ACME-LEGACY-CART-OBSERVED
Request logging: sampled
Response code: 204
Redactions: none

5. Make logging useful without collecting sensitive data

Log enough to answer what happened: timestamp, policy or rule identity, action, signal, hostname, normalized route, request ID, response status, deployment version, and a privacy-reviewed client network identifier where necessary. Correlate WAF events with edge, origin, and application telemetry using request or trace IDs.

Apply a data-minimization policy to WAF logs and downstream tools:

• Do not export Authorization headers, cookies, secrets, access tokens, raw form bodies, or sensitive query values.
• Avoid full URLs when query strings may contain personal or credential data; use a normalized route or approved redaction.
• Restrict access, retention, and onward webhook delivery to people and systems with a documented need.
• Treat false-positive review samples as sensitive operational data. Redact them before tickets, chat, vendor support, or incident reports.

Fastly's signal monitoring guidance describes how to inspect signal activity. Validate available request data, delivery latency, and redaction behavior in your account before writing an alert or investigation runbook around them.

API and webhook caveats

Automating policy changes or event delivery is useful, but an API token or webhook is a production security boundary. Do not assume every console capability, rule type, event field, or webhook delivery guarantee is available through every API or account plan.

• Use least-privileged, separately managed credentials and rotate them on a defined schedule. Never put long-lived tokens in VCL, browser code, source control, or webhook URLs.
• Make API-driven changes idempotent where the API supports it, record the resulting policy or rule identifiers, and keep a human-review gate for new blocking behavior.
• Authenticate webhook receivers, validate signatures or another documented authenticity mechanism where available, enforce TLS, and apply replay, rate, and payload-size protections.
• Design webhook consumers for duplicate, delayed, missing, and out-of-order events. A webhook alert must not be the only record of an enforcement action.
• Send only the minimized, approved event fields. A webhook endpoint is not an appropriate place for request bodies, credentials, or customer session data.

Confirm endpoint behavior, authentication, quotas, pagination, and versioning in Fastly's current Next-Gen WAF API reference. Test integrations in a non-production receiver before using them for automated response.

6. Advance enforcement in stages

Use explicit promotion criteria instead of a calendar-only rollout:

1. Inventory: verify policy coverage, critical routes, owners, telemetry, and the known-good baseline.
2. Detect: enable or observe relevant signals without introducing a new broad block. Investigate representative matches and false positives.
3. Simulate: test sanitized positive, negative, and boundary samples against candidate conditions.
4. Constrain: apply a candidate request rule or signal exclusion only to the smallest safe route, environment, or traffic population.
5. Enforce: block or challenge only after the observed match rate, legitimate-user impact, support signals, application errors, and rollback are acceptable to security and application owners.
6. Review: periodically remove temporary rules and exclusions, retest critical flows, and revise controls after application changes or incidents.

During every stage, monitor both security and product outcomes: matched and blocked requests, WAF errors, origin errors, login and checkout success, API completion, latency, support contacts, and bypass attempts. A falling attack count may mean the rule works, traffic changed, logging failed, or users were blocked before they reached the application.

Promote only after the application and security owners review a complete staging window: simulator result, candidate event count, sampled false positives, synthetic checkout result, and exact disable path. Enforce only the same domain, path, and method that were observed.

Rollback

For a suspected false-positive incident, optimize for restoring legitimate access while preserving evidence:

1. Stop expanding enforcement. Record the policy and rule identifiers, timestamps, request IDs, observed signals, action, affected routes, and client impact.
2. Disable or narrow only the candidate rule, action, or exclusion using the predefined rollback path. Do not broadly disable unrelated protections unless the incident requires it.
3. Re-run controlled legitimate and attack-like test cases, then verify application journeys, WAF events, origin traffic, and error rates.
4. Preserve sanitized evidence and update the change record. Correct the condition, scope, or application behavior before a new staged rollout.
5. If data may have been exposed, or a credential or origin path may be compromised, use the security incident process rather than treating the event as a WAF tuning issue.

Troubleshooting

Common pitfalls

• Treating a signal exclusion as an allowlist: It suppresses a specified signal for matches and can create a blind spot beyond the original false positive.
• Blocking before observing real traffic: Simulator success does not prove the behavior of real clients, proxy paths, geolocation, or rate limits.
• Using broad IP, country, user-agent, or path matches: These are easily overinclusive and can block customers, partners, crawlers, or internal systems.
• Trusting client-provided forwarding headers: Unless a trusted proxy sanitizes and sets them, clients can forge them.
• Treating logs or webhooks as harmless telemetry: They may contain sensitive request context and can be delayed, duplicated, or unavailable.
• Automating blocks without a rollback owner: A fast API change needs the same peer review, audit trail, and recovery path as a console change.
• Assuming the WAF protects an origin that is publicly reachable: Restrict and authenticate origin ingress separately.

Primary Fastly references

• Next-Gen WAF documentation
• Next-Gen WAF setup and configuration
• Configuring system signals
• Working with signal exclusion rules
• Working with request rules
• Defining rule conditions and Simulator limitations
• Monitoring signals
• Next-Gen WAF API reference

Related guides

• Fastly Compute Deployment
• Fastly Caching with VCL

Related reading

• Testing rule logic with the Simulator
• Next-Gen WAF setup and configuration
• Working with request rules
• Monitoring signals