Your to-do list

What to do about it

Every fix from every guide, in one place. Tick them off for your own app. Saved in this browser only.

0 of 126 done

The Front Door

Signs missing at the front door

Security headers

Add the headers once for every route: headers() in next.config.js, helmet() in Express, or your host’s headers file.
Start with Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY (or CSP frame-ancestors 'none') and a Referrer-Policy.
Add a Content-Security-Policy such as default-src 'self', then loosen only what your app really needs. Remove X-Powered-By.

Handing statements to anyone’s messenger

CORS

Keep a list of exact origins you trust (your own app and admin site) and only echo an origin if it is on the list.
Browsers refuse a wildcard together with cookies, so don’t “fix” that error by echoing any origin back. Never allow the null origin.
For public data that needs no login, * is fine. For anything tied to a user, use the allowlist.

A forged slip riding on a real badge

CSRF

Set session cookies with SameSite=Lax (or Strict), HttpOnly and Secure.
On every route that changes data, require a CSRF token, or check that Origin matches your own site.
Never change data on a GET request. Keep GETs read-only.

The greeter who walks you anywhere

Open redirect

Redirect only to relative paths on your own site, or to a fixed allowlist of known URLs.
Resolve the value with new URL(value, yourOrigin) and check the result’s origin equals yours. A simple starts-with check can be fooled.
If it fails the check, fall back to / and never to the supplied address.

The armored truck with one unlocked leg

Mixed content

Change every http:// resource URL to https://, or use relative paths on your own domain like /img/logo.png.
Add Strict-Transport-Security and consider the CSP directive upgrade-insecure-requests.
Check the browser console on each key page and fix any mixed content warnings before you ship.

Tamper-evident seals on vendor deliveries

Subresource Integrity (SRI)

Add integrity="sha384-…" and crossorigin="anonymous" to every third-party script and stylesheet tag (the host must allow cross-origin requests, which public CDNs do). Tools like srihash.org can generate the value.
Pin an exact version in the URL so the file doesn’t change underneath the fingerprint.
Better still, install the library with npm and serve it from your own domain. Remove third-party scripts you don’t need.

Blueprints left on the front counter

Exposed source maps

Turn off public source maps for production: in Next.js leave productionBrowserSourceMaps off, in Vite set build.sourcemap: false, in Create React App set GENERATE_SOURCEMAP=false.
If you need maps for debugging, upload them to your error tracker (such as Sentry) and delete them from the public output folder.
Never put secrets in front-end code, because even without a map, anyone can read what the browser downloads.

The ID Desk

An ID desk that gives too much away

Weak login checks

Return one generic message and status for every failed login, and keep response times similar.
Delete seeded and default accounts before launch, and force strong passwords for admins.
Add rate limits and lockouts so robbers cannot keep guessing (see Missing rate limits).

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

Password reset flaws

Send the token only by email, and respond with the same message for every request.
Generate long random tokens (use your auth provider’s built-in reset), expire them in minutes, and make them single-use.
Rate limit reset requests per email and per IP so nobody can flood inboxes or guess tokens.

Visitor badges left lying around

Session & token storage

Store sessions in HttpOnly, Secure, SameSite cookies set by the server, not in localStorage.
Keep access tokens short-lived (minutes) and use refresh tokens that you can revoke.
Add real logout that invalidates the session on the server, not just deletes it in the browser.

Forging a signed badge

JWT attacks

Verify with jwt.verify(), pass an explicit algorithms list, and reject alg: none.
Use a long random secret (32+ bytes) from an env var, or let your auth provider (Supabase, Firebase, Clerk) manage tokens.
Always set a short exp, and look up roles in your database instead of trusting the token’s claim.

Unlimited PIN guesses

Missing rate limits

