Security Engineer Interview Questions

Option B is the strongest: it demonstrates knowledge of the current 2021 list (not the outdated 2017 version), gives the specific attack patterns under each category (IDOR, horizontal vs vertical privilege escalation), names precise mitigations with alternatives (bcrypt vs MD5, parameterised queries vs ORMs), and explains why each is critical — not just that it is. Key OWASP knowledge for security interviews: Know the 2021 list order by heart — interviewers often test whether you know Broken Access Control moved to #1 in 2021 (previously #5). Broken Access Control specifics: IDOR (Insecure Direct Object Reference) — /api/orders/1234 where 1234 is another user's order ID. If no authorization check, attacker reads any order. Horizontal privilege escalation — same-role, different user. Vertical privilege escalation — different role (regular → admin). Injection specifics: Always parameterised queries/prepared statements. Never string concatenation. ORMs reduce injection risk but don't eliminate it (raw queries in ORMs can still be vulnerable). Cryptographic Failures specifics: Password hashing ≠ encryption. MD5/SHA-1/SHA-256 are NOT suitable for passwords (too fast, rainbow table attacks). bcrypt, Argon2, scrypt are designed to be slow. Key differentiation: Argon2 won the Password Hashing Competition (2015) and is the current recommendation.

Option B is the strongest: it gives a time-bounded structured response (first hour, 24h, 24–72h), includes the critical evidence preservation step that many candidates miss, names specific regulatory frameworks with their deadlines (GDPR 72h, HIPAA 60 days), addresses the legal communication angle (don't speak publicly without legal approval), and ends with post-incident hardening. The most common mistake in breach response interviews: wiping or rebooting systems before forensic imaging. This destroys volatile evidence (RAM, process list, network connections) that is critical for understanding how the attacker got in. Evidence preservation order: 1. RAM (most volatile — dump immediately). 2. Running processes and network connections. 3. Logs (centralise/freeze). 4. Disk image. Key regulatory deadlines — must know for security interviews: GDPR — notify supervisory authority within 72 hours of awareness. If high risk to individuals, notify them too "without undue delay." HIPAA — notify HHS within 60 days of discovery; if > 500 individuals, notify media. NIS2 (EU) — initial notification to authority within 24 hours (significant incidents). GDPR vs data subjects: you must notify individuals only if there's a "high risk" to their rights and freedoms. Lower-risk breaches may only require authority notification. Dwell time: average time an attacker is present before detection — industry average was ~200 days, now closer to ~16 days. Long dwell time = more lateral movement = worse scope.

Option B is the strongest: it defines threat modeling precisely, gives the full STRIDE acronym with definitions, explains the DFD-based process step by step, includes risk scoring (DREAD/CVSS), makes the "shift left" argument, mentions two alternative frameworks (PASTA, LINDDUN), and describes the output artefact (threat register with residual risk) — showing that threat modeling produces an actionable document, not just a meeting. STRIDE in full — memorise the acronym: S — Spoofing → Authentication controls (MFA, certificates, signed tokens). T — Tampering → Integrity controls (HMAC, signing, checksums, input validation). R — Repudiation → Non-repudiation controls (audit logs, digital signatures, tamper-evident logging). I — Information Disclosure → Confidentiality controls (encryption, access control, data minimisation). D — Denial of Service → Availability controls (rate limiting, circuit breakers, resource quotas). E — Elevation of Privilege → Authorization controls (least privilege, RBAC, ABAC). Data Flow Diagram components: External entities (actors), Processes (code), Data Stores (databases, files), Data Flows (arrows), Trust Boundaries (dashed lines separating privilege zones). The trust boundary crossings are where most security controls should be applied. PASTA (Process for Attack Simulation and Threat Analysis) — risk-centric approach that maps technical threats to business impact. LINDDUN — privacy-specific threat model (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance).

Option B is the strongest: it addresses all seven security layers with specific techniques under each, makes the critical auth vs. authz distinction (being authenticated ≠ being authorised for a resource), explains WHY object-level authorisation matters (IDOR), specifies what to avoid in logs (passwords, tokens, card numbers), and includes security headers — often overlooked but important for a complete secure API. Authentication vs. Authorisation — the most critical distinction: Authentication (AuthN) — "Who are you?" — verified by credentials, tokens, certificates. Authorisation (AuthZ) — "Are you allowed to do this?" — enforced by access control logic. A common security bug: the API gateway validates the JWT (AuthN) but the service doesn't verify that the user in the token actually owns the resource they're requesting (AuthZ). JWT security notes: use short expiration (15–60 minutes for access tokens); use refresh tokens with rotation for long sessions; choose RS256 (asymmetric) over HS256 (symmetric) when multiple services verify tokens; store in httpOnly cookies (not localStorage) to mitigate XSS token theft. Sensitive data in logs — OWASP: never log authentication credentials, session tokens, full credit card numbers/PAN, social security numbers. Use log scrubbing middleware. Response data minimisation: never return more than the client needs. No internal database IDs in responses (use external, non-enumerable IDs). No stack traces in production (leaks paths, framework versions, function names to an attacker). Rate limiting response: always return 429 with a Retry-After header — allows legitimate clients to back off.

Option B is the strongest: it extends the principle explicitly to "minimum time needed" (just-in-time access), applies it at five distinct layers (human IAM, service identities, database, Kubernetes), names specific tooling for each, and closes with a list of violations to watch for — giving the interviewer a complete mental model of how a senior security engineer operationalises the principle. Least privilege implementation layers: Human identity — IAM/RBAC: Role-based access control (RBAC): permissions → roles → users. Attribute-based access control (ABAC): permissions based on attributes (department, clearance level, resource owner). Just-in-time (JIT) access: no standing high-privilege access; request elevation for a short window with approval. Tools: AWS IAM Identity Center, HashiCorp Boundary, CyberArk. Service identity — workload identities: Each service has its own identity (IAM role, Kubernetes service account) with the minimum policy. No long-lived API keys in code — use role-based credentials that rotate automatically. Secrets manager (AWS Secrets Manager, Vault) for dynamic secret injection. Database — separate application user from admin user: Application user: SELECT, INSERT, UPDATE on specific tables. Migration user: ALTER TABLE — only used during deployments. Admin user: used manually, not by applications. Permission drift — over time identities accumulate permissions they no longer use. Tools like AWS IAM Access Analyzer and Cloudcraft identify unused permissions. Zero standing privileges (ZSP) — the most secure posture: no identity has permanent elevated access; all high-privilege access is just-in-time, approved, time-boxed, and logged.

The correct response prioritizes understanding the *impact* before taking drastic action. Rolling back immediately without assessment could disrupt ongoing builds and isn't always the best solution. Suggesting a rapid impact assessment allows for a more informed decision about the urgency and potential consequences of remediation – avoiding unnecessary downtime and ensuring alignment with overall risk tolerance.

The key here is recognizing that 'basic' doesn't equate to 'secure'. The provided validation function is extremely weak and vulnerable. Highlighting this encourages the developer to move beyond a superficial understanding of requirements and towards implementing industry-standard security practices like salting and hashing – critical for protecting user credentials.

While all options are relevant to microservice security, JWT expiration time is a foundational element. Short-lived JWTs significantly reduce the window of opportunity if a token is compromised. Refresh tokens introduce complexity that may not be necessary in this initial deployment; rate limiting and monitoring are important but secondary considerations to immediate token security.

Rate limiting is a critical defense mechanism against brute-force attacks targeting API keys. While validating input and sanitizing data are important for preventing injection vulnerabilities, they don't address the core problem of unauthorized access through compromised or stolen API keys. Storing keys in code is extremely insecure.

Defense in depth is a layered security approach. The key element is redundancy – if one layer fails (e.g., a firewall bypass), other layers will still provide protection. It's not just about having multiple controls, but ensuring those controls operate independently and contribute to overall resilience.