Security interview questions
Security questions a Backend developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
The interviewer asks: “Where do database passwords and API keys live?” Strongest answer?
The strongest answer: In the environment or a secret store injected at deploy — never in source, never in the image layer as a default committed to git.
Why it works: Exactly. Code is copied, forked and logged. Secrets are injected. Twelve-factor is still the interview answer in 2026.
- Secrets are injected, not committed.
- Environment or a secret manager.
- No production passwords in the repo.
- A leaked .env is an incident.
The interviewer asks: “How do you put user input into SQL?” Strongest answer?
The strongest answer: Parameters / bind variables. The value never becomes SQL text. I never concatenate untrusted input into the statement.
Why it works: Exactly. Parameterised queries (and ORM bind) are the default in 2026. Concatenation is how you donate the database.
- Bind values; don't concatenate.
- Escaping is not a substitute.
- Integers aren't a free pass.
- String-built SQL with user text is unsafe.
The interviewer asks: “We set CORS to our frontend origin. Are we safe?” Strongest answer?
The strongest answer: CORS is a browser rule about who can read a response. It is not authentication or authorization. curl, mobile apps and servers ignore it. I still auth every request.
Why it works: Exactly. A missing CORS header stops a browser page, not an attacker. Authz is still the API's job.
- CORS ≠ authn/authz.
- Browsers care; curl does not.
- Still authenticate every call.
- Never * with cookies.
The interviewer asks: “How do services get secrets in production?” Strongest answer?
The strongest answer: A secret manager (cloud KMS/vault) mounted or injected at runtime, short-lived where possible, rotated without a code change. Not files in the image, not git, not a shared Slack message.
Why it works: Exactly. Identity of the workload fetches the secret. Rotation doesn't need a rebuild. Audit who read what.
- Runtime inject from a secret manager.
- Short-lived, rotatable, audited.
- Not git, not images, not logs.
- Workload identity beats a shared password.
The interviewer asks: “What must never land in logs or traces?” Strongest answer?
The strongest answer: Secrets, session tokens, passwords, full card numbers, and anything our retention policy treats as sensitive PII unless it's hashed or tokenised. I redact at the logger, not by hoping people remember.
Why it works: Exactly. Logs are a datastore with weak access control and long copies. Redaction libraries and allow-listed fields beat folklore.
- Redact secrets and sensitive PII.
- Logs are a store; treat them like one.
- Don't keep “everything for court.”
- Collection beats permissions — don't collect it.
The interviewer asks: “A user asks us to delete their data. What does a backend actually do?” Strongest answer?
The strongest answer: A tested erasure path: production data, backups/retention windows we have documented, search indexes, logs we can justify, and derived stores. I don't promise 'everywhere' if backups are immutable — I state the policy we actually run.
Why it works: Exactly. Deletion is a product+legal design: what we erase, what we anonymise, how long backups last. Engineering implements that policy and can demonstrate it.
- Erasure is a designed path, not a DELETE.
- Inventory every store, including logs.
- Document backup windows honestly.
- Append-only still needs a PII story.
The interviewer asks: “Threat-model this order service. Where do you start?” Strongest answer?
The strongest answer: Assets and actors: money, PII, admin actions; users, other services, operators, a stolen token. Then STRIDE-style questions on each trust boundary — especially IDOR, injection, and the admin path — and what control already exists.
Why it works: Exactly. A threat model is a conversation about what you're protecting and who can touch it. Scanners don't replace that; they follow it.
- Name assets, actors, trust boundaries.
- Ask how each boundary fails (IDOR, inject, abuse).
- Scanners help; they aren't the model.
- Do this before the design ships.
The interviewer asks: “A customer requires their data stay in the EU. What do you actually implement?” Strongest answer?
The strongest answer: Store and process that tenant in an EU region: database, object storage, logs, backups, and support tools. I don't silently replicate to another region for “DR convenience,” and I document what subprocessors see.
Why it works: Exactly. Residency is about where bits live and who can read them — including replicas, snapshots and observability. Encryption helps confidentiality; it doesn't move the jurisdiction.
- Residency includes DB, backups, logs.
- No silent cross-region copies.
- Encryption ≠ a region move.
- Don't advertise a flag you didn't build.
The interviewer asks: “The API pod's cloud role can read all buckets and impersonate other roles. What's wrong?” Strongest answer?
The strongest answer: That's standing privilege far beyond the service. I scope the workload identity to the buckets and APIs it needs, short-lived tokens, no impersonate-all. A break of this pod should not be a break of the company.
Why it works: Exactly. Workload identity + least privilege is how you cap a remote-code bug. Privilege of the pod is the real blast radius.
- Workload identity, least privilege.
- A pod break ≠ company break.
- Private net isn't enough.
- No long-lived god keys in env.
The interviewer asks: “Privacy by design — what does the backend actually ship?” Strongest answer?
The strongest answer: Collect the minimum, tag what is personal, expire it, encrypt it, and ship the delete/export path in v1 — not as a ticket after the first request. Access is logged. Defaults are off for secondary use.
Why it works: Exactly. Privacy is a feature set: minimisation, retention, rights workflows, access control. Retrofitting is where companies fail audits.
- Minimise, expire, encrypt, delete/export.
- Ship the rights path in v1.
- Don't theatre-hash the UI only.
- “Keep all events” is not a privacy design.
The interviewer asks: “A popular npm/NuGet/Maven package you use was compromised. What should already have been true?” Strongest answer?
The strongest answer: Pinned, reviewed dependencies, lockfiles in CI, scanning, and minimal install surface. We can freeze and roll back. We don't float latest on main, and we don't run postinstall scripts from untrusted tags.
Why it works: Exactly. Supply chain is a backend production risk. Pin + scan + a rollback story is the mature bar. Rebuilds should be reproducible.
- Lockfiles, pins, scans, rollback.
- Don't float latest on main.
- The registry can lie; hashes shouldn't.
- No ad-hoc curl | sh in prod.
The interviewer asks: “Product wants to keep clickstreams forever for “future ML.” What's your backend answer?” Strongest answer?
The strongest answer: We only keep what we have a documented purpose and retention for. Forever clickstreams are a privacy and security pile. I'll offer aggregated or hashed features with a TTL — not raw identity in an immortal log.
Why it works: Exactly. Purpose limitation is an engineering constraint: schemas, TTLs, and access. “Future ML” is not a purpose. That's how you fail a review and a breach notification.
- Purpose + retention, not “forever for ML.”
- Prefer aggregates and TTLs.
- Policy text isn't a blank cheque.
- No shadow buckets.