Application & API Security
49 questionsDONEUNLOCKEDLOCKED
Application Security Interview Questions
Application and API security from input validation and authorization to source analysis and application security posture management (ASPM). Connect code findings, deployed services and accountable owners, including AI-generated code and remediation review.
Worked answers that start from a threat model, explain each control by mechanism, and include the follow-ups and scoring an interviewer uses.
You have 5 free answers unlocked here.Sign in free for 5 more · 39 are premium.
01–20Foundationsthe mechanisms and vocabulary an interviewer expects you to have0/20 done
21–38Core questionsthe questions this round asks most, answered in full0/18 done
39–49Field scenariosdesign rounds, incidents and judgment calls with the inputs left incomplete0/11 done
The concepts behind Application & API Security
The lessons these answers build on. Introductory ones are free; advanced ones need Premium.
Foundational
Injection VulnerabilitiesInjection happens when data from an untrusted source is combined with code for an interpreter, such as a SQL engine, a shell or a template engine, and the interpreter treats part of the data as instructions. The structural fix is to keep code and data in separate channels: parameterised queries, argument arrays instead of shell strings, sandboxed templates. Prompt injection is the same failure in an interpreter that offers no separate channel, which is why its defences look different.Foundational
Cross-Site Scripting and Output EncodingCross-site scripting (XSS) is injection into a browser: attacker-controlled content ends up in a page as executable script, running with the site's origin and the victim's session. It comes in stored, reflected and DOM-based forms. The fixes are contextual output encoding (frameworks do this by default), sanitisation when HTML must be rendered, and a strict Content Security Policy as a second layer. Chat interfaces that render model output as HTML or Markdown are a new and common source.Core
Content Security Policy in DepthA Content Security Policy is a response header the browser enforces for one document: it decides which scripts, styles, frames and connections the page may use, blocks the rest and can report violations. Host allowlists failed in practice because allowed domains host code an attacker can reuse. A strict policy trusts scripts by per-response nonce or by hash, propagates trust with strict-dynamic, and adds object-src and base-uri. Trusted Types closes DOM sinks. CSP limits XSS impact; it does not fix XSS or stop data leaving.Sign in
Foundational
Server-Side Request ForgeryServer-side request forgery (SSRF) happens when an application fetches a URL that an attacker can influence, letting the attacker use the server's network position to reach internal services, cloud metadata endpoints and admin interfaces. String checks on URLs are easy to bypass. Robust defences validate the resolved IP address, connect to that exact address, re-check redirects, prefer allowlists, and route outbound fetches through an egress proxy. LLM tools that fetch web pages are SSRF primitives by design.Core
Broken Access Control and IDORBroken access control covers every way a user acts outside their intended permissions: reading other users' objects by changing an ID (IDOR, or broken object-level authorization), calling privileged functions directly, changing fields they should not (mass assignment), or crossing tenant boundaries. It tops both the OWASP web and API risk lists because authorization must be correct on every endpoint. Central policy, object-level checks in the data layer and two-user tests prevent most of it.Sign in
Core
Insecure DeserializationDeserialization turns bytes back into objects. Formats that can describe arbitrary objects, such as Python pickle, Java native serialization and unsafe YAML loaders, can be made to call functions during loading, so untrusted input becomes code execution. The fix is to never deserialize untrusted data with such formats: use data-only formats like JSON, safe loaders, schemas, and for machine learning, safetensors instead of pickle-based checkpoints. Signing proves origin, not safety.Sign in
Advanced
How Browsers Separate Origins: SOP, CORS and CSRFThe same-origin policy lets a page send requests almost anywhere but stops its script reading responses from other origins. CORS is the server's way to relax that read restriction for chosen origins; it never stops a request being sent. CSRF is the attack that exploits sending: a cross-site page makes the victim's browser submit a request with the victim's cookies. The defences are separate: exact CORS allowlists for reads, and for writes a CSRF token, Fetch Metadata checks, strict content types and SameSite cookies as defence in depth.🔒 Premium
Advanced
HTTP/2, HTTP/3 and Request SmugglingRequest smuggling happens when a front-end and a back-end parse the boundaries of HTTP/1.1 requests differently, so bytes an attacker sends are treated as the start of the next request on a shared connection. HTTP/2 and HTTP/3 use binary framing that removes that ambiguity, but proxies that accept HTTP/2 and forward HTTP/1.1 reintroduce it, and the new protocols bring their own denial-of-service classes, such as Rapid Reset, which drove record attack rates in 2023. Defences are strict parsing that rejects ambiguous framing, HTTP/2 end to end, per-connection budgets for resets and headers, and care with QUIC's 0-RTT and visibility.🔒 Premium
Unlock all 49 answers · $25
Every worked answer in all 17 topics, every lesson in every course, the full concept curriculum, the complete practice-test bank, and the downloadable security field guides.
6 months · One payment · No auto-renewal