Security Engineer — Interview Questions.

The three core goals of security. Confidentiality — only authorized parties can read data (encryption, access control). Integrity — data isn't tampered with, and you can detect if it was (hashing, signatures, checksums). Availability — systems and data are accessible when needed (redundancy, DDoS protection, backups). Most controls map to one or more; many security decisions are about balancing them (and against usability).

Authentication = proving who you are (password, MFA, certificate). Authorization = what you're allowed to do once authenticated (permissions, RBAC/ABAC). Accounting/Auditing = recording what you did (logs, audit trail). A classic confusion: "401 Unauthorized" is actually an authentication failure; "403 Forbidden" is the authorization failure. Defense relies on all three plus the audit trail for detection and forensics.

Symmetric uses one shared key for encrypt + decrypt (AES) — fast, used for bulk data. The problem is key distribution. Asymmetric uses a public/private key pair (RSA, ECC): encrypt with the public key, decrypt with the private — solves key exchange and enables signatures, but is slow. In practice they combine (e.g. TLS): asymmetric to authenticate and exchange/derive a session key, then fast symmetric encryption for the actual data. Signatures use the private key to sign, public to verify.

You store hashes so a database breach doesn't reveal plaintext passwords. But fast hashes (SHA-256/MD5) are too fast — attackers brute-force billions/sec and use rainbow tables. Use a slow, salted password hashing function designed for this: bcrypt, scrypt, Argon2 (or PBKDF2). The salt (unique per user) defeats rainbow tables and ensures identical passwords hash differently; the deliberate work factor makes each guess expensive. Encryption is wrong here (reversible) — you want a one-way, slow, salted hash.

Layering multiple independent controls so that if one fails, others still protect you — no single point of failure in your security. Example for a web app: WAF + input validation + parameterized queries + least-privilege DB user + network segmentation + monitoring. Each layer catches what the previous missed. The opposite is a "crunchy shell, soft center" (hard perimeter, flat trusted interior) — which zero trust explicitly rejects. Assume any one control will eventually fail.

Confidentiality (only authorized access), Integrity (data not tampered), Availability (accessible when needed) — the core security objectives.

Authn proves who you are; authz decides what you're allowed to do. Authn first, then authz.

Symmetric: one shared key (fast, AES). Asymmetric: public/private key pair (RSA/ECC) for key exchange and signatures — often combined (asymmetric to exchange a symmetric key).

Hashing is one-way; a per-user salt stops rainbow tables and makes identical passwords hash differently. Use slow hashes (bcrypt/argon2), never plain hashing.

Multi-factor auth requires two+ of: something you know (password), have (token/phone), are (biometric) — defeats stolen-password attacks.

Give each identity only the minimum access needed, reducing blast radius if compromised.

Encryption is reversible with a key (confidentiality); encoding is reversible without a secret (e.g. base64, not security); hashing is one-way (integrity/passwords).

TLS encrypts and authenticates traffic; HTTPS is HTTP over TLS, protecting confidentiality and integrity in transit.

Controls traffic by rules (port/IP/protocol or app-layer); a stateful firewall tracks connections to auto-allow return traffic.

A vulnerability is a weakness; an exploit is code/technique that abuses it. Risk depends on both plus exposure.

SQLi happens when untrusted input is concatenated into a SQL query, so an attacker's input changes the query's structure (e.g. ' OR '1'='1, ; DROP TABLE, UNION-based data exfiltration). Prevention, in order: parameterized queries / prepared statements (the fix — data is bound separately from code, never interpreted as SQL) or a vetted ORM; least-privilege DB accounts (the app user can't drop tables/read other schemas); input validation/allow-listing as defense in depth; and a WAF as a backstop. The root cause is mixing code and data — parameterization separates them. Same principle defeats command injection, LDAP injection, etc.

XSS (Cross-Site Scripting): attacker injects script that runs in other users' browsers (stored/reflected/DOM). It can steal cookies/tokens, act as the user. Defend with context-aware output encoding, input validation, a Content Security Policy, and HttpOnly cookies so JS can't read them. CSRF (Cross-Site Request Forgery): tricks an authenticated user's browser into making an unwanted state-changing request (the browser auto-sends cookies). Defend with anti-CSRF tokens, SameSite cookies, and checking Origin/Referer. Key difference: XSS abuses the site's trust in user content (runs script); CSRF abuses the site's trust in the user's browser (forged request). XSS can defeat CSRF tokens, so fix XSS first.

OAuth2 is an authorization framework: it lets an app get a scoped access token to act on a resource on a user's behalf (delegated access) — it's not for login per se. OIDC (OpenID Connect) is a thin identity layer on top of OAuth2 that adds an ID token proving who the user is — that's what "Sign in with Google" uses. A JWT is a signed (and optionally encrypted) token format — header.payload.signature, base64url — carrying claims; commonly the ID/access token. Gotchas: verify the signature and alg (reject none), check exp/aud/iss, keep them short-lived (they're bearer tokens — anyone holding one can use it), and don't put secrets in the payload (it's only base64, readable by anyone).

