Project 92: WAF Security Engineering

Module: Module 10: Advanced Detection Engineering & Zero-Day Research  |  Level: Advanced  | 
Primary tool: ModSecurity + OWASP Core Rule Set (free, open-source)  |  Estimated time: 2–4 hours

Objective: Deploy a real web application firewall and tune it against your own deliberately vulnerable app.

Free lab environment

PortSwigger Web Security Academy + OWASP Juice Shop — https://portswigger.net/web-security and https://owasp.org/www-project-juice-shop/

PortSwigger’s Web Security Academy is 100% free (no paid tier required) and gives you an isolated, disposable vulnerable lab instance for every topic. For projects that need a full application to explore end-to-end, run OWASP Juice Shop locally with `docker run -p 3000:3000 bkimminich/juice-shop` (free, open-source, built by OWASP specifically to be broken).

Lab workflow

1. Open the lab environment (OWASP Juice Shop behind a local ModSecurity/CRS reverse proxy) and read the challenge description in full before touching anything.
2. Using ModSecurity + OWASP Core Rule Set (free, open-source), explore the application’s normal, intended behavior first — you cannot recognize an anomaly without a baseline.
3. Attempt to deploy a real web application firewall and tune it against your own deliberately vulnerable app, adjusting your input methodically (change one variable at a time) rather than guessing randomly.
4. The moment you get a signal the technique is working, stop and capture evidence before pushing further — over-testing a confirmed finding wastes time and risk for no additional proof.
5. Write the exact remediation for the specific code pattern involved — ‘sanitize input’ is not sufficient; name the actual fix (parameterization, encoding, allow-listing, etc.).
6. If the lab platform offers a ‘solved’ confirmation, capture that as supporting evidence alongside your own screenshots.

Evidence & screenshot requirements

Submit the following with your report (see this module’s practical assignment for exact upload details):

• a blocked-request log entry from ModSecurity for a payload that previously succeeded unprotected
• your written note on one rule you had to tune to avoid a false positive, and why

Expected deliverable

A concise lab-report entry containing: scope/target, exact commands or payloads used, your key
observation, the required screenshots above, and — where applicable — the specific remediation for what
you found. Vague answers (“sanitize input”, “use a firewall”) without naming the exact mechanism will not
receive full credit.

Safety & authorization

Only test the specific free lab target named above, or infrastructure you personally own. Do not target
third-party systems, real user accounts, or production services without explicit written authorization.
Never deploy anything from this project outside an isolated lab environment.