Operate edge rules without hiding application defects

A WAF inspects traffic before the application's full business context is available. It can reduce exposure to recognized patterns and provide temporary containment, but it cannot reliably infer every valid account relationship or repair a transaction race. Treat a virtual patch as a tracked mitigation with a linked application fix and retirement condition.

RASP observes execution inside a running application, while IAST uses instrumentation during testing to find defects. These locations change available context, deployment cost and failure behavior. Evaluate each against a concrete task rather than assuming that adding another category guarantees complete protection.

The synthetic rule model below, with invented rule names, keeps the exercise small; the next section shows the same pattern with the real OWASP CRS. R-A flags an apostrophe in any body field, while R-B flags the literal test marker BAD_TEST in any body field. A legitimate comment, O'Connor's booking, trips the simplistic R-A. Disabling all inspection on the route would also disable R-B and other controls. Excluding only R-A on the comment parameter preserves the rest of the modeled inspection.

Real CRS tuning requires the actual matched rule, target variable, transformation and anomaly score. One rule can inspect many parameters, and multiple matches may contribute to a blocking score. Capture a redacted reproducible legitimate request and compare narrowly scoped exclusions under the installed ruleset. The intended lesson is how to define scope and regression cases, not to recommend removing a named production rule without evidence.

The application must still use safe database APIs and enforce ownership. A WAF cannot infer that authenticated North user N may not cancel South user S’s booking when both requests are syntactically ordinary. Keep an application regression for that relationship even if the edge blocks known injection patterns. Track a temporary virtual patch with its owner, expiry, affected route and application repair.

Bots are the other half of edge work, and signatures rarely see them. In the exercise trace, 40,000 login attempts arrive in an hour from 9,800 residential addresses, none sending more than five, each with a different leaked username and password pair. Every request is well-formed, so no CRS rule matches, and a limit of 20 requests a minute per address never fires. This is OWASP OAT-008 credential stuffing. The controls that bite key on what the attacker reuses or targets, not on the address: failed logins per account and per username, a check of submitted passwords against known breached passwords, and phishing-resistant MFA or passkeys so a correct password is not enough. The MFA and login defense guide at /domains/identity-crypto/authentication/mfa-account-takeover/ covers those controls.

SYNTHETIC RULES, not production CRS identifiers
R-A: any ASCII apostrophe in any body field -> match
R-B: literal BAD_TEST in any body field -> match
Any non-excluded match blocks
Candidate exclusion: R-A only, path=/comments, parameter=comment
T1 /comments comment="O'Connor"
T2 /comments comment="BAD_TEST"
T3 /comments username="O'Connor"
T4 /profile comment="O'Connor"

With CRS 4.30 running on ModSecurity at paranoia level 1, a developer-forum comment, wrap it in <script> tags, posted to /comments was blocked with 403. The audit log named three matches on ARGS:comment (rules 941100, 941110 and 941160, all tagged attack-xss) for an anomaly score above the threshold of 5, which rule 949110 enforced. The exclusion below removes the XSS rules from that one parameter on that one route.

Tested with the same requests as the exercise: the legitimate comment passed; a SQL injection string in the same field, the same HTML in a username field and the same comment posted to /profile were all still blocked. A route-wide ctl:ruleEngine=Off also let the legitimate comment through, but it let the SQL injection and the username case through as well. Even the narrow exclusion has a cost: <script>alert(1)</script> in the comment field now passed the WAF, so the application must encode comments on output, and that test belongs in its regression suite.

# Developers post HTML snippets in the comment field of POST /comments. Stop the XSS rules
# from inspecting that one parameter on that one route; every other rule still applies to it,
# and every rule still applies to other parameters and routes.
SecRule REQUEST_FILENAME "@streq /comments" \
    "id:10000,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetByTag=attack-xss;ARGS:comment"

Start with a documented ruleset and a controlled observation phase. CRS groups rules into paranoia levels 1 to 4: level 1 aims for few false positives, and each higher level adds stricter rules that catch more attacks and more legitimate traffic. CRS 4 separates tx.blocking_paranoia_level from tx.detection_paranoia_level, so rules from a higher level can score and log without blocking while you tune. By default it blocks a request whose inbound anomaly score reaches 5 and a response whose score reaches 4. OWASP CRS uses rule matches and anomaly scoring; review which inputs triggered which rules instead of disabling a broad protection because a legitimate request was blocked. Keep a fixture for the legitimate request and one for the intended rejection when introducing an exclusion.

Limit exclusions to the necessary endpoint, parameter and rule where the implementation supports that scope. Verify limits and body inspection behavior for uploads, compressed data and large payloads. Understand what the edge does when inspection fails or a backend is unavailable. Monitor false-positive impact on real tasks, not only the percentage of traffic blocked.

Request smuggling arises when components disagree about request boundaries or framing; the guide at /domains/runtime/edge-defense/http-request-desynchronization/ shows how to test a chain. Use maintained proxy/server implementations, reject ambiguous framing and verify HTTP-version translation. Parser disagreement can undermine routing and WAF assumptions even when the visible request looks ordinary. Run such checks only in an isolated environment because shared connections and caches can affect other traffic.

Shared caches at the edge are a separate boundary: a cache that stores a personalized response under an incomplete key leaks it to the next user without any malicious request. The cache poisoning and deception guide at /domains/runtime/edge-defense/cache-poisoning-deception/ covers cache keys, private responses and how to test them; no WAF rule or threshold repairs a cache key.

Credential stuffing, scraping and inventory hoarding may use syntactically valid authenticated requests. Combine account/tenant/action limits, risk signals and suitable authentication controls with upstream capacity protection. Avoid permanent account lockouts that let an attacker deny access to a victim. Challenges need accessible alternatives and measured failure rates. Test recovery after the abusive pattern stops and keep application permission checks independent of the edge decision.

The OWASP Automated Threats to Web Applications project names 21 kinds of abuse, OAT-001 to OAT-021, which gives teams a shared vocabulary for which flow is attacked and which control applies. Most need application or identity controls rather than WAF signatures.

A request that exceeds the inspection body limit may be rejected, partially inspected or passed according to the product and configuration. Test that explicit failure mode. A dashboard showing inspected requests tells you little about traffic skipped by the inspection path.

Bot controls also need a defined unit of abuse. Account recovery, reservation holds and expensive search may require distinct per-account, tenant and action budgets. A challenge or IP limit that blocks a shared office network can harm legitimate users while leaving distributed abuse intact. Measure successful user tasks and recovery after pressure stops.

These outcomes belong to the synthetic model; the CRS test above produced the same pattern for T1 to T4 with real rules.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP CRS anomaly scoring
2. OWASP CRS false-positive tuning
3. RFC 9112 HTTP framing
4. RFC 9111 caching
5. OWASP Credential Stuffing Prevention
6. OWASP CRS: paranoia levels
7. OWASP CRS Docker images
8. OWASP Automated Threats to Web Applications

Reference information

Tags

Denial of service and resource limitsAccount takeoverAuthentication and sessionsWAFs and edge defenses

SDLC phase

Maintenance

Role

AppSec engineersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-2.4.1 · v5.0.0-6.3.1

Download this guide as Markdown

Continue exploring