Firewall log analysis: from rule match to investigation
Preserve rule decisions, review false positives, and connect edge events to application evidence.
EDGE & RULE DECISIONS
Firewall log APIFrom a rule match to the full picture.
Read firewall and WAF events with their original source, rule, action, and request context intact.
{
"schema_version": "1.0",
"timestamp": "2026-09-21T09:41:02.184Z",
"severity": "WARN",
"event_id": "evt_demo_006",
"event_name": "firewall.rule.matched",
"service": "edge-firewall",
"attributes": {
"rule_id": "rule_demo_12",
"action": "block",
"source": "example-waf",
"request_ref": "req_demo_81"
}
}Synthetic fixture · nothing is sentDownload JSON ↗
DESIGN WITH INTENT
Keep the important distinctions.
Preserve the original
Keep source-specific actions alongside normalized categories.
Review false positives
Connect a reported block to its rule and configuration context.
Follow the request
Understand why blocked traffic may never reach the application.
THE EVENT CONTRACT
Fields with a reason to exist.
Network and application firewalls observe different units of activity. Document the source type and whether one request can generate several matching-rule events. Review collection scope and rule changes before attributing a change in counts to a change in traffic intent.
These fields illustrate a design pattern. Map them deliberately to your own schema, source, and destination.
| Field | What it means |
|---|---|
rule_id | The original rule reference when available. |
action | The source action, preserved before normalization. |
source | The component or product that made the decision. |
request_ref | A safe request identifier for correlation. |
A matching rule is evidence of a configured condition. It is not, on its own, proof of an attack or successful exploitation.
Technical reference: Cloudflare firewall event fields . Verify the version and settings used by your own implementation.
FIELD NOTES
Keep following the signal.
Web traffic logging: requests, routes, and real context
Build useful access logs while keeping observation points, latency boundaries, and visitor metrics distinct.
A security logging checklist for application teams
Capture access decisions and administrative actions with safe attribution, protected records, and clear outcomes.
ONE EVENT IS A GOOD START
Make your next log more useful.
Start with a clear schema. Keep the context that matters.