298: Security Interview Review and Threat Modeling

Learning outcomes

By the end of this lesson, you should be able to:

explain and apply threat modeling in a realistic implementation;
explain and apply broken authorization in a realistic implementation;
explain and apply injection and XSS defenses in a realistic implementation;
explain and apply defenses against authentication and session threats in a realistic implementation;
explain and apply controls for SSRF, uploads, and secrets in a realistic implementation.

Prerequisites and retrieval

This lesson assumes that you have worked through the earlier 01–06 foundation and the preceding lessons in this module. Before you begin, retrieve one concrete example from a previous project where one of these concerns appeared. It might be an ownership check, an unsafe query, a session decision, or an operational control that you had to make explicit.

The purpose is not to memorize a list of security terms. In a realistic full-stack interview loop, your explanation, trade-offs, debugging process, code, and project evidence should all support the same decision. Retrieving a real example gives you something concrete to reason from instead of reciting vocabulary.

Terminology

Threat model: Identify the assets that need protection, the entry points and trust boundaries around them, the relevant actors, and the abuse cases an attacker might attempt.
Broken authorization: Reason about IDOR and resource ownership, tenant leakage, role and attribute policies, server-side enforcement, database scoping or RLS as a defense, and tests for denied requests.
Injection and XSS: Parameterize SQL, avoid shell and template injection, encode or sanitize for the correct HTML, URL, or JavaScript context, and use CSP or Trusted Types as defense in depth rather than as a substitute for correct handling.
Authentication/session threats: Account for credential stuffing, password hashing, MFA, secure cookies, CSRF, token theft, refresh-token rotation, logout and revocation, and validation of OAuth state, PKCE, and OIDC data.
SSRF/uploads/secrets: Allowlist and validate outbound destinations, prevent access to metadata networks, constrain and scan uploads before storing or serving them, and keep secrets in dedicated systems accessed through least-privilege identities.
Security operations: Audit logs, anomaly detection, dependency patching, key rotation, incident response, backups, and security tests keep controls maintainable after launch rather than leaving them as one-time implementation decisions.

Mental model

Treat Security Interview Review and Threat Modeling as a design problem with observable inputs, outputs, invariants, and failure modes. Start with the assets and trust boundaries, then describe what an attacker can do and which layered controls stop that path. Memorizing OWASP names is less useful than tracing one concrete abuse case from entry point to impact.

A strong implementation makes its assumptions visible, reduces uncertainty at boundaries, and leaves evidence that can be inspected. That evidence may be a test, a type, a database constraint, a metric, or a diagram. The point is to be able to explain why the design is safe and where that safety is enforced, not merely to claim that a library handles security for you.

A useful sequence for both an interview and production work is:

requirement -> constraints -> model -> implementation -> failure analysis -> verification

Do not jump from a requirement directly to a library call. First state what must remain true. Then choose the mechanism that enforces that invariant, and finally explain how you would verify it and diagnose a failure.

Deep dive

1. Threat model

Begin by identifying the assets, entry points, trust boundaries, actors, and abuse cases. Then prioritize the cases by impact and feasibility. State your environmental assumptions as well: for example, whether a service is reachable from the public internet, whether tenants share a database, or whether an operator can inspect production data. An unstated assumption is often where an otherwise polished security answer breaks down.

Decision rule: Use a threat model deliberately when it makes the contract or invariant easier to prove. If it only reduces typing while hiding an assumption, prefer the more explicit design.

2. Broken authorization

Authorization failures often look like ordinary successful requests. A user changes an ID in a URL, and the server returns another user's resource; a query omits the tenant predicate; or a role check exists only in the client. Explain IDOR and resource ownership, tenant leakage, role and attribute policies, and server enforcement. Database scoping or row-level security can provide another defense, but it does not remove the need to understand the application rule. Include deny-case tests, not only tests proving that an allowed user can read or change a resource.

