The Olivetta Bank Security Demo

A criminal posts a link that, when clicked, runs hidden code in your browser and steals your session.

The bank's homepage has a 'Find a branch' search box. The text you type is shown back to you on the same page - but the bank's developers forgot to escape it. An attacker can craft a URL containing JavaScript that runs in any victim's browser the moment they open the link.

Without protection: the script runs, an alert pops up, and a real attacker could steal cookies, log keystrokes, or impersonate the user. With Cloudflare WAF: 403 Forbidden at the edge.

An attacker tricks the database into returning data they shouldn't be able to see - or worse, dropping the whole table.

On the transactions page, the search box passes your text to the API in a query string. A naive backend would paste that text directly into a SQL query, letting an attacker change what the query does (e.g. dump every customer's transactions). Olivetta's backend happens to use parameterised queries, so the database itself is safe - but the request payload still matches SQLi signatures, which is what Cloudflare blocks.

Without protection: the malicious payload reaches the backend. With Cloudflare WAF: blocked before the application ever sees it.

An attacker calls the mobile API without logging in - or signs a fake token and pretends to be a customer.

Olivetta's API issues bearer tokens (JWTs) at login. A correctly-built API must verify every token's cryptographic signature on every request - missing tokens, expired tokens, and tokens signed with the wrong key must all be rejected. Cloudflare API Shield can perform this check at the edge using the public key published at /api/v1/.well-known/jwks.json, so forged requests never even reach the bank.

Without protection: the API only does a best-effort decode and trusts whoever holds a token-shaped string. With API Shield: forged or missing tokens are blocked at the edge with a clear violation reason in Security Events.

After logging in as yourself, you change a number in the URL and see somebody else's bank account.

Even with a perfectly valid token, GET /api/v1/accounts/{id} returns whatever account you ask for - the API never checks whether the account belongs to you. This is OWASP API Security Top 10 #1, and unlike XSS or SQL injection there is no signature for it: ownership rules live in the application's data model, not in the request payload. Cloudflare's recommended approach is layered: detect the bug, limit the blast radius, and fix the bug.

Without protection: any authenticated user can enumerate every account in the system. With Cloudflare: the endpoint is flagged in Security Overview, attacker sessions are listed with their IPs and JA4 fingerprints, the per-session rate limit cuts the enumeration off after ~20 requests/minute, and the dev team gets a precise pointer to the bug they need to fix.

An attacker hammers the login endpoint with millions of password guesses until one works.

POST /api/v1/login has no in-app rate limit. A botnet can fire thousands of guesses per second from many IPs. The 'admin / admin' demo account exists specifically so you can crack it quickly without a wordlist.

Without protection: thousands of login attempts succeed in seconds. With Rate Limiting: attempts beyond the threshold receive 429 Too Many Requests.

Internal endpoints that the bank forgot to remove from production. They were never meant to be public.

GET /api/v1/admin/debug and /api/v1/_internal/dbdump exist in the running Worker but are not declared in the public OpenAPI specification. In a real bank this is how customer data ends up in breaches: a developer leaves a debug route in production, an attacker fuzzes the URL space and finds it.

Without protection: full user table, including password hashes, returned to anyone who finds the URL. With Schema Validation: the endpoint is unreachable from the public internet.

The API returns full credit-card numbers and CVVs in plain text - a regulatory disaster.

GET /api/v1/cards intentionally returns full Primary Account Numbers (PAN) and CVVs in the response body. A real bank that does this fails PCI-DSS instantly. The point is that data-loss problems are often invisible to a code review: the endpoint looks innocent until you see what it returns.

Without protection: card data leaves the perimeter in plain text. With SDD: the response is flagged in Security Events, and the team can take the endpoint down or mask the data.