Add a rate limiter (for example Upstash Ratelimit, express-rate-limit, or your provider’s built-in limits) to every auth route.
Limit by account as well as by IP, since robbers rotate IP addresses.
Add increasing delays or short temporary lockouts after repeated failures (permanent lockouts let robbers lock real customers out), plus alerts for spikes. Against credential stuffing, MFA and breached-password checks help most.

The Teller Window

Slips that give the teller orders

SQL & command injection

Use parameterized queries or your ORM’s safe methods. Never paste input into the query text, and give raw-query helpers parameters too. Escaping and blocklists are weaker backups.
For commands, avoid the shell entirely and pass arguments as a list. Check input against an allowlist of expected shapes.
Give the database user only the permissions it needs, and return generic errors instead of database messages.

Notes that boss around every reader

Cross-site scripting (XSS)

Show user text as text. Let React, Vue or your template engine escape it, and avoid raw HTML insertion.
If you must allow HTML (rich text), clean it with a sanitizer library such as DOMPurify.
Add a Content-Security-Policy header as a second layer, and keep session cookies HttpOnly so scripts cannot read them. That limits theft, but injected script can still act as the user.

Sending the teller to the back room

Server-side request forgery (SSRF)

Allow only specific hostnames you trust. Do not try to block bad ones.
Resolve the address yourself, reject private, loopback and link-local IPs, connect to the exact IP you checked (DNS can change), and re-check every redirect.
On AWS require IMDSv2 (a plain URL fetch can’t get a token) and give the server the least permissions possible, so stolen keys aren’t worth much.

The deposit slot that takes any parcel

Unsafe file uploads

Allow only the types you need, check the real content type, and set a maximum size.
Generate your own random filename and never use the user’s name or path.
Store files outside the web root (private bucket), serve them with a safe content type, and never serve user HTML or SVG from your own domain.

Account Access

Peeking at someone else’s account

IDOR / BOLA

On every request, check the record belongs to the current user before returning it.
Put the ownership check in the query itself: WHERE id = ? AND user_id = ?.
Use random IDs as a second layer, never as the only layer.

The service window nobody guards

Routes without authentication

Require a verified session at the top of every route and Server Action, and fail with 401 if there is none.
Make “protected” the default (a shared wrapper or middleware) and mark public routes explicitly.
Call your own routes with no token as a test; anything that returns data should be a surprise.

Walking into the manager’s office

Privilege escalation

Read the user’s role on the server for each request and require "admin" on every admin route.
Block users from editing role-like columns: keep roles in a table users cannot write, or use RLS plus column privileges or a trigger so only admins or the server can change them.
Keep admin-only tables and functions behind policies, not behind a hidden URL.

Scribbling in the margin of the form

Mass assignment

Pick the fields you allow by name on the server, never spread the whole request body into the database.
Validate bodies with a strict schema that rejects or strips unknown fields.
Move sensitive fields (roles, balances, plans) to server-only code paths or separate tables users cannot write to.

Handing in oddly shaped slips

Body & parameter fuzzing

Validate every request body with a strict schema (types, ranges, lengths) and return 400 for anything else.
Strip or reject __proto__, constructor and prototype keys before merging, and keep libraries like lodash up to date.
Treat amounts, quantities and prices as server-checked numbers: reject negatives and zero where they make no sense.

Drawers with no lock rule

Database access rules (RLS & Firebase rules)

Enable RLS on every table, and write policies that compare the row’s owner to auth.uid(). Keep the service_role key out of the browser: it bypasses RLS entirely.
In Firebase, replace open rules with owner checks like request.auth.uid == userId, and add validation on writes.
Test as a signed-out visitor and as a second user: you should not be able to read the first user’s data.

The Vault

The vault key in the old filing cabinet

Secrets in git history

Revoke and rotate any secret that was ever committed. Deleting it from code is not enough.
Keep secrets in environment variables or a secret manager, and add .env* to .gitignore.
Add a pre-commit or CI secret scanner (for example gitleaks), and optionally purge history with git filter-repo after rotating (rewriting history alone is not enough once pushed, since forks and clones keep copies).

