Application Security · WAF Testing

WAF Attack Simulation Dashboard

A ModSecurity + OWASP Core Rule Set firewall was placed in front of a test web app, then attacked with real SQL injection, XSS, path-traversal and command-injection payloads. This page shows what got blocked, what didn't, and why — read the KPI row first, then the category and detail views for specifics.

WAF Rule Engine: On
Sample data. These results are from a completed test run of the project — see the write-up for how to reproduce them with run_attacks.py.

At a glance

The four numbers that summarize whether the firewall is doing its job.

Block rate by attack category

Of the malicious payloads sent through the WAF, how many were stopped vs. how many reached the application in each category.

Blocked by WAF Reached the app

False-positive check

A WAF that blocks everything isn't useful — this confirms normal, benign traffic still gets through.

Every request, in detail

Filter by target or attack category, or click a column header to sort. This table is the full underlying data behind every chart above.

Target
Category
Target Category Payload HTTP status Outcome

What the WAF actually matched

An example excerpt from ModSecurity's audit log for one blocked request — this is illustrative; your own run writes real entries to ./audit.log.

--edcbdef1-A--
[02/Aug/2026:14:12:03] YQ2x9AAAAA 172.19.0.1 51422 172.19.0.3 8080
--edcbdef1-B--
GET /rest/products/search?q=%27%20OR%20%271%27%3D%271 HTTP/1.1
Host: localhost:8080
--edcbdef1-H--
Message: Warning. detected SQLi using libinjection. [file "REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [id "942100"] [rev ""] [msg "SQL Injection Attack Detected via libinjection"] [severity "CRITICAL"]
Action: Intercepted (phase 2)
Total inbound anomaly score: 5 (threshold was 5) — request blocked