Security
Security capstone: multiple-choice review
Six questions that cut across the entire security track. None is a definition to recite — each is a decision in a real secure-web-app threat model, where the breach almost always lives in the seam between two controls that each looked correct alone.
Confirm you can compose the whole track — access control, OAuth/OIDC, JWT validation, CSRF defense, password hashing, secrets, and supply chain — into one threat model, and tell which layer actually stops a given attack.
A logged-in user sends GET /accounts/{id}/statements with a valid, correctly-signed JWT but an id that isn't theirs, and reads a stranger's data. Which layer failed, and what fixes it?
Your SPA receives an OIDC ID token and an access token. A junior wires the API to authorize calls by reading the ID token's claims. Why is that wrong?
A pentester takes a valid RS256 JWT, flips the header to alg:HS256, sets role:admin, and re-signs it using your published JWKS public key as the HMAC secret — and the server accepts it. Root cause?
A team moves session auth from a localStorage JWT to an HttpOnly cookie to stop XSS theft. What new exposure does this open, and how do you close it?
A breach dumps your users table. Which storage choice means 'they'll get a few trivially weak passwords and then give up,' rather than 'everything common is cracked by Monday'?
Your app code is flawless, yet CI gets owned during npm install: a package resolved from the public registry at version 9.9.9 over your internal one. What class is this, and the primary defense?
The through-line of the whole track is one threat model: a single sensitive request passes through transport, authentication, authorization, input handling, secrets, and supply chain — and the breach lives in the seam, not inside any one layer. AuthN proves who; AuthZ decides what they may touch (A01). An OIDC ID token identifies the user while the access token authorizes the API, validated by signature, iss, aud, exp. A JWT is trustworthy only when you pin the algorithm. Moving a token to an HttpOnly cookie trades XSS theft for CSRF, closed with SameSite plus a token. Passwords need a slow, salted, memory-hard KDF. And the install step is your real attack surface — scope packages, pin a registry, enforce lockfile integrity.