Web application security

18 questions drawn from the parts of this series. Answers here count toward each post's own quiz.

1. Question 1 of 18·StarterWhat is the main difference between threat modeling and a pentest?

   Threat modeling is only for the security team, while a pentest is done by the engineers who designed the systemThreat modeling finds design flaws in what is about to be built, when fixing is cheap (change a diagram), while a pentest finds exploitable vulnerabilities in what already runsThreat modeling can replace a pentest because it lists every risk exhaustivelyThreat modeling finds implementation bugs like injection, while a pentest finds design flaws
2. Question 2 of 18·IntermediateA worker runs inside the company VPC and processes files that outside users upload to S3. The team says it is "safe because it is on the internal network". Which statement is correct?

   Correct, because the VPC and security groups block all outside accessCorrect, as long as the worker scans for malware before processingWrong, but only because the worker needs its libraries updated regularlyWrong, because trust boundaries follow the origin of the data, not the network; file contents are bytes chosen by strangers, so sandboxing and least privilege are needed
3. Question 3 of 18·IntermediateReact escapes every value rendered as text. Why is XSS still a risk in a React app?

   React only escapes short strings; strings above some length are skippedReact's escaping can be switched off by CSP, so it must be re-enabled on the serverEscaping only covers text and attributes React manages; sinks like dangerouslySetInnerHTML, javascript: hrefs, JSON in script tags, direct DOM APIs or third-party libraries bypass itReact does not escape < and > characters in text nodes
4. Question 4 of 18·AdvancedWhy does the post recommend a nonce-based strict CSP with 'strict-dynamic' instead of a domain allow-list?

   Allow-lists are bypassable via endpoints on trusted domains (JSONP, script gadgets, uploads); a per-response nonce can't be guessed by someone injecting <script>, and 'strict-dynamic' lets trusted scripts load othersA nonce encrypts the script content so attackers cannot read the codeAllow-lists are not supported by modern browsers, so the policy has no effectA nonce can be reused across requests to take advantage of CDN caching
5. Question 5 of 18·IntermediateA colleague says "our API has strict CORS so we don't need to worry about CSRF". Why is this wrong?

   Because CORS only applies to GET requestsBecause CORS only relaxes read access to responses; simple requests like form POSTs are still sent and executed, the browser merely hides the responseBecause CORS only takes effect over HTTP, not HTTPSBecause the browser checks CORS after the server has processed the request, so the server can always reject it
6. Question 6 of 18·IntermediateWhy is setting Access-Control-Allow-Origin to the request's own Origin together with Allow-Credentials: true a vulnerability?

   Because browsers do not accept a specific origin when credentials are usedBecause it makes preflight always failBecause it only affects cache performanceBecause it trusts every origin, so any website can read logged-in users' personal data; with SameSite=Lax it is still open to every same-site origin, including a forgotten subdomain with XSS
7. Question 7 of 18·IntermediateWhy does RFC 9700 recommend PKCE for every client, even confidential clients that already have a client_secret?

   Because the client_secret can leak, so PKCE is a complete replacement for itBecause PKCE encrypts the authorization code while it passes through the browserBecause PKCE binds the code to the client that started the flow, so an intercepted code or one injected into an attacker's session is uselessBecause PKCE replaces state and nonce, so those parameters can be dropped
8. Question 8 of 18·IntermediateA SPA sends the ID token in the Authorization header to call an API, and the API accepts it because the signature is valid. What is the biggest problem?

   The ID token is issued for the frontend (aud is the client_id) and carries no scopes; the API is accepting a token meant for another application and loses scope-based authorizationID tokens are always opaque strings, so the API cannot verify the signatureID tokens expire faster than access tokens, so users will be logged out constantlyThere is no security problem, it is only a naming convention
9. Question 9 of 18·AdvancedThe server issues RS256 tokens and verifies with a function that takes the algorithm from the header. How does an attacker forge a token without the private key?

   Set alg to none and leave the signature empty.Set alg to HS256 and HMAC-sign using the public key string as the secret; the library uses that public key to verify and it matches.Point kid at /dev/null so the verifier uses an empty key.Brute-force the RSA private key from the public key in the JWKS.
