💼 Use Case
Most organisations don't have a complete map of their own API surface. Shadow APIs, forgotten endpoints, and undocumented routes are common. API Discovery gives you visibility before attackers find them first.
🎮 How to Demo
- Read through the discovered endpoint table below
- Point out that none of these were manually configured
- Click "Save to Schema →" to transition into Schema Validation
✅ Expected Outcome
All 7 demo API endpoints appear in the table — populated automatically from observed traffic. The "Unprotected" tags highlight endpoints that have no schema or auth rule yet — your attack surface.
| Method | Endpoint | First Seen | Requests (24h) | Auth | Status |
|---|---|---|---|---|---|
| POST | /api/auth/login | 2d ago | 4,821 | None | Discovered |
| GET | /api/products | 2d ago | 18,302 | None | Discovered |
| GET | /api/products/{id} | 2d ago | 9,104 | None | Discovered |
| POST | /api/cart | 2d ago | 3,456 | JWT | Unprotected |
| GET | /api/cart | 2d ago | 5,102 | JWT | Unprotected |
| POST | /api/orders | 2d ago | 1,233 | JWT | Unprotected |
| GET | /api/orders/{id} | 2d ago | 1,200 | JWT | Unprotected |
💼 Use Case
Attackers probe APIs with malformed payloads to find injection points, crash handlers, or unexpected behaviour. Schema Validation stops this class of attack entirely at the edge — your server never processes garbage input.
🎮 How to Demo
- Review the schema — note the field types
- Click "Auto-fill Valid" then Send — gets through
- Pick a violation from the dropdown
- Click "Auto-fill Invalid" then Send — CF blocks it
✅ Expected Outcome
Valid request → 200 OK, response from origin.
Invalid request → 400 blocked by CF. The Worker code is never executed.
POST /api/cart requestBody: required: true properties: product_id: type: integer # required minimum: 1 quantity: type: integer # required minimum: 1 maximum: 99 coupon: type: string # optional maxLength: 20
💼 Use Case
Without edge validation, every invalid token request hits your auth middleware, consumes server resources, and risks edge cases in your validation logic. CF handles all of this before your code runs.
🎮 How to Demo
- Click "Issue Demo Token" — Worker signs a real JWT
- Click "Send with Valid Token" — passes CF validation
- Click "Send Tampered Token" — CF detects signature mismatch
- Click "Send Expired Token" — CF detects expiry
- Click "Send No Token" — CF blocks unauthenticated request
✅ Expected Outcome
Valid → 200 OK.
Tampered / Expired / Missing → 403 Forbidden from CF edge. Origin never contacted.
sub claim. Requests that skip required steps are blocked at the edge — your Worker has zero sequence logic.💼 Use Case
Bots running credential stuffing, account takeover, or checkout abuse skip the normal browsing flow and jump straight to the target endpoint. Sequence Enforcement detects and blocks this pattern automatically.
🎮 How to Demo
- Make sure you've issued a JWT first (JWT tab)
- Click "Simulate Normal User" — follows all 4 steps in order
- Click "Simulate Bot Attack" — jumps straight to checkout
- Watch the flow diagram react in real time
✅ Expected Outcome
Normal user → all 4 steps light up green, order confirmed.
Bot → blocked at Step 3 with sequence violation. Steps 1 and 2 never occurred in this session.
💼 Use Case
Credential stuffing, scraping, inventory hoarding, and fake account creation all rely on automated traffic. Bot Management gives you the signal — WAF rules give you the action. Together they stop automation at the edge.
🎮 How to Demo
- Click "Check My Bot Score" — shows your real browser score (~99)
- Open a terminal and run the curl command shown — scores ~1
- Compare both scores side by side — explain why they differ
- Walk through the 3 WAF rule tiers
✅ Expected Outcome
Browser scores 70–99 (Human).
curl scores 1–5 (Bot) — detected by TLS fingerprint + User-Agent heuristics. The Balanced WAF rule blocks it.
Heuristics
33554817 (cURL - User-agent), 161371150
Run this in your terminal to see a real score of 1. CF scores curl low because its TLS fingerprint (JA3) is completely different from a browser — no JavaScript, no cookies, instantly recognisable handshake pattern.
(cf.bot_management.score lt 10)
and not (cf.bot_management.verified_bot)
(cf.bot_management.score lt 30)
and not (cf.bot_management.verified_bot)
(cf.bot_management.score lt 50)
and not (cf.bot_management.verified_bot)
💼 Use Case
IP-based limits break for users behind shared NAT or office proxies. Per-JWT-sub limits target the actual authenticated identity — no matter how many IPs they use or share.
🎮 How to Demo
- IP Test: Click "Run IP Test" — 12 requests, same IP. Watch 429 kick in.
- JWT Sub Test: Click "Run User A" then "Run User B" — each has their own separate limit despite sharing the same IP.
- Copy the curl commands and run them yourself to prove it's real.
✅ Expected Outcome
IP test: requests 1–10 return 200, requests 11–12 return 429.
JWT sub test: User A and User B each have independent counters — one hitting the limit doesn't affect the other.