You are not being interviewed as a security engineer. You are being checked for one habit: whether, while describing a system, you notice who could abuse it.
Security questions rarely arrive labelled. They show up as follow-ups inside an ordinary technical conversation, and the ones that matter come back to a single instinct: treating input as hostile and asking who this trusts and why.
Authentication and authorisation are different questions
Everyone can define the difference. The interesting part is that authentication bugs are rare and authorisation bugs are everywhere, because authentication is one well-tested code path and authorisation is a decision at every single endpoint.
The specific failure worth naming is trusting an identifier from the client. An endpoint that fetches a record by an id in the URL, checks that the caller is logged in, and returns it, is broken: the caller is authenticated and has no right to that record. Being able to describe that in one breath is more valuable than any definition.
Password storage
A near-guaranteed question, and one where a good answer takes fifteen seconds.
How do you store user passwords?
Junior answer: Hashed and salted, never plain text, using bcrypt rather than something like MD5 or SHA-256 because those are too fast and not designed for passwords.
Senior answer: A deliberately slow, memory-hard hash, so bcrypt or argon2, with the work factor tuned to what the login path can afford and raised as hardware gets cheaper. The slowness is the point, because the real threat is offline cracking after a dump rather than anything at login time. Salts are per user and stored alongside the hash, which is what stops one precomputed table covering every account. I would also keep the failure path constant time, since a login that returns measurably faster for an unknown email leaks which accounts exist.
The timing side channel is the follow-up. Volunteering it moves you into a different category of candidate.
Sessions and tokens
Expect a discussion of stateless tokens versus server-side sessions, and expect it to be a trade-off question rather than a right-answer question.
Stateless tokens avoid a lookup on every request, which is why they scale nicely. What they cost you is instant revocation: until it expires, a stolen token is valid, and there is no server-side record to delete. That is the whole trade, and the mature answer is a short access token plus a refresh token, with a deny list only on the paths where the risk justifies the round trip.
- Never accept the algorithm from the token itself. Pin it server side.
- Verify signature, issuer, audience and expiry, not just that it decodes.
- The payload is readable by anyone holding it. Signed does not mean private.
- Store it somewhere script cannot read it if you can, which usually means an httpOnly cookie rather than local storage.
Injection, and why parameterisation is the answer
Still asked, still worth answering precisely, because most candidates say escaping when the actual answer is separation.
A parameterised query does not clean the input, it sends the query and the data separately, so the database never parses user text as SQL. That distinction matters, because escaping is a filter that can be wrong and separation is structural. The same reasoning covers shell commands and any other interpreter: pass arguments, do not build strings.
// injectable: the value becomes part of the parsed statement
db.query("SELECT * FROM users WHERE email = '" + email + "'");
// parameterised: the value is never parsed as SQL
db.query("SELECT * FROM users WHERE email = $1", [email]);
The first version concatenates user input into the statement. The second sends the statement and the value on separate channels, so nothing in the value can change the query's structure.
XSS and CSRF, and why people mix them up
Worth being able to separate cleanly, because candidates routinely give the mitigation for one when asked about the other.
Cross-site scripting is untrusted content becoming executable in your page, and the defence is contextual output encoding plus a content security policy. Cross-site request forgery is another site causing the browser to make an authenticated request to yours, and the defence is a token the other site cannot read plus same-site cookies. One is about what runs in your page, the other is about who caused a request. If you have XSS, your CSRF defences are irrelevant, since the attacker is already running inside your origin, and saying that shows you understand the relationship rather than the labels.
Secrets
Usually asked practically: where do your credentials live. The expected answer is injected at runtime from a secret manager or the platform's environment, never committed, with rotation possible without a code change.
The follow-up worth preparing is what you do when a secret leaks. Rotate first, then work out the exposure, and assume anything committed to a repository is compromised permanently regardless of whether the commit was later removed. That last point is the one interviewers listen for.
Rate limiting and abuse
Increasingly common, particularly for anything with a login form or an expensive endpoint.
The reasoning to show is what you are limiting on and why. Per IP is easy and weak, since attackers rotate addresses and shared networks hurt real users. Per account protects against credential stuffing against one target. Both, at different thresholds, is usually the honest answer. The good follow-up is where the counter lives once you run several processes, which lands you back on shared state, the same problem scaling a Node process runs into.
What is actually being scored
Not a checklist. Interviewers are listening for whether you volunteer the abuse case unprompted, the same way you would volunteer a trade-off. Someone who says which endpoint they would attack first, in their own design, has demonstrated the instinct the round is looking for.
Common questions
How much security is expected from a normal backend role?
The common classes and a threat-model instinct. Nobody expects exploit development. Everybody expects you to notice that user input reaches a query.
Should I memorise the OWASP Top Ten?
Know the categories and be able to describe two or three properly. Reciting ten labels with no mechanism behind them is transparent and scores badly.
What if I have never worked on anything security sensitive?
Say so and reason from the systems you have built. Naming where you would be worried about your own past work is a strong, honest answer.
Security questions are almost entirely follow-up territory, which is where a definition stops helping. Run a security-focused interview and see where yours ends. Practise a security interview
