The Security Interview Question That Doesn't Sound Like One

The key insight: nobody asks you a security question in a senior backend interview. They ask you to explain your system, and then watch whether you notice, unprompted, who could abuse it. That's the entire test.

This reframes a huge chunk of interview prep that's aimed in the wrong direction. Candidates study OWASP Top 10 flashcards, memorize the difference between JWT and opaque tokens, and rehearse bcrypt vs Argon2 talking points. All useful — but useless if you can't spontaneously apply them while walking through your own API design. The signal interviewers are actually looking for is a habit, not a knowledge dump.

That's the framing worth internalizing. Security questions at the senior level rarely arrive labeled "now let's talk security." They show up as a casual follow-up: "okay, and what happens if that user ID belongs to someone else?" If your answer requires you to context-switch into security mode, you've already signaled that threat modeling isn't part of your default design process — it's a separate checklist you run afterward, if at all.

Why the backend is where this matters most

The backend is where identity, permissions, and data access actually get enforced. The frontend can hide a button; it can't stop a curl request. Every endpoint you design is implicitly answering three questions, whether you address them or not:

• Who is allowed to call this?
• What data does it touch or return?
• What happens when someone calls it in a way you didn't expect?

That third one is where most designs quietly fail. Rate limits, pagination bounds, authorization checks scoped to this specific object rather than this resource type — these are the unglamorous details that separate a system that merely works from one that survives contact with an adversarial user.

A concrete pattern: authorization on the object, not the route

A classic gap is checking that a user is authenticated and has a role that can access an endpoint, but forgetting to check that they own the specific resource being requested — the textbook IDOR (insecure direct object reference).

1# Looks fine at first glance
2@app.get("/invoices/{invoice_id}")
3def get_invoice(invoice_id: int, user: User = Depends(get_current_user)):
4    invoice = db.get_invoice(invoice_id)
5    return invoice
6
7# The fix: authorize the object, not just the route
8@app.get("/invoices/{invoice_id}")
9def get_invoice(invoice_id: int, user: User = Depends(get_current_user)):
10    invoice = db.get_invoice(invoice_id)
11    if invoice is None or invoice.owner_id != user.id:
12        raise HTTPException(status_code=404)  # 404, not 403 — don't confirm existence
13    return invoice

That one-line check is the difference between a demo that works and a system that got someone else's financial data exposed by incrementing an integer in the URL. Notice the 404-over-403 detail too — leaking which IDs exist to an unauthorized caller is its own small information disclosure.

The mental model that actually scales

Instead of memorizing a list of vulnerabilities, the more durable skill is treating every design conversation as implicit threat modeling: define the system, ask what can go wrong, decide what mitigates it, and be honest about what you haven't verified yet. That last part matters — a senior answer isn't "we're secure," it's "here's the trust boundary, here's the specific attack I'm worried about, and here's the control that addresses it, and here's what I'd still want to test."

A few areas worth having a sharp, specific answer for, because they come up constantly as "innocent" follow-ups:

• Password storage: slow, salted hashing (bcrypt/Argon2/scrypt) — never plaintext, never fast general-purpose hashes like plain SHA-256.
• SQL injection: parameterized queries as the default, not manual string escaping as your primary defense.
• Token vs session tradeoffs: stateless JWTs scale horizontally but make revocation hard; server-side sessions or short-lived tokens with refresh rotation trade some scale for control. Know which one your system actually needs and why.
• Logging discipline: tokens, passwords, and PII should never end up in application logs or error responses — this one gets missed constantly because it doesn't feel like a "security" decision, it feels like a debugging convenience.

1-- Never do this
2query = "SELECT * FROM users WHERE email = '" + user_input + "'"
3
4-- Always this
5cursor.execute("SELECT * FROM users WHERE email = %s", (user_input,))

Why this matters

The practical value here isn't passing an interview — it's that the same habit prevents real incidents. Most backend security failures aren't exotic zero-days; they're missing authorization checks, secrets sitting in logs, or a rate limit nobody thought to add because the happy path worked fine in the demo. If you build the reflex of asking "who could abuse this" while you design, rather than during a separate security review weeks later, you catch these for free.

Next time you're sketching an API or explaining a system — to an interviewer, a teammate, or yourself — try narrating the abuse path out loud before anyone asks. If you can't, that's your actual practice list, not a stack of OWASP flashcards.