imperva-demo/docs/DEMO_RUNBOOK.md

Demo Runbook

Status: BUILT, not yet deployed to the GCP host. All four screens and three attack endpoints exist in backend/ and frontend/ and were functionally verified locally (backend via uvicorn + curl, frontend via vite dev + a browser, talking to each other through the same /api/* path Caddy proxies in prod — including confirming the XSS payload actually executes and the traversal payload actually reads a file outside boarding_passes/). Not yet shipped with ./deploy.sh — that must run from a real host terminal, not an AI coding-agent sandbox (see CLAUDE.md).

Goal of the demo: type an attack into a believable flight-booking UI, watch Imperva block it, then show the corresponding event in the Imperva portal. Three attacks, three distinct portal classifications.

Attack matrix

#	Attack	Endpoint	Sample payload	Expected Imperva portal classification
1	SQL Injection	/api/v1/users?q=	' OR '1'='1	SQL Injection
2	Reflected XSS	/api/v1/search?term=	<script>alert(1)</script>	Cross-Site Scripting (XSS)
3	Path Traversal	/api/v1/download?file=	../../../../etc/passwd	Illegal Resource Access / Directory Traversal
—	(bonus) Cred stuffing	/api/v1/login	repeated login attempts	Requires a custom rate policy, not a signature — not in core demo

Attacks 1–3 are blocked by Imperva's default signatures — no custom rules needed. The bonus is intentionally excluded from the core demo because it needs a rate policy configured in Imperva and doesn't produce a clean single-payload block (see DECISIONS.md D7).

Frontend screen → attack mapping

Each attack has a natural home in the UI so the demo looks like poking a real product:

• Passenger / admin lookup → SQLi search box (users?q=)
• Flight search results → XSS search field (search?term=)
• Boarding-pass download → path-traversal file param (download?file=)
• Login → existing endpoint, kept as the credential-stuffing bonus

Demo flow (target)

1. Show the app working normally (a legitimate search, a legitimate lookup).
2. For each of the three attacks: enter the payload in its screen → show the request is blocked by Imperva (block page / rejected response).
3. Switch to the Imperva portal security dashboard → show the three distinct event types logged, one per attack.
4. Reinforce the isolation point: the origin only accepts Imperva CIDRs, so these attacks cannot reach the app except through the WAF — which is why every one of them appears in the portal.

Pre-demo checklist

• https://flytoouter.space/ loads with Imperva's trusted edge cert.
• All three endpoints reachable through Imperva (legit requests return 200).
• Origin firewall confirmed Imperva-CIDR-only (allow-imperva-waf, tcp:443).
• DNS for flytoouter.space points at Imperva, not the raw origin IP.
• Portal logged-in and on the security events view, filtered to the demo site.

Notes on portal specifics

Exact event labels and menu paths vary by Imperva account/version. Confirm the live labels in your portal before presenting and update the classification column above to match what your account actually shows.