Application Security System Design
By Imran M ·
· 10 min read
WAF in Modern Backends: Rules, Bypass Risks, and Defense in Depth
WAF in Modern Backends stops bad requests before your app. Learn rule design, false positives, logging, and how to fail closed when a rule set misses.
A WAF in Modern Backends is the filter that sees HTTP before your handlers do. It matters because a single missed check in app code can take a bad request all the way to the data store. You still need app checks. The edge filter is an extra gate, not a replacement.
If you treat the filter as a magic box, you will ship rules you do not understand. Then a false block will page you at night. Also, a gap in the rule set will look like safety when it is only quiet.
What a WAF is and why it fails
A web application firewall inspects HTTP and decides to allow, count, or block. It can match on path, header, query, cookie, and body. It can also rate limit a key such as IP or user id. Because it sits on the request path, a bad default becomes a user facing outage.
In my experience, the first failure is scope. Teams turn on a large managed rule set and call the job done. However, the set was built for a generic site, not for your API. As a result, valid JSON gets blocked, and odd paths slip through.
The second failure is trust. People assume the filter sees the same bytes the app sees. Still, a proxy may decode, compress, or cut the body before the app reads it. If those steps differ, the rule and the app disagree about the request.
Where it sits in the path
You can place the filter at a cloud edge, on an ingress proxy, or beside the app. First, pick the spot that sees every public request. Next, make sure private calls that skip that spot have their own checks. Otherwise a mesh hop can walk around the policy.
Edge placement stops junk before it spends app CPU. Meanwhile, a local filter can see identity headers that the edge does not have yet. Therefore many teams run a coarse edge policy and a tighter check near the service. That split is useful when you can name which rule lives where.
Architecture and how you roll it out
Think in three planes. The data plane matches rules on live traffic. The control plane stores rule versions and who changed them.
The observe plane stores samples, counts, and block reasons. If any plane is weak, you cannot explain a block to a caller.
A common mistake I have seen is to edit rules in a console with no review. Then you cannot roll back to a known file. Also, two regions drift.
Specifically, one region blocks a header that the other allows. You should store rules in git and ship them like app code.
Managed groups from a vendor cover common web bugs. Custom rules cover your paths, verbs, and body shapes. For example, you might allow POST only on /v1/orders and reject other verbs. You should keep custom rules small and named for the risk they close.
A safe rollout order
- Start in count mode on a copy of production traffic.
- Log the rule id, path, and a short body sample with secrets removed.
- Fix false blocks before you switch that rule to block.
- Block one rule group at a time, then watch error rate and latency.
- Keep a fast kill switch that returns the last good policy.
When you skip count mode, you learn about false blocks from angry users. After you have a week of counts, you can block with a clearer picture. Although the week feels slow, it is cheaper than a rollback during a sale.
Trade-offs you should name
Every WAF choice trades coverage for noise and cost. A strict allow list is strong when the API is small and stable. A broad block list is easier at first, and weaker as new paths appear. You should write down which model you use and why.
| Choice. | Use it when. | Main risk. | Cost shape. |
|---|---|---|---|
| Count only. | You are tuning a new rule. | Nothing is stopped yet. | Log volume grows. |
| Managed block group. | You want a known base set. | False blocks on valid API calls. | Vendor fee plus exceptions. |
| Path allow list. | Routes change rarely. | New routes fail until you add them. | Low, if the list stays short. |
| Rate based rule. | One client can overwhelm a route. | Shared IPs punish many users. | Cheap until you add keys. |
| Body inspection. | The risk is inside JSON or forms. | Large bodies add latency. | Billed per byte checked. |
If your API is public and stable, start with a path allow list plus a small managed set. If partners send odd but valid bodies, do not turn on full body match on day one. Instead, count those rules and add exclusions with a ticket id in the comment.
Negative rules try to spot bad patterns. Positive rules name what you allow. Positive rules fail closed when a new field appears.
Negative rules fail open when a new trick does not match the pattern. Therefore I prefer positive rules on state changing routes.
Pitfalls and failure modes
Rules miss when the match runs on raw bytes and the app runs on decoded text. For example, a path can be encoded more than once before your parser sees it. You should decode and normalize in a fixed order, then match. Also, document that order so the app uses the same steps.
Size limits are a quiet hole. Many filters inspect only the first chunk of a body. If your app reads the rest, a bad tail can pass.
Set the app to reject bodies larger than the filter inspects. Then the two limits match.
Exclusions rot. A team excludes a rule for one partner and never returns. Months later the exclusion covers a path that now takes user input.
Review exclusions every month. Remove any that lack an owner and an end date.
Fail open is a product choice
Some vendors fail open when the rule engine errors or times out. That keeps the site up, and it also lets traffic through with no check. For a login or payment route, fail closed is the safer default.
For a static health page, fail open may be fine. You should set this per route, not as one global switch you forget.
Health checks can trip rate rules. If a probe shares an IP with users, you may block real clients. Give probes a separate path and a rule above the rate rule. Still, do not let that path skip auth checks that the public path uses.
- Block rate spikes after a rule deploy.
- A rise in one rule id across many paths.
- Latency added at the filter, not in the app.
- Exclusions with no owner or no end date.
- Count mode left on for a rule you meant to enforce.
Bypass risk is real when you only match one header and ignore the body. A client can send the same field in a place you do not check. Close that gap by checking each source you parse, and by rejecting duplicate fields.
App code must still reject bad input. The filter is not the only line.
We once hit a bottleneck when a managed group scanned file uploads on a media route. The rule was right for HTML forms and wrong for large binary posts. We scoped body checks to JSON routes and left uploads on a size cap and a virus scan worker. Latency on that route dropped in the same hour.
A policy you can adapt
The snippet below is a stand in for an edge policy file. It limits the public API, turns the engine on, and points at a rule file you review in git. Change the rate to match a real client, not a lab toy. Also, keep the health path out of the tight limit so probes do not drain the burst.
# Public API edge. Fail closed if the rule file will not load.
# Inspect state changing routes. Do not scan large uploads here.
limit_req_zone $binary_remote_addr zone=api_waf:10m rate=20r/s;
server {
listen 443 ssl;
server_name api.example.internal;
location /healthz {
proxy_pass http://app;
}
location /v1/ {
modsecurity on;
modsecurity_rules_file /etc/waf/rules.conf;
limit_req zone=api_waf burst=40 nodelay;
proxy_pass http://app;
}
}
Pair this file with tests. Send a known good order and expect HTTP 200. Send a verb you do not use and expect a block.
Then alert if the block count is zero for a full day. A silent filter is often a filter that is off.
The AWS WAF developer guide shows how managed groups, custom rules, and labels fit one web ACL. The OWASP Core Rule Set is a common base when you run the engine yourself. Read both before you copy a rule you cannot explain.
Performance, scale, and cost
Inspection adds latency on every request you attach it to. Simple header and path checks are cheap. Body match and regex are not.
Therefore put the heavy rules on the few routes that need them. Leave static assets and health checks on a short path.
Cost usually follows three meters. You pay for requests evaluated, for bytes of body you scan, and for log volume you keep. A debug sample of every body will dominate the bill before the rule fee does.
Sample blocks at full rate and allows at a low rate. Keep full bodies only for a short window.
At scale, rule eval must stay in budget. Set a timeout and decide fail open or fail closed before the timeout hits. Also, watch CPU on the proxy when you add a group. If p99 rises after a rule publish, roll back first and tune second.
How this fits other controls
A WAF does not replace SQL injection prevention inside the query layer. It also does not replace XSS prevention when you render HTML. Those bugs live in your code. The filter only reduces how often a bad request arrives.
Use DDoS protection for floods that are too large for per request rules. Use CSRF protection for browser state changes that look like normal posts. The Azure Web Application Firewall overview is a useful second view of the same split between edge policy and app checks.
Capacity plan for rule growth. A policy with hundreds of regex rules will cost more CPU than a short allow list. When the list grows, split it by service. Give each team a quota on custom rules so one service cannot slow the shared edge.
Key Takeaways
- Put the filter where every public request is seen, and say so in the design.
- Run new rules in count mode until you know the false blocks.
- Normalize bytes the same way the app does, then match.
- Align body size limits so the app cannot read past what you inspect.
- Prefer allow lists on routes that change state.
- Store rules in git, with an owner and a fast rollback.
- Keep app layer checks even when the edge looks quiet.
FAQ
Does a WAF replace input checks in code?
No. The filter can drop many bad requests, and it can also miss one. Your handlers must still validate types, ranges, and auth. If you delete those checks, a path that skips the filter becomes a hole.
Should every rule start in block mode?
No. Start in count mode and read the samples. Switch to block only after false blocks are fixed or excluded with an end date. A global block on day one will hide the signal under noise.
What should you do when a vendor group blocks a valid call?
Exclude the smallest match you can, and name the route and the rule id. Open a ticket to remove the exclusion. Also, send the vendor a note if the group is wrong for API traffic. Do not turn the whole group off.
How do you know the filter is still on?
Alert if block and count totals stay at zero. Alert if the policy version in production is older than git. A health check that expects a block on a canary request is even better. If that canary gets HTTP 200, the engine is not enforcing.
A WAF in Modern Backends pays off when you can explain each rule, each exclusion, and the fail mode. Pick one public route this week. Put it in count mode, log the rule ids, and compare them with the checks already in the handler.
Next, write the allow list for verbs and paths on that route. Then set the body cap so the filter and the app agree. After that, block the rules that stayed clean. Leave the rest of the stack, from query binding to browser controls, in place.
Last updated on 09 September 2026.
