Security Interview Questions

Confidentiality (only authorized parties read data), Integrity (data isn’t tampered with undetected), Availability (it’s there when needed). Every security control defends at least one; they trade against each other.

Authentication verifies who you are (login, MFA); authorization verifies what you may do (permissions). 401 = not authenticated, 403 = authenticated but not permitted. Authz bugs (IDOR) are the more common breach.

Encryption: reversible with a key — confidentiality. Hashing: one-way fingerprint, no key — integrity. Encoding (base64): reversible, no key, zero security — a data format. Calling base64 “encryption” is a red flag.

Symmetric (AES): one shared key, fast, bulk data — but key distribution is hard. Asymmetric (RSA/ECC): public/private pair, slow, solves key exchange + identity. TLS uses asymmetric once to agree a symmetric session key.

A per-user random salt stored beside the hash makes identical passwords hash differently and defeats precomputed rainbow tables — the attacker must crack each hash individually.

Multi-factor auth: two different factors from know (password), have (phone/key), are (biometric). Two passwords isn’t MFA — same factor. Phishing-resistant MFA (passkeys/hardware keys) binds to the real origin.

Every user, service and credential gets the minimum access needed and nothing more. Doesn’t stop a breach — shrinks its blast radius from “everything” to “one thing”. Cheapest control there is.

TLS wraps HTTP in confidentiality (encrypted), integrity (tamper-evident) and authentication (the certificate proves the server’s identity via a trusted CA). Same methods and status codes underneath.

Untrusted input concatenated into a query changes its structure (`' OR 1=1 --`). Fix: parameterized queries — the driver sends query and data separately so input can never become SQL. Escaping by hand is the history of failed defenses.

Social engineering that targets the human, not the tech: a fake login harvests credentials or an attachment runs a payload. It’s the most common initial-access vector because urgency and authority override caution.

As a slow, salted hash using bcrypt/scrypt/argon2 — never plaintext, never encrypted, never a fast hash like SHA-256. Slowness turns billions of GPU guesses per second into thousands; salts kill rainbow tables.

A ranked list of the most common web app risks: broken access control (#1), cryptographic failures, injection, insecure design, misconfiguration, vulnerable components, auth failures, integrity failures, logging gaps, SSRF. It’s a prioritization guide, not a checklist.

XSS injects script that runs in the victim’s page — full session access, can read responses. CSRF tricks the browser into sending an authenticated request via auto-attached cookies — blind but state-changing. Defenses differ: output encoding/CSP vs SameSite/tokens.

Insecure Direct Object Reference — /invoice/18 returns another user’s data because there’s no per-object authorization. Fix: check ownership server-side on every access, tied to the authenticated principal. Unguessable IDs help discovery but aren’t authz.

Server sessions: opaque ID, state server-side, instant revocation, needs a shared store to scale. JWT: signed claims in the token, stateless, any instance verifies — but revoking before expiry needs a denylist, reintroducing state.

Layered independent controls so a breach of one meets another: WAF, input validation, parameterized queries, least-privileged DB user, segmentation, monitoring. The attacker must win repeatedly; you must win once.

Redirect to provider → user logs in and consents there → provider redirects back with a one-time code → app backend exchanges code + client secret for a scoped access token. The code step exists because the browser redirect is observable; the code alone is useless without the secret/PKCE verifier.

Each TLS session derives a unique key via ephemeral Diffie-Hellman (ECDHE), discarded afterward. Stealing the server’s long-term private key later can’t decrypt past captured traffic — that key only authenticated, it never derived session secrets.

Your OS/browser trusts ~150 root CAs. A root signs an intermediate, which signs the server’s leaf cert. Verification walks leaf → intermediate → root, checking signatures, validity, revocation and name match. Trust the root, transitively trust what it signed.

A malicious page makes your logged-in browser send a state-changing request; cookies attach automatically so it looks authentic. Defenses: SameSite=Lax/Strict cookies, per-session CSRF tokens the attacker can’t read, and re-auth for sensitive actions.

Never in source code — they live in git history forever. Inject at runtime via env vars, a secrets manager (Vault, cloud KMS) or mounted files. If a secret ever hit a commit, rotate it; deletion doesn’t help, it’s already scraped.

Splitting the network into zones with controlled crossings so one foothold can’t reach everything. A DMZ holds internet-facing services; the database sits in a private zone reachable only from the app tier. Blast-radius reduction at the network layer.

Server-Side Request Forgery tricks your server into making requests — classically to the cloud metadata endpoint (169.254.169.254) that hands out instance credentials. One “fetch this URL” feature plus SSRF equals stolen cloud keys (the Capital One pattern). Defend with destination allowlists.

Compromising something upstream — a dependency, maintainer account or build system — so malicious code ships inside a trusted artifact with your app’s privileges. Log4Shell, event-stream, SolarWinds. Defenses: lockfiles with integrity hashes, SCA scanning, signed/reproducible builds, an SBOM.

1-RTT handshake (down from 2), key share in the first flight, and a purge of broken options (RC4, static RSA, SHA-1). 0-RTT resumption can be replayed by an attacker, so early data must carry only idempotent requests.

“Never trust, always verify” — drop implicit network trust; every request is authenticated, authorized and encrypted regardless of origin, as if from the open internet. Identity becomes the perimeter. Solves what perimeter security can’t once an attacker is inside or “inside” stops existing.

Phishing or an exploited edge service for initial access → payload + persistence → privilege escalation → lateral movement across a flat network → data exfiltration for double extortion → detonate encryption. Break any link — MFA, patching, segmentation, egress monitoring, offline backups.

Contain before investigating everything: isolate affected hosts, revoke suspect credentials/sessions, preserve evidence. Then scope, eradicate the foothold, recover from known-good backups, and run a blameless postmortem. Preparation is what makes it calm not chaotic (PICERL).

Argon2/bcrypt password hashing + breach-password checks, or delegate to OAuth/OIDC. Sessions in httpOnly+Secure+SameSite cookies, or short-lived JWTs with refresh + a revocation denylist. MFA (prefer passkeys), rate limiting, and server-side authorization checks on every request — never trust the client’s claimed role.

Contain: force logout/rotate that user’s sessions and credentials. Investigate: check auth logs for source IPs, times, MFA status, credential-stuffing patterns across accounts. Determine scope (one account or many), notify per policy/regulation, remediate the root cause (leaked reuse, missing MFA, session fixation), and run a blameless retro.