Backend Security Interview Questions
Common backend security interview questions on hashing, JWT, OAuth, CSRF, XSS, injection and secure API design, with answers.
Backend security interview questions
Security questions appear in almost every backend interview. Interviewers want to see that you build safe defaults into your code, not that you memorised acronyms.
1. Authentication vs authorization?
Authentication verifies who a user is (login). Authorization decides what they may do (can this user edit this record?). Both must be enforced on the server for every request.
2. How should passwords be stored?
As salted hashes from a slow, memory-hard algorithm — Argon2id, scrypt or bcrypt — never as plain text, encrypted text or fast hashes like SHA-256. Compare hashes in constant time.
3. What is a salt, and why is it needed?
A random value stored with each password hash so identical passwords produce different hashes. It defeats precomputed rainbow tables and forces attackers to crack each hash separately.
4. Explain JWT structure and how it's verified.
Header, payload and signature, Base64URL-encoded and separated by dots. Verification recomputes or checks the signature with the key, then validates claims like exp, iss and aud. The payload is readable by anyone, so it must not contain secrets.
5. JWT vs session cookies — which would you use?
Sessions for traditional web apps (simple revocation, small cookies). JWTs for APIs, mobile apps and multiple services where stateless verification helps. If using JWTs, keep access tokens short-lived and rotate refresh tokens.
6. How do you revoke a JWT?
You can't change an issued token, so use short expiry, rotate refresh tokens, keep a deny-list of token IDs (jti) for emergencies, or change the signing key to invalidate all tokens.
7. What is OAuth 2.0, and how does OpenID Connect differ?
OAuth 2.0 delegates authorization — an app gets an access token to call an API on the user's behalf. OpenID Connect adds authentication, returning an ID token that identifies the user.
8. What is PKCE?
Proof Key for Code Exchange: the client sends a hash of a random verifier when starting the flow and the verifier itself when exchanging the code, so an intercepted authorization code is useless.
9. What is SQL injection and how do you prevent it?
Untrusted input changes the meaning of a SQL query. Prevent it with parameterised queries or an ORM, allow-lists for identifiers, least-privilege database users, and input validation.
10. What is CSRF and how do you prevent it?
Cross-Site Request Forgery makes a logged-in user's browser send an unwanted request using their cookies. Prevent it with SameSite cookies, anti-CSRF tokens for state-changing requests, and checking Origin headers.
11. What is XSS?
Cross-Site Scripting injects malicious JavaScript into pages other users view. Prevent it with automatic output escaping, a Content-Security-Policy, input validation, and HttpOnly cookies so scripts can't steal sessions.
12. What is SSRF?
Server-Side Request Forgery tricks your server into requesting internal or cloud-metadata URLs. Defend with URL allow-lists, blocking private/loopback/link-local addresses, re-validating redirects, and network egress controls.
13. What is broken access control? Give an example.
A user can access resources they shouldn't — for example, changing /orders/101 to /orders/102 and seeing another customer's order (an IDOR). Fix it by checking ownership or permissions server-side on every request.
14. How do you protect a login endpoint?
Strong password hashing, rate limiting per account and IP, generic error messages ("invalid email or password"), MFA, breached-password checks, logging and alerting on suspicious activity.
15. How do you manage secrets in a backend?
Keep them out of source control; load them from environment variables or a secrets manager; give each service only the secrets it needs; rotate them regularly; and never log them.
16. Why is CORS Access-Control-Allow-Origin: * with credentials a problem?
Browsers actually forbid that exact combination, but reflecting any origin while allowing credentials lets any website make authenticated requests to your API and read the responses. Allow-list specific trusted origins instead.
Practice tip
Take a small API you've built and review it against the OWASP Top 10: check every endpoint for authorization, every query for parameterisation, and every secret's location. Fixing real issues in your own code makes for excellent interview stories.