Structured "what could go wrong." Steps: (1) Diagram the system — components, data flows, and trust boundaries (where data crosses from less- to more-trusted). (2) Enumerate threats, often with STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) at each boundary/component. (3) Rate risk (likelihood × impact, e.g. DREAD/CVSS-ish) and prioritize. (4) Mitigate — map each significant threat to a control (authn, validation, encryption, rate limiting, least privilege). (5) Validate the mitigations and revisit as the design changes. Do it early (design time) where fixes are cheap; focus on the assets and the trust boundaries.

Never in code, configs, or images. Store in a dedicated secrets manager / KMS (Vault, AWS Secrets Manager, cloud KMS), inject at runtime, and prefer short-lived/dynamic credentials over static ones (workload identity so services assume roles). Encrypt secrets at rest and in transit, tightly scope access (least privilege) and audit it, and rotate regularly (and immediately on suspected compromise). For keys: separate key-encryption keys from data keys (envelope encryption), use HSM/KMS-backed keys, and have a documented rotation + revocation process. Scan repos/CI for accidental secret commits. The goal: centralized, access-controlled, rotated, never persisted in plaintext.

Untrusted input concatenated into SQL lets attackers alter queries; prevent with parameterized queries/prepared statements, ORM, input validation, and least-privilege DB users.

Injecting script into pages (stored/reflected/DOM); prevent with output encoding, CSP, sanitizing input, and HttpOnly cookies.

Tricks a logged-in user's browser into unwanted requests; prevent with anti-CSRF tokens, SameSite cookies, and checking Origin/Referer.

Tricking the server into making requests to internal/metadata endpoints; mitigate by allowlisting destinations, blocking internal IPs/redirects, and IMDSv2.

OAuth2 is for authorization (delegated access via tokens); OIDC adds an identity layer (ID token) on top for authentication.

A signed token carrying claims; risks: alg=none/confusion, weak secrets, no revocation (use short expiry + refresh), and storing in XSS-accessible storage.

Systematically enumerating threats (Spoofing/Tampering/Repudiation/Info-disclosure/DoS/Elevation) per component/data flow, then mitigating.

Layered controls (network, host, app, data, identity) so one failure doesn't breach everything — assume any single layer can fail.

Sharing a symmetric key securely is hard; solved with asymmetric key exchange (Diffie-Hellman/ECDHE) or wrapping the key with the recipient's public key.

A knowledge base of real adversary tactics/techniques used to map detections, assess coverage, and structure threat hunting.

Follow the IR lifecycle (NIST): Preparation (done beforehand — runbooks, logging, access). Identification — confirm it's real, determine scope/severity, preserve evidence (don't tip off or destroy forensics). Containment — short-term (isolate affected hosts, revoke/rotate credentials and tokens, block C2) then long-term, while keeping forensic copies (snapshots, memory) before wiping. Eradication — remove the foothold (malware, backdoors, attacker accounts), patch the entry vector. Recovery — restore from known-good backups, rebuild rather than clean where possible, monitor closely for re-entry. Lessons learned — blameless postmortem, timeline, and concrete improvements. Throughout: clear roles (incident commander), communication (legal, comms, regulators if data was exposed — breach-notification timelines), and a bias toward containing damage over perfect attribution in the moment.

Server-Side Request Forgery: the attacker gets the server to make HTTP requests to a target of their choosing (by controlling a URL the app fetches). In the cloud it's devastating because the server can reach the instance metadata service (e.g. 169.254.169.254) and, on weak setups, retrieve IAM credentials — turning a fetch-a-URL bug into cloud account compromise (the 2019 Capital One breach). It also pivots into internal networks behind the firewall. Defenses: validate/allow-list outbound destinations, block link-local/RFC1918 ranges, require IMDSv2 (session-token, hop-limit) or disable metadata access from workloads that don't need it, network egress controls, and least-privilege roles so a leaked credential is low-value. It's #10-ish on OWASP and a staple cloud-pentest finding.

