Model
Reverse proxy WAF before the upstream application
Original WAFWiki lab
Generic Reverse Proxy WAF Workflow
A vendor-neutral WAF workflow diagram explaining client traffic, inspection, decision logic, allowed upstream traffic, blocked requests, and evidence capture.
- Client traffic
- Network entry point
- WAF inspection layer
- Policy decision
- Allowed request to origin
- Blocked request evidence
Lab status
- Product
- Generic reverse proxy WAF model
- Status
- Methodology
- Updated
- 2026-07-09
Evidence policy
WAFWiki separates verified smoke-test results from architecture diagrams and methodology notes. A smoke test proves one narrow local path; it does not claim full production readiness.
Environment
Reproducibility notes
Primary signal
Request headers, URI, parameters, body, response context, and rule/action logs
Validation method
Replay clean workflows, then safe lab payloads, then tune narrow exclusions
Commands
How this lab can be reproduced
Baseline a clean route
curl -w 'status=%{http_code} total=%{time_total}\n' -o /dev/null -s https://app.example/healthRecord the clean response and latency before enabling stronger rules.
Record WAF evidence
Query WAF logs for rule id, action, path, parameter, anomaly score, client context, and upstream status.Every block or alert should be explainable by rule, request field, and business impact.
Observed result
What this model helps validate
Decision quality
Evidence-led
A WAF decision should be traceable to a rule, score, action, and affected application route.
Rollout order
Observe before block
Normal workflows should be captured before prevention mode is enabled.
Diagram and method are vendor-neutral.
Use official documentation and current product logs for each concrete WAF.
Treat feature claims as hypotheses until tested against the same workload.Evidence context
Evidence is summarized from the recorded local run.
The public page shows safe excerpts from the recorded environment and results. Raw local logs remain in the project documentation for auditability.
Limitations
What this result does not prove
- Architecture diagrams do not replace hands-on validation.
- Real behavior depends on connector support, body parsing, TLS placement, rule set version, and upstream application behavior.
Related research