Security Engineer interview questions

I apply STRIDE to each data flow and trust boundary, then convert credible threats into testable security requirements.

• I start from a data-flow diagram containing processes, stores, external entities, flows, and privilege transitions.
• For each element I ask relevant STRIDE questions, such as spoofing at an identity boundary or tampering on a message queue.
• I record an attack precondition, affected asset, impact, existing control, owner, and verification method for each accepted threat.
• I discard impossible combinations explicitly so the team spends review time on reachable attack paths rather than filling every matrix cell.

I choose PASTA when business impact and attacker simulation must drive a deeper risk analysis, while STRIDE is faster for design-level coverage.

• PASTA links business objectives, technical scope, application decomposition, threat intelligence, weakness analysis, attack modeling, and risk decisions across seven stages.
• It suits a high-value payment or identity system where fraud paths and likely adversaries matter more than broad category coverage.
• It costs more workshop time and needs reliable architecture and threat data, so I would not impose it on every low-risk service.
• The output should still become owned mitigations and tests, not remain a presentation of hypothetical attacks.

I put account takeover at the root and decompose it into alternative and combined attacker goals until each leaf can be evaluated or controlled.

• OR branches could include credential stuffing, password reset abuse, session theft, and malicious support-assisted recovery.
• AND branches capture prerequisites, such as stealing a refresh token and bypassing device or risk checks before reuse.
• I annotate leaves with required access, likelihood, detectable signals, and control coverage rather than assigning unsupported numeric precision.
• The tree exposes shared mitigations, such as phishing-resistant WebAuthn blocking several credential-based branches at once.

A trust boundary is meaningful when data crosses into a context with different identity, privilege, ownership, or control guarantees.

• Common boundaries include browser to API, workload to database, tenant to shared service, and company network to a third-party webhook.
• A subnet line alone is not necessarily a boundary if both sides share the same compromised identity and authorization model.
• I label the protocol, authentication, authorization, encryption, parser, and validation performed at each crossing.
• I split diagrams until reviewers can see where untrusted input becomes trusted state or where privilege increases.

I inventory data, capabilities, identities, and availability-sensitive functions, then classify them by concrete harm if confidentiality, integrity, or availability fails.

• Assets include signing keys and admin actions as well as obvious records such as payment data or health information.
• I trace where each asset is created, processed, stored, logged, backed up, and deleted to find overlooked copies.
• Classification uses business and regulatory impact, such as account takeover, fraudulent payout, GDPR exposure, or missed recovery objectives.
• I validate the inventory with product, operations, and data owners because architecture diagrams rarely capture every business-critical capability.

Abuse cases describe how a hostile or unauthorized actor can misuse a valid feature, which exposes requirements that happy-path stories omit.

• For a coupon feature, I model enumeration, replay, race conditions, self-referral, and use across accounts rather than only malformed input.
• Each case names the actor, goal, preconditions, sequence, affected asset, and observable result.
• I turn credible cases into controls such as single-use state, atomic redemption, per-account limits, and audit events.
• Product owners help rank fraud loss and user friction, while engineers define enforceable server-side invariants.

I make every security-relevant assumption explicit, assign an owner, and link it to evidence or a verification task.

• An assumption such as only the gateway can call this service needs proof in network policy, workload identity, and a direct-access test.
• Third-party guarantees should cite a contract, configuration, or protocol property instead of relying on vendor reputation.
• I give assumptions review triggers for architecture changes, new data classes, incidents, and expired dependencies.
• An unverified assumption is tracked as risk because controls built on it may provide no real protection.

I use CVSS to describe technical severity and EPSS to estimate near-term exploitation probability, but neither replaces environment-specific impact and exposure.

• CVSS captures properties such as attack vector, privileges, user interaction, and confidentiality, integrity, and availability impact.
• EPSS is a probability model informed by observed exploitation signals, so a high score can raise urgency for an internet-facing asset.
• I add reachability, deployed version, compensating controls, asset criticality, exploit evidence from CISA KEV, and blast radius.
• The resulting decision and evidence go into the ticket so a score change or control change can be reassessed consistently.

I prioritize the threat with the stronger combination of reachable attack path, likely exploitation, business impact, and weak current controls.

• I compare prerequisites and exposure, such as an unauthenticated internet path versus an internal path requiring a privileged role.
• I estimate affected users, data, transaction value, lateral movement, and recovery cost rather than relying on the severity label alone.
• Active exploitation, a public proof of concept, CISA KEV listing, or poor detectability increases urgency.
• I document the deferred threat with a temporary control, named owner, expiry date, and explicit risk acceptance.

A finding is resolved only when the attack path, chosen treatment, implementation, and verification evidence are traceable.

• The record names the affected component and asset, attacker preconditions, impact, and relevant diagram flow or boundary.
• The decision states whether the risk is mitigated, avoided, transferred, or accepted, with an owner and deadline.
• A mitigation links to a requirement and evidence such as a unit test, authorization integration test, policy check, or reviewed configuration.
• Residual risk and assumptions remain visible, and material architecture changes reopen the finding for review.

A modern client uses Authorization Code Flow with PKCE S256 so tokens stay out of the authorization response and a stolen code cannot be redeemed alone.

