Two practical scenarios

Run each attack bare to see it succeed, then place the app behind DP WAF and re-run to see it blocked / balanced.

Scenario 1 — Web attack chain WAF

Follow a full real-world breach: a SQL-injectable login, a role-based dashboard whose unsigned cookie can be edited to escalate to admin, and a public form carrying a stored XSS payload that steals the admin cookie for account takeover.

  1. Login → dashboard — user vs admin sidebar (edit cookie to escalate)
  2. Public feedback form — plant the XSS payload
  3. Attacker console — watch the admin cookie get stolen

✓ DP WAF blocks the SQLi and XSS requests before they ever reach the origin.

Scenario 2 — Capacity & load balancing Load Balancer

Participants open the site from their own real IPs. A single origin serves only 2 distinct IPs — the 3rd person sees a real HTTP 503 overload. Put several origins behind DP WAF (or the included balancer) and everyone gets in.

✓ DP WAF load balancing spreads traffic across many origins, and per-IP control (FortiGate) drops abusive IPs, so no single server is overwhelmed.

Live capacity test →

Simulated-IP version (one laptop, no class needed)