All guides

Walk through the bank

Each part of the bank is a different place a robber might try. Start anywhere. Stuck on a word? See the glossary.

The Front Door

7 guides

In a bank: Doors, windows and signs that decide who can walk in and what customers can see from the street.
In your app: Browser protections: headers, cross-site rules, redirects and what your pages expose.

Signs missing at the front door

Short instructions your server sends with every page that tell the browser what is and isn’t allowed. Without them, the browser falls back to loose defaults.

Security headersInteractive

Handing statements to anyone’s messenger

Browsers ask your server which other websites may read its answers. A wildcard or lazy setting says yes to everyone, including attackers.

CORSInteractive

A forged slip riding on a real badge

A malicious page makes your logged-in visitor’s browser send a request they never meant to make, and your server obeys because the cookie is valid.

CSRFInteractive

The greeter who walks you anywhere

A link on your trusted domain that forwards visitors wherever a parameter says, which lets attackers send them to a fake copy of your site.

Open redirectInteractive

The armored truck with one unlocked leg

An HTTPS page that loads parts over plain HTTP. Browsers now block or upgrade most, but anything that slips through can be swapped by anyone on the network.

Mixed contentInteractive

Tamper-evident seals on vendor deliveries

A fingerprint you add to script and style tags from other sites, so the browser rejects a file that has been swapped.

Subresource Integrity (SRI)Interactive

Blueprints left on the front counter

Source map files turn your scrambled public code back into the original readable source. If they are public, anyone can read it.

Exposed source mapsInteractive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The ID Desk

5 guides

In a bank: Where staff check who you are, issue a visitor badge and decide how long it stays valid.
In your app: Login, sessions, tokens, password resets and rate limits.

An ID desk that gives too much away

A login that reveals which accounts exist, or accepts default logins like admin/admin, hands robbers the first half of a break-in.

Weak login checksInteractive

The “I lost my key” process that opens the door for anyone

If a reset link is handed to the person asking, instead of only mailed to the owner, anyone can take over any account.

Password reset flawsInteractive

Visitor badges left lying around

A login badge stored where scripts can read it, with no flags and no expiry, can be copied and used for as long as the thief likes.

Session & token storageInteractive

Forging a signed badge

A signed login token is only trustworthy if the server insists on a real signature, a strong secret and a fixed algorithm.

JWT attacksInteractive

Unlimited PIN guesses

Without a limit on attempts, a robber can try thousands of passwords a minute until one works.

Missing rate limitsInteractive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The Teller Window

4 guides

In a bank: Where customers hand over slips and a teller carries out what is written on them.
In your app: Everything users type or send that your server acts on: queries, commands, URLs and uploads.

Slips that give the teller orders

Typing instructions into a form field that your server then runs as if you had written them yourself.

SQL & command injectionInteractive

Notes that boss around every reader

A note on a public page that secretly contains instructions every visitor’s browser follows, such as stealing their login.

Cross-site scripting (XSS)Interactive

Sending the teller to the back room

Tricking your server into fetching an address of your choice, such as internal services that only the server itself can reach.

Server-side request forgery (SSRF)Interactive

The deposit slot that takes any parcel

Letting users upload any file with any name, so a disguised script, a giant file or a tricky filename lands somewhere dangerous.

Unsafe file uploadsInteractive

Want the scanner’s view of this area? Open the isitsecure overview ↗

Account Access

6 guides

In a bank: The rules about which accounts each person may open, and what each role may do.
In your app: Authorization: who can see or change which records.

Peeking at someone else’s account

Changing a number in a URL to read another customer’s data, because the app never checks whose it is.

IDOR / BOLAInteractive

The service window nobody guards

An API route that does its job for anyone who asks, because nobody ever checks who is calling.

Routes without authenticationInteractive

Walking into the manager’s office

A regular user gains admin powers because the app believes the role the client claims instead of the one on record.

Privilege escalationInteractive

Scribbling in the margin of the form

The server saves every field the client sends, so a user can set fields like role or balance that the form never offered.

Mass assignmentInteractive

Handing in oddly shaped slips

Sending negative numbers, wrong types and hidden nested keys to see what breaks when the server trusts the shape of its input.

Body & parameter fuzzingInteractive

Drawers with no lock rule

With row-level security off or too loose, anyone holding your public key can read or change any row straight from the browser.

Database access rules (RLS & Firebase rules)Interactive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The Vault

3 guides