The pipeline is high-value (it can push to prod) and a prime target. Controls: protect source (branch protection, required reviews, signed commits). Harden CI — ephemeral, isolated runners; least-privilege, short-lived credentials (OIDC federation to cloud, no long-lived keys); pin action/image versions by digest; isolate untrusted PR builds. Scan — SAST, SCA/dependency, IaC, secret scanning, image scanning as gates. Supply chain — generate and verify an SBOM, sign artifacts (Sigstore/cosign) and verify signatures at deploy, enforce provenance/attestations (SLSA, in-toto) so you can prove how an artifact was built. Policy gates (OPA/Kyverno admission) requiring signed, scanned images. Least privilege on what the pipeline can deploy. Threats to address: dependency poisoning, compromised build step, leaked CI secrets, malicious PRs, and tampered artifacts — defense in depth across source → build → artifact → deploy.

Commonly confused. Encoding (base64, URL) is reversible and provides no security — it's for data format/transport. Encryption is reversible with a key — provides confidentiality (AES/RSA); whoever has the key can decrypt. Hashing is one-way (irreversible) — provides integrity and is used for password storage (with salt + slow KDF) and signatures; you can't get the input back, only verify a match. Tokenization replaces sensitive data with a non-sensitive surrogate (token) while the real value is kept in a secure vault/mapping — common for PCI (card numbers) so systems handle tokens, not card data, reducing scope. Quick test: need it back with a key → encryption; need to verify not reverse → hashing; just changing format → encoding; need to remove sensitive data from scope → tokenization.

You can't respond to what you can't see. Log the right things — authn/authz events, admin actions, access to sensitive data, config changes, network flows, and cloud control-plane (CloudTrail) — with enough context (who/what/when/where) and consistent timestamps. Centralize into a SIEM, immutable/append-only and access-controlled (attackers delete logs — protect and ship them off-host). Detect — signatures for known-bad plus anomaly/behavioral detection; map coverage to MITRE ATT&CK to find gaps; tune to reduce alert fatigue (high signal-to-noise). Alert and respond — route to on-call with runbooks, automate enrichment/containment (SOAR) where safe. Retain per compliance and forensic needs. Cover the layers: endpoint (EDR), network (IDS/flow), application, identity, and cloud. The aim: high-fidelity detection of the techniques that matter, with logs trustworthy enough for forensics, and a fast path from alert to action.

Prepare → Detect/analyze → Contain (isolate, preserve evidence) → Eradicate (remove foothold) → Recover (from clean backups, rotate secrets) → Post-incident review with hardening.

Random high-entropy session IDs, HttpOnly+Secure+SameSite cookies, server-side invalidation, idle+absolute timeouts, rotation on privilege change, and re-auth for sensitive actions.

Central vault, runtime injection, per-service workload identity, short-lived/dynamic creds, rotation, audit, per-env isolation, encryption, and repo/CI scanning.

A chain from a leaf cert up to a trusted root CA; clients verify signatures up the chain, check validity/revocation (CRL/OCSP) and hostname — trust anchored in the root store.

Centralize logs/telemetry (SIEM), map detections to MITRE ATT&CK, alert on anomalies/IOCs, automate enrichment + containment playbooks (SOAR), and continuously tune.

SBOM, pinned+verified deps, signed commits/artifacts (Sigstore/SLSA), reproducible builds, and admission control allowing only attested artifacts — defends against compromised deps/builds.

Strong identity + MFA on every request, device posture, microsegmentation, least privilege + JIT access, encrypt everywhere, continuous verification, and assume-breach monitoring.

MFA (ideally phishing-resistant/passkeys), rate limiting + bot detection, breached-password checks, anomaly-based login risk scoring, and device fingerprinting.

Hash: integrity, no key. HMAC: integrity+authenticity with a shared secret. Signature: integrity+authenticity+non-repudiation with asymmetric keys (anyone verifies with the public key).

Authn (OAuth2/OIDC/mTLS), fine-grained authz, input validation, rate limiting/quotas, TLS, secrets management, logging/auditing, and protection against OWASP API Top 10 (BOLA/broken auth).