The combination printed on the brochure

Secrets in the browser

Move every secret call into a server route, and let the browser call your route instead of the third party. Require login and add rate limits on that route so it is not an open relay for your key.
Use only keys designed to be public in the browser, and pair them with rules such as Supabase RLS or Firebase security rules.
If a secret ever reached the browser, rotate it immediately; deleting it from the next deploy is not enough.

The lock the vendor warned about

Vulnerable dependencies (CVEs)

Turn on Dependabot or Renovate and review its update PRs weekly.
Run npm audit (or pip-audit / the OWASP dependency-check Maven plugin) in CI and fail builds on high or critical findings.
Commit your lockfile, remove unused packages, and prefer well-maintained libraries. Flaws often hide in transitive dependencies, which npm audit and Dependabot also cover.

The Building

A prefab bank with the master key inside

Docker misconfigurations

Pin the base image (node:24.22.1-alpine) and add a non-root USER before CMD.
Keep secrets out of the image: pass them at runtime and add a .dockerignore for .env and .git. Deleting a secret in a later step does not remove it from earlier layers, so rotate any that were baked in.
Run the database as its own service, and publish only the app’s port.

A bank campus with every door open

Kubernetes misconfigurations

Set runAsNonRoot: true, privileged: false, allowPrivilegeEscalation: false, drop ALL capabilities, and avoid hostPath mounts.
Store credentials in Kubernetes Secrets (or an external secret manager) and reference them with secretKeyRef. Secrets are only base64-encoded, so restrict who can read them (RBAC) and enable encryption at rest.
Add CPU and memory limits, a default-deny NetworkPolicy (your network plugin must enforce it), and pinned image versions.

A blueprint that builds the same mistake everywhere

Infrastructure-as-code mistakes

Keep buckets private and add a public access block; share files with signed, expiring links.
Open firewall ports only to the specific addresses or services that need them, and grant narrow IAM permissions.
Keep secrets out of the files (use a secrets manager), keep Terraform state in a private, encrypted backend (it can hold secrets in plain text), and review changes before applying.

Maintenance crews that trust every instruction

Risky shell scripts

Download scripts to a file, review or verify them, then run them; never pipe from the internet into a shell.
Quote every variable ("$DIR"), guard destructive paths with "${DIR:?}" so an empty value stops the script, avoid eval, and start bash scripts with set -euo pipefail.
Read secrets from the environment or a secrets manager, and give scripts the minimum permissions.

The Blueprints

Doors nobody remembered to lock

Hidden endpoints

Require auth and role checks on the server for every route, with a default-deny wrapper or middleware, and still check inside sensitive handlers.
Delete retired API versions, test pages and debug routes from production builds.
List all your routes regularly and check each one has an owner and a lock. Treat “nobody knows about it” as no protection.

Files left in the lobby

Exposed files & risky HTTP methods

Keep secrets in your host’s environment settings, not in the deployed folder. Block dotfiles (except /.well-known) and backups from being served. Rotate any secret that was ever public.
Disable directory listing and delete old backups and build leftovers from public folders.
Allow only the HTTP methods each route needs, and turn off TRACE on your web server or proxy.

The service desk with everything on the menu

GraphQL exposure

Turn introspection off in production (Apollo has an option, Yoga a plugin) and disable “did you mean” field suggestions. This hides the map, it is not a lock.
Cap query depth, complexity and alias count, and limit or disable batching.
Check permissions inside every resolver, since hiding a field in the schema is not access control. Rate limit by query cost.

The staff manual in the lobby

Exposed API docs (OpenAPI)

Serve the docs UI and spec only in development, or put them behind login in production. Publish a trimmed public edition if customers need docs.
Remove admin and internal operations from any public spec, and set a global security scheme.
Remember the spec is not the protection. Enforce authentication and authorization in the server for every route.

The Rulebook

A ledger that was built wrong

Insecure database schemas

