# AWAF policy-diff hole checker

> Paste a before and an after declarative WAF policy and it classifies every security-relevant change as a relaxation or a tightening, then answers the question that matters after tuning: did this open a hole? It flags relaxations that widen protection beyond a single entity apart from a properly-scoped single-entity allow. Runs entirely in your browser.

- Tool: https://ronutz.com/en/tools/f5-awaf-policy-diff
- Family: Security & WAF

---

## What it does

Paste two declarative security policies from F5 AWAF - Advanced WAF (formerly BIG-IP ASM - Application Security Manager) — a before and an after — and this compares them and classifies every security-relevant change as a relaxation or a tightening. It exists to answer the one question that matters after a tuning session: did this open a hole? It runs entirely in your browser and never contacts a BIG-IP.

## The distinction it draws

Not every relaxation is dangerous. Adding one allowed URL or parameter is a scoped, single-entity widening — the normal, correct way to clear a false positive. What deserves scrutiny is a relaxation that widens protection across the whole policy: switching enforcement to Transparent (which stops the entire policy blocking), disabling a violation or an evasion, turning Data Guard off, trusting a client-supplied X-Forwarded-For header, moving signatures to staging, or adding a wildcard entity that matches many URLs at once. The tool separates these policy-wide relaxations from the scoped ones, so a tuning diff does not quietly become a security regression.

## The verdict

If any policy-wide relaxation is present, the verdict is "opened a hole," and those changes are listed first, each with a concern level. If the widenings all stay entity-scoped, the verdict is "scoped changes only" — the safe zone for false-positive tuning. If every change increases protection, it is "tightened." It also lists the tightenings so you can see the full picture of what moved between the two policies.

## What it compares

It reads the security-relevant sections F5's declarative policy schema defines: enforcementMode, signature-settings staging, general.trustXff, data-guard, csrf-protection, the per-violation block flags under blocking-settings, the per-evasion enablement, and the URL, parameter, and file-type entity lists (where a name containing an asterisk is treated as a wildcard). These are the same field paths validated in the declarative-policy explainer and the evasion explainer.

## Grounding

The relaxation semantics follow F5's declarative WAF policy schema and the ASM documentation on how a Transparent policy and a cleared block flag stop enforcement, together with K70544352's rule that you relax only where a false positive occurred and scope it. Neither policy you paste is uploaded or leaves the page.

## Standards and references

- [F5 Advanced WAF declarative policy schema (enforcementMode, signature-settings, blocking-settings evasions/violations, data-guard, general.trustXff, entity arrays)](https://clouddocs.f5.com/products/waf-declarative-policy/)
- [F5 K70544352: Reducing false positive violations (relax only where a false positive occurred, and scope it)](https://my.f5.com/manage/s/article/K70544352)
- [F5 BIG-IP ASM: Working with Violations (a transparent policy and a disabled block flag stop enforcement)](https://techdocs.f5.com/en-us/bigip-17-5-0/big-ip-asm-implementations/working-with-violations.html)

## Related reading

- [How a BIG-IP Advanced WAF Declarative Policy Is Structured](https://ronutz.com/en/learn/awaf-declarative-policy-structure.md): A declarative WAF policy is a JSON file that describes a security policy as a set of adjustments on top of a base template. The key to reading one is the template-and-adjustments model: anything the policy does not mention keeps the template's default, so an absent section means default, not disabled.