10. Question 10 of 18·AdvancedIn scheduled JWKS key rotation, why publish the new key to the JWKS and wait before signing with it?

    So every verifier has time to cache a JWKS containing the new key, avoiding a window where new tokens get 401 due to an unknown kid and the refetch cooldown.So the old key expires automatically without being removed.So the CDN has time to compress the JWKS file.Because the JWKS can only be updated once a day.
11. Question 11 of 18·IntermediateThe GET /orders/:id endpoint already has an if comparing order.customerId with the current user. Why does the post still recommend moving ownership checks into the data layer (scoped repository)?

    Because an if in the controller runs slower than a where condition in the databaseBecause the JWT can be forged, so the controller cannot be trusted to read req.userBecause every new endpoint (invoice, CSV export, cancel order) can forget the if, while a repository that requires a scope cannot be bypassedBecause controller checks only work for read operations, not for writes
12. Question 12 of 18·AdvancedAn "import from URL" feature has the server fetch a user-supplied URL. Which SSRF defence is the most reliable?

    Reject URLs whose string contains localhost, 127.0.0.1 or private IP rangesResolve DNS once to check the IP, then let the fetch library resolve again when it connectsAllow only HTTPS, since an attacker cannot get a valid certificate for an internal IPCheck the IP the connection actually goes to, reject redirects, and put the worker behind an egress proxy
13. Question 13 of 18·AdvancedThe code resolves the hostname, checks the IP is public, then calls fetch(url). Why is it still vulnerable to SSRF, and what is the correct fix?

    A public IP can be changed to a private one by a router; re-check after receiving the response.fetch resolves the name again, so DNS rebinding can return a public IP at check time and 127.0.0.1 at connect time; validate and pin the IP inside the lookup the socket actually uses.Checking only IPv4 is not enough; adding an IPv6 check is all that is needed.Hostnames can contain Unicode characters; normalise the hostname before resolving.
14. Question 14 of 18·IntermediateA team serves user uploads from files.acme.com while the app runs on app.acme.com, believing this isolates them. What is wrong?

    Subdomains always share a certificate so they are easy to spoof.Subdomains do not support the Content-Disposition header.Subdomains are slower than a separate domain because of an extra resolution.The two subdomains are same-site: cookies scoped to .acme.com are still sent and SameSite does not protect you, so use a completely different registrable domain.
15. Question 15 of 18·IntermediateA dev accidentally pushed an API key to a repo. After deleting the file and force-pushing rewritten history, they consider it done. What is missing, and why is it the most important step?

    Notify GitHub so they remove the commit from every clone; after that the key is safeRename the repo so scanners can no longer find the keyRevoke or rotate the credential immediately, since the key is burned the moment it was pushed: clones, forks, pull request refs and scraping bots may already hold a copyAdd gitleaks to pre-commit so it does not happen again; the old key is no longer dangerous
16. Question 16 of 18·IntermediateWhy is using GitHub Actions OIDC to deploy to the cloud better than storing AWS_SECRET_ACCESS_KEY in GitHub secrets?

    Each workflow run exchanges a signed JWT for short-lived credentials scoped by repo/branch/environment, so there is no long-lived secret to leak or rotateBecause OIDC encrypts the static key more strongly than regular GitHub secretsBecause OIDC lets every repo in the org share one role without extra configurationBecause OIDC automatically masks every secret in logs, even base64-encoded ones
17. Question 17 of 18·AdvancedA new release of a package has valid provenance. What can you conclude?

    It is definitely safe because it was built in an authenticated CI.It is safe because npm scanned it for malware before issuing provenance.You only know which commit and workflow built it; if an attacker controls that workflow, the provenance is still valid.Provenance only proves the publisher had 2FA enabled.
18. Question 18 of 18·IntermediateWhy is a cooldown (rejecting versions newer than a few days) considered a good cost-to-benefit defense?

    Because malicious versions are usually detected and removed within hours to a day or two, so waiting long enough avoids most attacks.Because the cooldown verifies the signature of every version.Because the cooldown replaces lockfiles and frozen installs.Because the registry only allows downloading versions older than three days.