Skip to main content

Command Palette

Search for a command to run...

A WAF rule is not authorization

Updated
•2 min read•View as Markdown
A
Practical lessons on auth, authorization, and access control.

A web application firewall can block known attack patterns, bad bots, and noisy paths. Authorization still decides whether this principal may perform this action on this object. Treating a green WAF verdict as a grant is how IDOR and BOLA keep sailing through secured” APIs.

The trap

You put the API behind a managed WAF (or ModSecurity) with OWASP CRS, rate rules, and geo filters. Handlers then assume “if the request reached me, access is fine” and load /orders/{id} or patch a user after a bare session check — with no authorize(actor, action, resource) against live ownership or membership.

That proves the request looked like traffic the WAF allows. It does not prove the caller may touch that order after a role change, a shared account, or a guessed id.

Why WAF rules fail as authz

  • Pattern matching ≠ permission. WAFs score payloads and paths. They do not know your tenant graph, document ACLs, or who left the workspace yesterday.
  • Allow means “not blocked,” not “entitled.” A clean request from an authenticated user can still be horizontal privilege escalation on the next id.
  • Rules lag product model changes. New endpoints, GraphQL fields, and admin overrides appear faster than custom WAF signatures.
  • Bypass lanes are common. Health checks, webhooks, partner IPs, and “internal” CIDR exceptions often skip the same rules customers hit — and still need object checks.

Tiny checklist

  1. After the WAF allows a request, do you still authorize the specific resource id — or only “any logged-in caller”?
  2. Can two users in the same org read each other’s objects by swapping path or body ids?
  3. When someone loses access in SSO or the app DB, does their next clean request still succeed?
  4. Do export, admin, and webhook paths use the same object checks as the public API?
  5. If you temporarily disable a WAF rule during an incident, what still enforces authorization?

Keep the WAF for abuse and exploit noise. Put authorization next to every sensitive read and write. A passed WAF rule is still not a permission check.