LEARN. PRACTICE. GROW.Locate blocking in the request lifecycle
The same 403 can represent different moments. Rule 5101 blocks the request before the handler; rule 5201 looks for marker DR-RESPONSE in the body produced by the application during phase 4. In the second case, applicationCalls and syntheticEffects equal one before the client receives 403. The counter is only fixture memory, with no database or financial operation. It makes ordering visible. When diagnosing a real case, correlate phase with application events instead of inferring non-execution from the HTTP code.
Compare proposed and delivered responses
The handler proposes a text/plain body containing the marker and adds X-Lab-App. When the response rule interrupts, ResponseRecorder shows 403, an empty body and absence of that header. Evidence belongs to the tested Coraza 3.8.0 wrapper and the fixture’s simple write. It does not generalize to every connector or streaming response. Record the proposed response separately from the delivered outcome. This distinction helps explain why the application may have completed work without delivering the confirmation the client expected to receive.
Check access and MIME together
The fixture explicitly selects text/plain for response inspection. Keeping the marker and changing only MIME to application/octet-stream passes the response without a rule match. Disabling SecResponseBodyAccess also passes the text/plain case. These are different boundaries: making the body accessible and selecting its type. In a fictional export release, functional tests can pass while coverage changes. Include the types actually produced in the acceptance matrix and confirm intended policy with security and development without assuming every format is equivalent.
Distinguish an output limit from application failure
With response limit 64 and Reject, the handler produces 96 bytes and the wrapper returns 500. The handler was called and the counter remains incremented. The experiment contains neither an application crash nor request rejection before execution. This comparison helps APS avoid attributing every 500 to the backend. Correlate size, phase, configuration and outcome before deciding mitigation. Raising limits has buffering and capacity implications that this small fixture does not measure; representative service conditions still need to be rehearsed.
Recover without duplicating effects
In a fictional API that commits an instruction before responding, losing confirmation can leave the client unsure of the outcome. Blocking the response does not implement instruction rollback. Before replaying, look up status by identifier and apply the agreed idempotency and reconciliation contract. A new identifier can create another effect. In parallel, investigate the false positive with synthetic data and a bounded exception, retaining regression of paths that should remain protected. The lab only illustrates the sequence; it implements neither the transaction nor the recovery mechanism.
Practice go/no-go and shift handover
The worksheet below proposes a meeting between the technical manager, APS, security and development. Assign roles and ask RUN to explain an input 413 and an output 403 using the matrix. Fill in evidence, owner, abort criterion and recovery; explicitly identify tests still missing on the actual connector. The sentence “The HTTP wrapper checks passed; deployment-path validation remains open” appropriately communicates the limit in English. No human workshop has been performed to validate this worksheet. Course quantity targets do not replace that exercise or specialist review.
DR proposed WAF acceptance workshop
No human workshop has been performed.
Fictional exercise; not a BNP Paribas procedure.
Roles: technical PM, APS/RUN, application owner, security owner.
Scope: actual connector, pinned engine/rules, clients and application paths.
Case | Expected phase | Application called? | Client result | Evidence | Owner
Clean request | request + response | yes | expected content |... |...
Request marker | phase 2 | no | policy rejection |... |...
Oversize request | body limit | no with Reject | agreed error |... |...
Partial request | inspected prefix | may be yes | full body contract |... |...
Response marker | phase 4 | yes | blocked confirmation |... |...
Unselected MIME | response selection | yes | coverage gap to review |... |...
Oversize response | response limit | yes | agreed recovery |... |...
Decisions to record:
- Legitimate sizes, MIME types and supported clients.
- Controls covering complete content beyond inspection limits.
- Mode transition and false-positive regression evidence.
- Operation identifier, outcome lookup and replay contract.
- Abort criteria, rollback procedure and unresolved exceptions.
- RUN owner, escalation contact and next review date.
Suggested English update:
The HTTP wrapper checks passed; deployment-path validation remains open.
A response block can follow application execution. Confirm the operation
outcome before replaying and retain an owner for each unresolved case.
Local evidence: Coraza 3.8.0 WrapHandler and httptest objects.
Not executed: listener, TCP/TLS, production proxy, full CRS, AWS WAF,
representative load, streaming, real financial writes or human rehearsal.
A fictional API completes an instruction and its response is blocked. APS checks the ID, avoids uncontrolled replay and coordinates correction of the output rule.
Common pitfalls
Interpreting 403 as no effect, 500 as a crash, absent alerts as coverage or a MIME change as only presentation; replaying with a new ID without reconciliation.
Related topics: WAF architecture and coverage · Parsing and inspection limits · Logs, changes, and RUN handover
A WAF decision needs phase and integration context. Check what already executed, what was delivered and who resolves uncertain outcomes before closing the change.
Reference: Coraza HTTP response interceptor source · BigSavant WAF 2026-09; selected AWS WAF and OWASP CRS operational concepts