Web Application Security Fundamentals and Threat Modeling
Core concepts
A candidate must be fluent in the CIA triad as applied to web apps, the difference between a threat, a vulnerability, and a risk, and the trust-boundary concept: every point where data crosses from an untrusted zone (browser, third-party API, partner) into a trusted one (server logic, database) is a place to validate and authenticate. Know the OWASP Top 10 categories as themes (broken access control, injection, insecure design, misconfiguration, vulnerable components, identification/authentication failures, integrity failures, logging failures, SSRF) rather than memorized rankings, and know STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) as a per-element checklist mapped to data flows.
Threat modeling in practice
Understand the four-step loop: decompose the application (DFDs, entry points, assets, trust boundaries), enumerate threats (STRIDE or attack trees), rate them (DREAD-style or likelihood × impact), and decide mitigations with a documented residual risk. Know that threat modeling is cheapest at design time and that it produces requirements, not test cases.
Traps
Questions conflate threat (a potential actor/event) with vulnerability (a weakness) and risk (likelihood × impact). Another trap: assuming a WAF or input filtering removes the need for threat modeling, or that threat modeling is a one-time phase. Also watch for "least privilege" being offered as an answer to a design question where the real answer is a missing trust boundary.
Rule of thumb
If you cannot draw the boundary and name the asset on each side, you cannot rate the threat. Model the flow first, then the threat, then the control.
Worked example
A checkout page calls a partner fraud API. Draw the boundary at that call, ask what the partner can send back (STRIDE: tampering, spoofing), and require signed responses plus schema validation before the data reaches order logic.