• The front channel carries a short-lived, single-use code rather than an access token, reducing exposure through browser history, referrers, and redirect logs.
• Every public and confidential client creates a high-entropy verifier per authorization request, sends its S256 challenge, and requires the authorization server to bind the code to that challenge.
• A confidential client also authenticates at the token endpoint, while a public client does not rely on an embedded secret; client authentication does not replace PKCE.
• Exact registered redirect URIs, secure transaction storage, and appropriate token storage remain required around the code exchange.

PKCE binds the authorization request to the token exchange, preventing a stolen or injected code from being redeemed without the initiating client's verifier.

• The client sends an S256 challenge derived from a fresh high-entropy verifier and presents that verifier only at the token endpoint.
• PKCE can provide CSRF protection when the client has assured that the authorization server supports PKCE and that the returned code is bound to the initiating challenge, with downgrade prevented.
• State remains useful for carrying or correlating application state, and an unpredictable validated state value is still needed when reliable PKCE challenge binding cannot be assured.
• PKCE is recommended for confidential clients as well as public clients, but it does not replace redirect URI validation, confidential-client authentication, or protection of tokens after issuance.

OpenID Connect adds a standardized authentication layer that lets a client verify an end user's identity through an ID token and provider metadata.

• OAuth access tokens authorize API access and should not be interpreted by a client as proof of login.
• The ID token carries claims for the client, including issuer, subject, audience, issue time, and expiry.
• The client validates nonce when used to bind the ID token to its authorization request and prevent replay across login transactions.
• Discovery and JWKS endpoints standardize provider configuration and signing-key retrieval, but their values still need trusted issuer configuration.

The resource server treats RFC 9068 as a typed access-token profile rather than accepting any JWT with a valid signature.

• It requires `typ` to be `at+jwt` in the protected JOSE header and explicitly rejects an OIDC ID token at the API, even if that token has a valid signature.
• It verifies the signature with trusted issuer keys and an allow-listed algorithm, rejecting unsigned tokens, algorithm confusion, and keys from an unconfigured issuer.
• It validates the configured `iss`, confirms `aud` names this resource server, requires an unexpired `exp`, honors `nbf` when present with bounded clock skew, and requires `client_id` plus the other mandatory profile claims.
• It then enforces scopes and resource-level policy for the operation; an ID token is for a client to authenticate a user, not for an API to authorize access.

I choose opaque tokens when centralized revocation and minimal information disclosure outweigh the latency and availability cost of introspection.

• A resource server sends the reference token to an RFC 7662 introspection endpoint or checks a trusted cache.
• Revocation and policy changes take effect quickly, while a JWT normally remains valid until expiry unless an extra deny list is added.
• JWTs reduce authorization-server calls and suit distributed APIs, but claim staleness and leaked claim data require short lifetimes and careful audience scoping.
• The choice must include introspection caching, failure mode, token lifetime, and authorization-server capacity.

I use an opaque, high-entropy session identifier in a Secure, HttpOnly cookie and keep identity and authorization state on the server.

• SameSite=Lax is a practical default, while cross-site flows require narrowly justified SameSite=None with Secure and separate CSRF protection.
• I rotate the identifier after login and privilege changes to prevent session fixation and invalidate it on logout and administrative revocation.
• Idle and absolute timeouts limit theft impact, with shorter reauthentication windows for payment or account-recovery actions.
• The cookie has the narrowest Domain and Path possible, and state-changing requests use CSRF tokens or origin checks.

Refresh token rotation makes each successful refresh replace the previous token, allowing reuse of an old token to reveal likely theft.

• The authorization server stores the token family or a hashed reference and invalidates the presented token atomically when issuing the next one.
• Reuse of an invalidated family member revokes the family or affected session and triggers user or security notification.
• Rotation needs concurrency handling because two legitimate refreshes can otherwise look like replay.
• Sender-constrained tokens such as DPoP or mTLS further reduce replay, while short access-token lifetimes limit the remaining exposure window.

I use RBAC for stable job functions and add ABAC when decisions depend on resource, principal, or environment attributes that roles cannot express cleanly.

• RBAC is easy to review for roles such as support-agent or billing-admin, but many exceptions cause role explosion.
• ABAC can express tenant, data classification, ownership, device posture, or working-hours conditions through a policy engine such as OPA.
• Attribute issuers and mutation paths become trust boundaries, so privilege-bearing attributes need controlled schemas and audit logs.
• I keep default deny and test policies with allowed and forbidden cases because flexible policy syntax can hide broad access.

ReBAC fits collaborative systems where access follows a graph of relationships such as owner, editor, team member, folder parent, or organization.

• A document permission can derive from membership in a team that has viewer access to the containing project.
• Systems such as Zanzibar-style engines, OpenFGA, and SpiceDB evaluate tuples and relation rewrites consistently across services.
• The model must define inheritance, cycles, deletion, tenant isolation, and maximum traversal cost to avoid surprising grants or expensive checks.
• I still use attributes for contextual conditions and roles for coarse administration rather than forcing every rule into the graph.

I give each workload a short-lived identity bound to its runtime service account and authenticate service-to-service calls with mTLS or signed workload tokens.

• SPIFFE IDs and SPIRE can issue rotating X.509 SVIDs based on attested workload attributes rather than static shared secrets.
• A service mesh can enforce peer identity and encryption, but application authorization still decides which identified caller may invoke an operation.
• Kubernetes service account tokens should use projected, audience-bound, short-lived tokens rather than legacy long-lived secrets.
• Certificate issuance, trust-bundle rotation, clock health, and emergency revocation need monitoring because identity depends on that control plane.