Security

A React SPA talks to a REST (Representational State Transfer) API on the same parent domain. You need to persist the user's session token across page reloads. Where should the access token live?

An httpOnly cookie cannot be read by JavaScript, so a single XSS (Cross-Site Scripting) bug cannot exfiltrate the JWT (JSON Web Token). localStorage is the classic wrong answer — it is trivially readable by any script that runs on the page, including injected ones from a compromised dependency.

Your app authenticates users with a session cookie and exposes POST /transfer to move money. A user reports that visiting a sketchy site while logged in caused a transfer. You confirm the cookie is Secure and httpOnly. What is the minimum fix?

A cookie alone proves the browser has a session but not that your own page initiated the request. A CSRF (Cross-Site Request Forgery) token bound to the session, or SameSite=Strict on the cookie, defeats cross-origin form submissions. CORS is the common wrong answer — it restricts what JS can read, not what a form post can send.

Users can write comments that other users see. Your template engine inserts the raw string into both an HTML body and a JavaScript onclick attribute. How should you defend against XSS (Cross-Site Scripting)?

The same string is dangerous in different ways depending on where it lands: HTML body needs entity encoding, attributes need attribute encoding, JS contexts need JS string escaping. Input sanitization is the tempting distractor but is brittle — encodings, mutation XSS, and new injection contexts routinely bypass blocklists.

A search endpoint receives a free-text query and your ORM exposes a raw() escape hatch. A teammate writes db.raw("SELECT * FROM items WHERE name LIKE '%" + q + "%'"). What is the correct fix?

Parameterized queries send the SQL (Structured Query Language) and the data on separate channels, so the input can never be parsed as code. Quote escaping is the classic wrong answer — Unicode tricks, backslash handling, and second-order injection all defeat hand-rolled escaping eventually.

GET /api/invoices/{id} returns an invoice. The handler looks up the invoice by id and returns it. Audit logs show user 42 successfully fetched invoice 9001, which belongs to user 77. What is missing?

This is a textbook BOLA (Broken Object Level Authorization) / IDOR (Insecure Direct Object Reference): authentication confirms who the caller is, but the handler never checks that the caller is allowed to see that specific object. UUIDs are the seductive wrong answer — they make guessing harder but ids leak through referrers, screenshots, and shared links, so they are obscurity, not authorization.

Your service runs on an EC2 instance and needs to read objects from S3. A junior dev plans to bake AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY into the container image as environment variables. What should you do instead?

Instance profiles (IAM (Identity and Access Management)) and IRSA on EKS deliver rotating, short-lived credentials via the metadata service — the SDK picks them up automatically and there is nothing to leak. ConfigMaps are the tempting wrong answer, but they store values in plaintext and end up in etcd, kubectl describe, and CI logs.

You are shipping a banking iOS app that talks to api.bank.example over HTTPS. The threat model includes users on hostile Wi-Fi and the possibility of a compromised public CA. What TLS (Transport Layer Security) posture makes sense?

SPKI pinning survives certificate rotation as long as the key stays the same, and a backup pin keeps you from bricking the app if you need to rotate keys. Leaf-cert pinning is the plausible wrong answer — it works but requires an app update on every renewal, which is operationally fragile and tempts teams to use very long-lived certs.

You need to encrypt small JSON (JavaScript Object Notation) blobs (user notes) at rest in the database. You will manage the keys via KMS. Which symmetric mode should you reach for?

AES-GCM is authenticated encryption: it provides both confidentiality and integrity, so a tampered ciphertext is rejected on decrypt. CBC is the tempting distractor because it has a random IV, but it offers no integrity — you need to layer an HMAC (Hash-based Message Authentication Code), and getting the order right (encrypt-then-MAC) is easy to botch.

You are integrating Sign in with Google into a public SPA that has no backend it can call its own (the SPA talks directly to your API). Which OAuth flow should the SPA use?

Auth Code + PKCE is the modern recommendation for public clients: the code_verifier ties the redirect back to the original request, so a stolen auth code is useless. Implicit flow is the obvious-looking wrong answer — it returns tokens in the URL (Uniform Resource Locator) fragment, exposes them to history/logs, and has been deprecated by the OAuth 2.1 BCPs.

Your /login endpoint is getting hammered: credential-stuffing attempts from thousands of residential IPs, sometimes one attempt per IP. You also do not want to lock real users out. What rate-limiting strategy fits?

Layered limits catch both the low-and-slow per-IP attack and the targeted single-account attack, and adaptive friction (CAPTCHA, delay) raises cost without a hard lock. Per-account lockout is the seductive wrong answer because it enables trivial denial-of-service: an attacker can lock any user out by submitting wrong passwords.

A teammate adds middleware that logs every request and response body to make debugging easier in production. Endpoints include /login, /payments, and /users/me. What is your review feedback?

Full request/response bodies pull passwords, session tokens, payment data, and PII (Personally Identifiable Information) into a system that was not designed as a vault — and once data is in logs it tends to spread to backups, SIEMs, and screenshots. Short retention is the tempting answer but it does not stop the immediate exposure to anyone with log access.

Your SaaS stores all tenants in one Postgres database with a tenant_id column on every table. A new engineer is writing queries and forgets the tenant filter on a JOIN, leaking data across tenants in staging. How do you prevent this systemically?

Postgres RLS enforces the tenant filter at the database, so a forgotten clause cannot leak data — the policy uses a per-connection setting like current_setting('app.tenant_id'). Code-review checklists are the obvious wrong answer: humans miss things, and the failure mode (silent cross-tenant read) is exactly what you cannot afford to learn about in prod.

An /upload endpoint accepts a file and a JSON metadata blob. The metadata includes a filename, size, and mime_type that the client computes. The server stores the file under filename and trusts mime_type for Content-Type on later downloads. What is the safer design?

Never trust client-declared content type — an attacker can upload an HTML file labeled image/png and trigger stored XSS when another user views it. Sniffing the type from the bytes and constraining filenames to a known-safe charset closes both holes. Rejecting only .. is the plausible wrong answer; it misses null bytes, absolute paths, Unicode normalization tricks, and reserved Windows names.

After a user changes their password from the settings page, what should happen to their other active sessions on other devices?

Password change is the primary user signal that 'someone may have my account' — every other session is now potentially an attacker, and the only safe move is to invalidate them server-side. Prompting the user is the friendly-sounding wrong answer; a victim who is panicking may dismiss the dialog, and a stateless 'just rotate this cookie' does nothing about the other tokens already in the wild.