Security

A React SPA talks to a REST 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. 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 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 page greets the user with a name they typed into their profile: element.innerHTML = 'Hi, ' + user.name. A user sets their name to <img src=x onerror=alert(1)>. What is the simplest safe fix?

innerHTML parses its input as HTML, so the injected img tag runs its onerror handler for every visitor who sees the name: a stored XSS bug. textContent inserts the string as text, and nothing in it can execute. Stripping the word script (b) misses this payload entirely, since it uses an event handler. Quotes (c) change nothing about how the HTML is parsed.

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 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) 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 pushed a commit to a public GitHub repo, and a minute later you notice it contains a live API key for your payment provider. What do you do first?

Assume the key is already compromised: bots scan public GitHub for credentials within minutes of a push. Revoking it is the only step that stops it from working, and cleaning history comes after. Deleting it in a new commit (a) leaves the key in history. A force push (c) or a private repo (d) can't recall the copies that forks, clones, and scrapers already have.

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 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 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 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 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.

Your signup form checks in JavaScript that the username is 3 to 20 letters and digits before it submits. A teammate says the API can skip its own check because the form already validates. Is that safe?

Client-side checks are a convenience for honest users. Anyone can send a request with curl, a script, or the browser's dev tools and skip the form entirely, so the server has to enforce every rule itself. Minifying (b) slows nobody down. HTTPS (d) protects the request in transit and says nothing about what is in it.

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.

Your marketing site is served over plain HTTP. Its login form posts to an HTTPS endpoint, so a teammate says passwords are already encrypted. What is wrong with that reasoning?

The form's HTML arrives over HTTP, so anyone on the path, like the operator of a coffee shop Wi-Fi, can rewrite it before it renders: change where the form posts, or inject a script that reads the password as it is typed. A password is only as safe as the page that collects it. Browsers allow the post (b), which is why this mistake ships. Hashing in JavaScript (c) turns the hash into the password, and an attacker who can edit the page can remove that code anyway.

Your Forgot Password form says 'No account found with that email' for unknown addresses and 'Check your inbox' for known ones. Why would a security review flag this?

Different responses for known and unknown emails let an attacker run a list of addresses through the form and learn who has an account, which feeds phishing and credential stuffing. Return the same message ('If an account exists, we sent a link') either way. Security questions (c) are weaker than an emailed link, since the answers are often public or guessable. Link expiry (d) is good practice and does nothing about the leak.

When a request fails in production, your API returns the full stack trace and the SQL query that failed in the response body. It makes debugging easy. What should the API return instead?

Stack traces and queries tell an attacker your framework, library versions, file paths, and table names, which makes the next attack much easier. Return a generic message with a request ID the user can quote to support, and log the full detail on the server where you can look it up by that ID. Logged-in users (a) include attackers with free accounts. A 200 (b) breaks clients and monitoring. Base64 (d) is an encoding anyone can reverse.

The endpoint DELETE /admin/users/:id checks that the request has a valid session, then deletes the user. A regular logged-in user finds the URL and deletes someone else's account. What is missing?

Authentication answers who the caller is, and the endpoint got that right. Authorization answers what the caller is allowed to do, and the endpoint never asked. Every admin route needs a server-side role check. Hidden URLs (c) turn up in JavaScript bundles, logs, and guesses. A confirmation dialog (d) lives in the UI, and the attacker calls the API directly.

npm audit reports a critical vulnerability in a package your app pulls in through another dependency. Your own code never imports it. What should you do?

Transitive dependencies run inside your app just like direct ones, and the package that pulled it in may call the vulnerable code for you. Upgrade the parent package to a release that ships the fix, or use the overrides field in package.json to force the patched version, then run your tests. Deleting the lockfile (b) gives you an unpredictable set of upgrades and may still leave the bad version. Turning off the audit (c) hides the problem.