F5 AWAF - Advanced (formerly BIG-IP ASM - Application Security Manager) can define a security policy declaratively, as a JSON file you keep in source control and import into the BIG-IP. Because the policy is just a file, it fits naturally into a CI/CD (continuous integration) pipeline: pull it from Git, adjust it, and push it back to the device.

The envelope

The whole policy lives under a single policy object:

{ "policy": { "name": "my-app-policy", "template": { "name": "POLICY_TEMPLATE_FUNDAMENTAL" } } }

Two fields are mandatory: name and template. Everything else is optional.

Template first, then adjustments

The template is the starting point. F5 ships several, including POLICY_TEMPLATE_RAPID_DEPLOYMENT, POLICY_TEMPLATE_FUNDAMENTAL, POLICY_TEMPLATE_COMPREHENSIVE, and POLICY_TEMPLATE_API_SECURITY, each providing a different level of default protection. The template does the heavy lifting; the rest of the policy only describes what should differ from it.

On top of the template, F5 distinguishes two tuning layers. The adjustments section holds attributes that override or add to the template, such as server technologies, URLs, and parameters. The modifications are the granular, frequent tuning, such as reducing false positives or patching a specific vulnerability.

The rule that matters most: absent means default

Every adjustment is optional, and this is the single most important thing to understand when reading a declarative policy: if the policy does not include a section, that section's values come from the template. An absent section does not mean a protection is turned off. You cannot conclude that Data Guard is disabled just because data-guard is missing; you can only conclude it if the policy explicitly sets it off. Read a declarative policy as a delta on its template, never as the complete picture on its own.

The logical sections

The policy is organized into logical sections, each with a defined purpose: enforcement (enforcementMode, signature-settings, policy-builder), application context (applicationLanguage, caseInsensitive, server-technologies), the traffic surface (urls, parameters, filetypes, methods, headers, cookies), and protections (blocking-settings, data-guard, brute-force-attack-preventions, csrf-protection, and more).

F5 publishes the full schema, versioned from v16.0 through v17.5, on clouddocs. Reading a policy well means walking those sections in turn, always remembering that what is not written is inherited.

This series, in order

This article opens the series BIG-IP Advanced WAF. Its template-and-adjustments model is how every policy is read; the parts build the policy up in the order its decisions come into force (enforcement mode, signature staging, content parsing, layering), add the protections that look beyond one request (sessions, responses, evasion, bots, floods), then turn to operating it: false positives, the triage of a block, and the learning mode an attacker can steer. They end with the two newest protocol questions: and the .

  1. Blocking vs Transparent: What Advanced WAF Enforcement Mode Really Does. Whether the policy protects or merely watches: what blocking and transparent modes actually do to a violation.
  2. Signature Staging and the Enforcement Readiness Period. A new signature matches and logs without blocking until it has been reviewed and the readiness period has passed.
  3. Advanced WAF Content Profiles: Parsing JSON, XML, GraphQL, and GWT Safely. How JSON, XML, and GWT payloads are parsed, so signatures apply to fields and structure is enforced.
  4. Nested Policies in Advanced WAF: Parent/Child Inheritance and Policy Microservices. Parent and child policies with mandatory inheritance, and policy microservices: two ways to layer instead of one flat policy.
  5. Advanced WAF Session Tracking: Finding and Stopping the Client Behind the Requests. Identifying the user, session, device or address behind a stream of requests, and acting on that identity.
  6. Data Guard: Masking Sensitive Data in Responses. The response-side protection that masks card numbers and other sensitive patterns before they leave.
  7. Evasion Techniques: How Advanced WAF Normalizes Around Attacker Encoding. Unusual encodings that hide a payload from a signature, and the evasion sub-violations that normalise around them.
  8. Client-Side Signals and Challenges: How Advanced WAF Tells a Browser from a Bot. The injected JavaScript, the integrity check and the capability probes that tell a real browser from automation.
  9. L7 Behavioral DoS (BaDoS): How Advanced WAF Learns Normal and Mitigates the Rest. The machine-learning defence against application-layer floods: a learned baseline, server stress, and signatures generated on the fly.
  10. Handling False Positives in Advanced WAF: Triage by Rating, Then Tune with Scope. Legitimate traffic that trips the policy: triage by violation rating first, then tune with the narrowest scope.
  11. Why AWAF Blocked It, in the Order That Answers Fastest. Four questions in the order that answers fastest: what was blocked, was it wrong, how far to trust the signature, what changed.
  12. Automatic Learning in Production: How an Attacker Poisons a WAF Policy. Automatic learning against untrusted traffic, and how an attacker gets a suggestion accepted into the policy.
  13. WAF Over QUIC: HTTP/3 Web Protection in BIG-IP 21.1. The same web protection, bot defence and flood protection extended to HTTP/3 virtual servers, and the limits that remain.
  14. QUERY Meets BIG-IP: LTM, iRules, and the Advanced WAF Verdict. The new QUERY method meets the BIG-IP: passed by the HTTP profile, blocked by the WAF as illegal until allowed.

Sources

The schema is published per BIG-IP version, so the range named above is visible in the table of contents rather than being a claim about it.