You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expert-level revision notes for web application security interviews (senior and staff security engineer). Each document is one topic, written as answers to the rabbit-hole follow-ups an interviewer asks, without the questions themselves. The content is grounded in real industry sources (PortSwigger Web Security Academy, OWASP cheat sheets and Top 10s, the relevant RFCs and protocol specs, and named public research), and each doc cites what it drew from.
This is a revision aid, not a tutorial. It assumes deep prior knowledge and reloads the technique-level detail fast: protocol breakdowns, concrete payloads, blind and out-of-band variants, escalation to RCE or account takeover, and the mitigations that actually hold.
Every doc follows the same shape
Mental model: the one-paragraph root cause.
How it works: the protocol or technology breakdown (wire format, headers, spec behaviors) where relevant.
Attack techniques: enumerated, each with the mechanism, a real payload or wire example, blind/OOB variants, how you confirm it, and why it works. Named techniques, CVEs, and researchers where sourced.
Defense: specific and ordered by effectiveness, separating the real fix from defense-in-depth.
Interviewer probes: 5-8 Q&A pairs, each with a mid-level answer and the principal-level answer that distinguishes it.
Sources: the real references used.
Each doc also carries an Interview frequency tag: Core (near-certain in any senior/staff appsec interview), Common (comes up often, not universal), Situational (depends on the role/domain matching), or Niche (real depth, rarely the actual focus). The Freq column below mirrors it.
One exception to the shape above: the Architectural controls docs (first section in the index below) are design checklists over one security-architecture decision, not one system. They fork by deployment context, compare realistic options in tables, and link out to the deep-dive docs instead of carrying their own How it works, Attack techniques, or Defense sections. See docs/adr/0003-architectural-control-doc-shape.md for the shape.
Design checklist forked by web/mobile/desktop/service-to-service: realistic options, modern defaults, and the sub-feature gaps each drags along (reset, remember-me, MFA recovery, deep-link interception, credential rotation)
The credential escalation ladder, HSM/TPM/TEE, envelope encryption/crypto-shredding, and the bearer-vs-proof-of-possession axis that decides when eliminating a secret beats storing it better
Where a stored object lives and who can reach it, forked by public/private/system-generated: presigned URLs vs authenticated proxies, envelope encryption, tenant isolation, SSRF in generation/import pipelines
4 Cs model, API server / kubelet / etcd, RBAC and service-account tokens, Pod Security Admission (PSA), NetworkPolicy, admission control (Kyverno/Gatekeeper), workload identity
HMAC-SHA256 vs JWT-signed vs mTLS webhooks, timestamp binding to prevent replay, constant-time compare, SSRF via webhook dispatch, at-least-once delivery + receiver-side idempotency
Suggested revision order
If you are cramming, prioritise by interview frequency: XSS, SQLi, access control/IDOR, SSRF, CSRF, auth/session, JWT, OAuth, then request smuggling and the caching/host-header trio, then the AI/agent docs if the role touches LLM or MCP integrations.
For AI/agent-heavy roles: start at hubs 30 → 31 → 32, then walk the OWASP LLM Top 10 series 33–43 in order, then agent-specific attacks 44–54, then protocol deep dives 55–62, then defenses 65–66.
Global reference libraries
These span almost every topic here and are worth bookmarking:
Docs follow a locked format: see CONTEXT.md for the section order and writing rules, and docs/adr/ for the ADRs that shaped it. A new topic can be authored with the /add-appsec-topic skill, which enforces the shape and runs a correctness/interviewer/sources review pass before writing anything to disk.
Before adding a new doc:
Check for an existing home first. Search the Index and grep docs/ for the topic. If it substantially overlaps an existing doc, extend that doc (a new attack technique, a new probe, an added source, a new diagram) instead of forking a near-duplicate. Two docs each covering 80% of the same ground is worse than one doc that covers it fully; it splits the reader's attention and the two copies drift out of sync over time.
Cross-link both directions. If the new topic relates to an existing one (a shared mechanism, a prerequisite, an attack that chains into another), link it from both sides: the new doc references the existing one, and the existing one gets updated to reference the new doc back. A one-way link is a dead end for a reader who lands on the older doc first; this repo already has a few of those to clean up as you touch adjacent docs.
Update the README in the same commit. A doc that exists on disk but is not in the Index below is invisible to a reader browsing the repo. This is enforced, not optional.
Open a PR. Small, focused changes (one new doc, one fix, one pass of cross-links) review faster than bundled ones.
Scope: web application security, plus the adjacent AI/agent surface (LLM integrations and MCP). Defensive and educational revision material.
About
Senior/staff-level revision notes for appsec interviews: 98 deep-dive docs on injection, access control, auth protocols, AI/agent security, and architecture reviews.