In a bank: Where the cash, keys and spare codes are kept, and who ever had a copy.
In your app: Secrets, API keys and the third-party code you depend on.

The vault key in the old filing cabinet

Deleting a leaked key from your code does not remove it from git history, where anyone with the repo can still find it.

Secrets in git historyInteractive

The combination printed on the brochure

Everything shipped to the browser can be read by anyone, so secret keys placed in front-end code are public keys.

Secrets in the browserInteractive

The lock the vendor warned about

The libraries you install can contain known flaws; if you never update them, robbers use the public advisory as a how-to.

Vulnerable dependencies (CVEs)Interactive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The Building

4 guides

In a bank: The walls, locks and wiring of the bank itself, and the maintenance crew who run it.
In your app: Containers, clusters, cloud config and deployment scripts.

A prefab bank with the master key inside

A container image that runs as root, has secrets baked in, or uses a moving “latest” base can hand an attacker everything.

Docker misconfigurationsInteractive

A bank campus with every door open

Over-powered containers, open traffic between services and plain-text secrets let one break-in spread across the whole cluster.

Kubernetes misconfigurationsInteractive

A blueprint that builds the same mistake everywhere

A public storage bucket or wide-open firewall written into Terraform gets stamped into every environment you create.

Infrastructure-as-code mistakesInteractive

Maintenance crews that trust every instruction

Scripts that run with full access and obey whatever they download, or whatever a blank variable turns into, can wreck or hand over your server.

Risky shell scriptsInteractive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The Blueprints

4 guides

In a bank: Floor plans and staff directories that tell a robber where everything is.
In your app: Your attack surface: endpoints, hidden routes, API schemas and debug interfaces.

Doors nobody remembered to lock

Admin pages, old API versions and test routes that aren’t linked anywhere, but are easy to find and often forgotten.

Hidden endpointsInteractive

Files left in the lobby

Secret files such as .env or backups sitting in public folders, and server windows that accept requests they were never meant to.

Exposed files & risky HTTP methodsInteractive

The service desk with everything on the menu

A flexible API that will describe itself to strangers, accept thousands of requests in one go and follow requests nested forever.

GraphQL exposureInteractive

The staff manual in the lobby

Leaving your full API documentation public, including internal and admin operations, which hands attackers a ready-made map.

Exposed API docs (OpenAPI)Interactive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The Rulebook

2 guides

In a bank: The written policies every branch must follow, and the guards who enforce them.
In your app: Database schemas, security rules and middleware that enforce policy for every request.

A ledger that was built wrong

Sensitive columns stored in plain text and missing owner or tenant columns mean no rule can protect the data, even a good one.

Insecure database schemasInteractive

A guard who skips some corridors

Your login check protects some paths but not others, so attackers walk through the corridors the guard was never told about.

Middleware coverage gapsInteractive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The Back Office

2 guides

In a bank: The processes behind the counter, where timing and business rules can be gamed.
In your app: Business logic: races, limits and flows that work as coded but not as intended.

Two tellers, one balance, paid twice

When two requests arrive at the same moment, each checks the balance before the other writes it down, and both succeed.

Race conditionsInteractive

Rules that work but can be gamed

Every line of code does what it says, yet the process can be abused: customer-set prices, negative amounts, skipped steps.

Business logic flawsInteractive

Want the scanner’s view of this area? Open the isitsecure overview ↗

The New Hire

5 guides

In a bank: A fast, eager assistant who reads everything on the desk, follows what it says, and has been handed keys on day one.
In your app: AI coding tools and agents: what they read, what they write, what you let them touch.

A note slipped into the pile

Instructions hidden in a page, email or issue that an AI reads. It cannot tell your orders from a stranger’s, so it may obey both.

Prompt injectionInteractive

Handing the new hire the keys

API keys and passwords slip out when they are pasted into a chat, written into generated code, or swept into a commit by an agent.

Secrets leaked via AI toolsInteractive

The supplier who doesn’t exist

AI tools sometimes suggest software packages that do not exist. An attacker can register that name with malware, and the next install fetches it.

Slopsquatting / hallucinated packagesInteractive

Signing what you haven’t read

AI-written code can look right and run fine while quietly skipping the checks that keep strangers out. Here is how to catch that.

Trusting unreviewed AI codeInteractive

A master key for the new hire

An AI agent acts with the access you give it. Hand it shell, files or a database, or install a stranger’s plugin, and one hidden note can do real damage.

Excessive agency / MCP risksInteractive