Follow the IR lifecycle. Contain first (isolate affected hosts/accounts, revoke sessions/keys, block C2) to stop the bleeding — but preserve evidence (snapshot memory/disk, keep logs) before wiping. Eradicate the foothold (malware, backdoors, compromised creds). Recover from known-good backups, rotate all potentially exposed secrets, and monitor for re-entry. Communicate per policy (legal, comms, regulators if PII). Then a blameless postmortem with concrete hardening. Don't tip off the attacker or destroy evidence in a panic.

First assess how passwords were stored — properly salted + slow-hashed (bcrypt/argon2) buys time; plaintext/MD5/unsalted = assume cracked now. Regardless: force password resets, invalidate sessions, and notify users (and regulators if required — GDPR/breach laws). Watch for credential stuffing on your and other sites, enforce/promote MFA, and rotate any other secrets in the same store. Then fix storage (argon2id + salt + pepper) and figure out the breach vector.

Immediate: deploy a WAF rule as a stopgap and, if severe, restrict/disable the affected endpoint. Real fix: parameterized queries / prepared statements (and ORM), input validation, least-privilege DB account. Then investigate exfiltration — review DB/query logs for what was accessed, assume data was read if it could be, and follow breach process. Rotate exposed secrets, add SAST/DAST to catch it earlier, and audit other endpoints for the same flaw.

Revoke all sessions and reset the account immediately, rotate its credentials/tokens, and enforce MFA (assume the password is gone). Then hunt for lateral movement — what did that account access, any new logins from odd locations/IPs, mailbox rules, OAuth grants, privilege escalation? Review SIEM/auth logs across the exposure window. Contain anything touched, notify per policy, and follow up with phishing-resistant MFA (passkeys/FIDO2) and user training. Treat one phish as a possible beachhead, not an isolated event.

Central secrets manager (Vault / cloud secrets), never secrets in code/images/Git. Inject at runtime (External Secrets Operator / CSI in k8s). Least privilege per service via workload identity (IRSA/OIDC) so apps assume roles instead of holding static keys; prefer short-lived/dynamic credentials. Rotation, audit logging, and per-environment isolation (dev can't read prod). Encrypt at rest + in transit, scan repos/CI for leaks. Goal: centralized, access-controlled, rotated, never plaintext.

Assess your exposure: what data/access did they have, what shared credentials/API keys/tokens connect you? Rotate all shared secrets immediately and review/limit their access (revoke if unneeded). Check your logs for misuse via that integration during the window. Notify your stakeholders/regulators if your data was affected, and review the vendor's disclosure + remediation. Long-term: least-privilege vendor access, scoped tokens, monitoring on third-party integrations, and contract/security-review requirements.

Contain (isolate hosts/accounts, revoke sessions) while preserving evidence, eradicate the foothold, recover from clean backups + rotate all exposed secrets, communicate per policy, then blameless postmortem.

Assess storage (bcrypt/argon2 buys time, plaintext/MD5 = assume cracked), force resets, notify users/regulators, watch credential stuffing, rotate other secrets, fix storage + breach vector.

WAF rule + restrict endpoint as stopgap; fix with parameterized queries + least-privilege DB; investigate exfiltration via logs, rotate secrets, add SAST/DAST, audit other endpoints.

Revoke sessions + reset + enforce MFA, hunt lateral movement (logins, mailbox rules, OAuth grants, escalation), review SIEM over the window, contain, and move to phishing-resistant MFA.

Vault, runtime injection, least-privilege workload identity, short-lived dynamic creds, rotation, audit, per-env isolation, encryption, repo/CI scanning.

Assess exposure (data/access/shared creds), rotate shared secrets, limit/revoke their access, check logs for misuse, notify per policy, review their disclosure + tighten vendor access.

XSS can steal the JWT → full account takeover; fix the XSS (encoding/CSP), move tokens to HttpOnly cookies + SameSite, use short expiry + refresh, and consider token binding.

Contain (block egress/isolate host), preserve evidence, scope what was accessed, identify the entry vector, rotate exposed creds, and follow breach-notification process.

Just-in-time, time-boxed, scoped least-privilege role with MFA, full audit logging, and automatic expiry/revocation — never a shared long-lived account.

Immutable/offline backups (tested restores), least privilege + segmentation to limit spread, EDR + anomaly detection, MFA + patching to block entry, and a tested IR/recovery plan.