LEARN. PRACTICE. GROW.Separate observability stages
The previous lesson’s program also creates isolated JSON audit files. Examine projections and rawAudit in evidence.json. A rule can match, the callback can receive it and audit selection can still prevent writing. If no local record exists, the collector cannot deliver it. This sequence helps APS locate loss before changing components. Each case uses a fresh file, closes the server and writer before reading the result and removes the temporary directory at the end of the program run.
Reproduce version-specific selection
With RelevantOnly and filter ^5, the rule-free 200 control produces no record and the application 503 produces one. In executed Coraza 3.8.0, the pass,log,auditlog rule matching with 200 is also excluded by the filter. The consulted online description presents a different exception; pinned source and execution support the result taught here. Retain that discrepancy in the report. Do not turn the observation into a claim about all versions or change an expected result merely to make it agree with documentation.
Distinguish message and transaction
In the log,noauditlog case returning 503, a status-selected transaction exists, but that rule’s message does not appear in JSON. The callback still observes the match. Omitting an audit message therefore does not mean vetoing the entire transaction or disabling other diagnostic channels. To investigate, record version, mode, filter, rule action and actual output. The sample implements neither a remote collector nor a retention policy: those stages need separate validation on the chosen production path before operational acceptance can be established.
Look for data beyond the body
With On and ABCFHZ, the sample stores the synthetic body and invented Authorization. With AHZ, request.body still exists as an empty string and headers have no content. However, the rule message still contains DR-NOTE-ALPHA through logdata. The helper considers body content collected only when its value is nonempty; key existence is insufficient. Search for markers in messages and callbacks too. Removing B and C does not establish anonymity, absence of identifiers or absence of copies in other systems.
Balance data and diagnosis
The fixture’s AZ profile stores a transaction without the marker or rule messages. This reduces observed data but can remove context needed by support. Do not treat an empty file as an isolated objective. For a fictional funds-application change, agree required fields, who accesses them, retention and restoration of earlier configuration. Reproduce with invented values and inspect the sample before sharing it. If an investigation involves real data, follow the organization’s authorized process; this exercise defines no internal bank policy.
Conduct RUN handover in English
Use the proposed worksheet below in a simulation involving the manager, APS, security and network teams. Ask each owner to explain where they look for a matching 200 request, a rejection before the application and a handler-produced 503. Then confirm they can distinguish a selection filter from writing or delivery failure. Record retained fields and controls still to be executed at the gateway and collector. The exercise prepares a professional discussion but proves no performed workshop, specialist human review or production acceptance.
DR proposed WAF origin and audit handover
Status: teaching worksheet, not an executed human workshop.
No human workshop has been performed.
Scope: fictional service; synthetic data only.
Observed locally: Coraza 3.8.0, Go 1.27.1, HTTPS loopback.
Not covered: production gateway, trusted-proxy rewriting, remote collector,
full CRS, attack detection efficacy, production PKI or production acceptance.
1. Draw the request paths and identify each peer and header writer.
2. Record who may reach the origin directly and how that path is handled.
3. Rehearse absent, empty, literal and multi-hop origin inputs.
4. Correlate rule match, application call, response and local audit record.
5. Compare On / RelevantOnly, effective status filter and rule audit actions.
6. Search synthetic markers across body, headers, messages and callbacks.
7. Agree necessary diagnostic fields, access owners and retention policy.
8. Rehearse actual gateway and collector behavior with authorized test data.
9. Record rollback conditions and who can restore the previous configuration.
Suggested meeting prompts:
"Which address is the connection peer, and which is a claim?"
"Who is allowed to supply the value used by this policy?"
"Did this event match, get selected, get written and reach the collector?"
"What evidence do we lose when these fields are removed?"
"Which acceptance controls remain unexecuted?"
Evidence columns:
case | version | path | peer | declared origin | selected origin |
rule/mode | HTTP outcome | application calls | audit records |
retained fields | expected result | actual result | owner | follow-up
Acceptance requires evidence on the selected deployment path.
Local quantitative coverage does not establish independent specialist review.
A fictional change removes the dedicated JSON body, but the marker remains in the message. Acceptance must seek data across all relevant outputs.
Common pitfalls
Confusing no log with no detection; claiming noauditlog prevents every transaction; declaring anonymity solely by removing B and C.
Related topics: WAF architecture and coverage · Rate, origin, and clients · Logs, changes, and RUN handover
Inspect actual records from the tested version. Selection determines whether a transaction exists; parts and messages determine which data remains available for diagnosis.
Reference: Coraza transaction and audit source · BigSavant WAF 2026-09; selected AWS WAF and OWASP CRS operational concepts