Hash passwords with a slow algorithm (bcrypt or argon2), encrypt other secrets at rest with keys kept outside the database, and never store raw tokens you can avoid keeping.
Add an owner or tenant column (user_id, tenant_id) to every table that holds someone’s data, and filter on it.
Keep roles in their own table rather than an isAdmin column on users, so a stray update can’t promote someone.

A guard who skips some corridors

Middleware coverage gaps

Make the matcher cover every path (pages and /api) and list the public exceptions explicitly.
Verify the token or session in the middleware; do not accept “a cookie is present” as proof.
In Express, register auth middleware before the routes it protects (public ones like login go separately). Never rely on middleware alone: check auth in sensitive handlers too, and keep Next.js patched (CVE-2025-29927, fixed in 12.3.5, 13.5.9, 14.2.25 and 15.2.3, let a crafted header skip middleware).

The Back Office

Two tellers, one balance, paid twice

Race conditions

Do the check and the change in one atomic statement: UPDATE … SET balance = balance - 50 WHERE balance >= 50.
Wrap multi-step changes in a transaction that also locks the row (SELECT … FOR UPDATE) or uses SERIALIZABLE isolation with retries. A plain transaction alone is not enough.
Add unique constraints and idempotency keys so a repeated coupon, order or refund can only happen once.

Rules that work but can be gamed

Business logic flaws

Look up prices, plans, roles and limits on the server, and treat everything in the request as a suggestion.
Enforce the order of steps on the server: keep a status (pending, paid, shipped) and allow only valid moves, such as granting access only after payment is confirmed.
Validate amounts (no negative, zero or absurdly large values), block self-transfers and reused coupons, and have an AI or a teammate review money flows.

The New Hire

A note slipped into the pile

Prompt injection

Give the AI only the access its task needs, with its own limited keys. Never your own all-powerful ones.
Require a human to approve risky actions, like sending data out, deleting or paying, before they happen.
Avoid putting private data, untrusted content and the ability to send data out in one assistant.

Handing the new hire the keys

Secrets leaked via AI tools

Keep secrets out of the repo and harder for the AI to read: list .env in .gitignore, and add deny rules in your tool (in Claude Code, "Read(./.env)" under permissions.deny, which covers its file tools and common shell commands like cat but not every script it could run).
Turn on secret scanning and push protection in your repository host (they are off by default for repositories, and private repos need GitHub Secret Protection), so pushes containing a recognised key pattern are blocked. People with write access can bypass a block, so treat it as a safety net, not the only guard.
If a key ever leaks, revoke and replace it right away. Deleting it from the code or history is not enough.

The supplier who doesn’t exist

Slopsquatting / hallucinated packages

Before installing anything the AI suggests, look it up on the registry: does it exist, who publishes it, how old is it, how many downloads (a low count is a warning sign, but a high one is not proof of safety), and does its repository really contain the same code.
Commit your lockfile and install from it (npm ci; for pip, pin exact versions with hashes and use --require-hashes).
Cut down install-time code: consider npm install --ignore-scripts when installing code you haven’t vetted (it applies to the whole install and can break packages that need a build step, and it does not stop a package’s code running once you import it), and use a private registry or allow-list so only approved names can be installed.

Signing what you haven’t read

Trusting unreviewed AI code

Ask for the security rules in your request: who may see what, queries built with placeholders, and no secret keys in browser code.
Read every change before it ships, and test as a second user and as a logged-out visitor.
Run automatic checks on every change: secret scanning, a dependency audit such as npm audit, and a security scanner or linter.

A master key for the new hire

Excessive agency / MCP risks

Give the agent only what the task needs: a separate account, read-only or narrowly scoped credentials, and no production keys.
Run it in a sandbox (a container, VM or separate account) and keep approval on for deletes, pushes and other destructive commands.
Treat each MCP server or plugin like any dependency: prefer known publishers, read what it does, and pin the version.