Decision rule: Use authorization controls deliberately when they make the ownership, tenant, or role invariant easier to prove. If a helper or abstraction makes the code shorter while obscuring which resource is being authorized, prefer the more explicit design.

3. Injection and XSS

Keep data separate from instructions at every boundary. Parameterize SQL instead of constructing queries from strings, and avoid passing untrusted values into shells or templates. For browser output, encode or sanitize according to the context in which the value will be used: HTML, a URL, or JavaScript are not interchangeable contexts. CSP and Trusted Types can reduce the impact of mistakes, but they are defense in depth; they do not make incorrect input handling correct.

Decision rule: Use injection and XSS defenses deliberately when they make the data-versus-code invariant easier to prove. If a convenience API hides the output context or silently changes how a value is interpreted, prefer the more explicit design.

4. Authentication/session threats

Authentication establishes who the user is; the session mechanisms then determine how that identity is represented and protected across requests. Cover credential stuffing, password hashing, MFA, secure cookie settings, CSRF, token theft, refresh-token rotation, logout and revocation, and the validation required by OAuth, PKCE, and OIDC. The useful interview distinction is that authenticating once does not automatically make every later request safe: token storage, renewal, revocation, and request binding still matter.

Decision rule: Use authentication and session controls deliberately when they make the identity and session-lifetime invariants easier to prove. If a mechanism shortens the implementation while hiding token scope, renewal, or revocation behavior, prefer the more explicit design.

5. SSRF/uploads/secrets

Treat outbound destinations, uploaded files, and secret-bearing configuration as separate trust boundaries. Allowlist and validate destinations before making server-side requests, and account for paths to metadata networks rather than assuming that a hostname check is enough. Constrain uploads by the properties that matter to your system, scan them where required, and control how and where they are stored and served. Store secrets in dedicated systems and use identities with only the permissions they need.

Decision rule: Use SSRF, upload, and secret controls deliberately when they make the allowed-destination, allowed-file, or least-privilege invariant easier to prove. If a shortcut hides a network assumption or broadens access for convenience, prefer the more explicit design.

6. Security operations

Controls have to remain useful after deployment. Audit logs provide a record of security-relevant actions; anomaly detection can surface behavior that ordinary request validation will not; dependency patching and key rotation reduce long-lived exposure; and incident response, backups, and security tests make recovery and verification possible. These concerns are part of the design rather than tasks to postpone until after an incident.

Decision rule: Use security operations deliberately when they make the system's detection, recovery, or maintenance guarantees easier to prove. If an operational control creates data without a way to inspect or act on it, prefer an explicit, measurable design.

Worked example

Consider a realistic full-stack interview loop in which the explanation, trade-offs, debugging, implementation, and project evidence must agree. Start by writing the requirement in one sentence. List the input and output contracts, then identify which concept above owns each failure mode.

The key move is separation. Parsing and boundary validation belong at the boundary; domain rules belong in the domain or service layer; persistence rules belong in the database or repository; and presentation rules belong in the client. Mixing these concerns can make a happy-path demo look shorter, but it makes edge cases and security failures much harder to reason about.

Prompt -> clarify -> state assumptions -> solve -> test edge cases -> explain trade-offs

Walk through at least four cases: the normal path, an empty or missing value, a duplicate, retry, or concurrent path where relevant, and a dependency failure. For each case, say which layer detects the problem and what the caller observes. That level of precision is what a senior code review or technical interview is testing: not just whether the request succeeds, but whether the boundaries and failure behavior are intentional.

Production perspective

Production correctness is broader than “the code works on my machine.” Ask how the design behaves during deployments, retries, partial failure, stale clients, concurrent requests, malformed data, schema changes, and high-cardinality workloads. Prefer explicit contracts, bounded resource usage, structured errors, and measurable behavior. Optimize only after evidence identifies the bottleneck or the risk.

When an external dependency is involved, define both a timeout and a cancellation strategy. When persistence is involved, define transaction and consistency expectations. When the system exposes user-visible state, define loading, empty, error, stale, and success states. For security-sensitive behavior, assume the client can be modified and every network input is untrusted. A client-side check can improve the user experience, but it cannot replace server-side authorization or validation.

Guided lab

Threat-model one of your projects and answer a mock security review. Your review should include cross-tenant authorization, injection, XSS and CSRF, SSRF, file uploads, secrets, rate limiting, logging, and incident response.

Complete the lab with this discipline:

Write the requirement and two non-requirements.
List the input, output, and error contracts before implementation.
Implement the smallest correct vertical slice.
Add at least one invalid-input test and one edge-case test.
Instrument or inspect the behavior instead of guessing.
Refactor one hidden assumption into an explicit type, constraint, function, or configuration value.
Explain one alternative design and why you did not choose it.
Record a short “what would break at 10× scale?” note.

Edge cases and failure modes

Threat model: Test absence, malformed input, duplicates, ordering or concurrency where applicable, and behavior at the smallest and largest credible sizes.
Broken authorization: Test missing or malformed identity and resource data, duplicate or retried requests, ordering or concurrency where applicable, and behavior at the smallest and largest credible tenant or resource sizes.
Injection and XSS: Test absent and malformed values, repeated or duplicated input, ordering or concurrency where applicable, and behavior at the smallest and largest credible input sizes and output contexts.
Authentication/session threats: Test missing or malformed credentials, duplicate or retried authentication requests, ordering or concurrency where applicable, and behavior at the smallest and largest credible session and token lifetimes.
SSRF/uploads/secrets: Test absent and malformed destinations, files, and configuration, duplicate or retried operations, ordering or concurrency where applicable, and behavior at the smallest and largest credible payload and resource sizes.

The exact cases depend on the system, but the testing habit is consistent: include the absence case, malformed input, repetition, timing or ordering, and credible limits. Security controls are easier to trust when their deny behavior is observable and tested.

Common mistakes and debugging

Solving the example instead of the requirement: a copied pattern can be syntactically correct while being architecturally wrong for the actual trust boundary.
Hiding uncertainty with assertions, broad exception handlers, permissive schemas, or temporary any values. These may suppress evidence that an invariant has already failed.
Testing only the happy path, which means discovering the actual contracts only after integration.
Optimizing before measuring, or selecting a scalable mechanism without a scale requirement.
Letting client-side behavior stand in for server-side authorization, validation, or persistence guarantees.

When debugging, reproduce the smallest failing case first. Inspect the actual value or execution plan, trace the boundary where the invariant first became false, and fix the layer that owns the rule rather than adding a downstream patch. Check the source or build, browser or DOM, Network panel or HTTP exchange, server or route, database or query, and deployment or configuration boundary as appropriate. A normal result at one boundary narrows the search; an abnormal result tells you which layer to inspect next.

Interview questions

What problem does threat modeling solve, and what trade-off or failure mode would make you choose a different approach?
What problem does broken authorization solve, and what trade-off or failure mode would make you choose a different approach?
What problem do injection and XSS defenses solve, and what trade-off or failure mode would make you choose a different approach?
What problem do authentication and session controls solve, and what trade-off or failure mode would make you choose a different approach?
What problem do SSRF, upload, and secret controls solve, and what trade-off or failure mode would make you choose a different approach?

Checkpoint

Without notes, explain Security Interview Review and Threat Modeling to another developer in five minutes. Include one invariant, one edge case, one production failure mode, and one alternative design. Then implement a small example without copying the lesson code. Your explanation should make clear where the control is enforced and what evidence would show that it is working.

Mastery checklist

I can define the core terms precisely.
I can choose a design from requirements instead of from habit.
I can implement and test the normal path and edge cases.
I can explain the runtime, storage, or complexity cost.
I can identify which layer owns validation, errors, and recovery.
I can compare at least two reasonable alternatives.
I can explain how the design changes at larger scale or under stricter reliability requirements.