Test what you understood — not what you memorized.
QUESTION 01 OF 05
In the 2019 Fortnite incident, how did the attacker steal authentication tokens without the victim entering their password?
Correct — a forgotten SSO page with an XSS-vulnerable redirect allowed an attacker to craft a link. When a victim clicked it, their browser was redirected through Epic's own OAuth flow, and the auth token was sent to the attacker. No password required.
Not quite — the Fortnite attack didn't need passwords or forged tokens. It exploited an abandoned OAuth redirect page combined with XSS. The victim clicked a link, their browser silently sent their existing auth token, and it was captured — all without any login form.
QUESTION 02 OF 05
A GraphQL API limits login attempts to 5 per minute. An attacker sends a single POST containing 50 login mutations in an array. How many attempts does the rate limiter see?
Correct — this is the GraphQL batching bypass. Rate limiting is typically applied at the HTTP request level. A batch of 50 mutations is still 1 HTTP request. The limiter sees 1. The login resolver processes 50. The fix: count operations inside a batch, not just the outer request.
Not quite — the issue is exactly that most rate limiters count HTTP requests, not inner GraphQL operations. One batched POST = 1 request to the limiter, but 50 login attempts to the resolver. This is the batching bypass and it's documented in the OWASP API2 scenarios.
QUESTION 03 OF 05
What does a JWT with {"alg":"none"} in the header allow an attacker to do?
Correct — if an API respects the algorithm specified in the token header and allows "none", it skips signature verification entirely. The attacker can write any user_id or role into the payload, omit the signature, and the API accepts it as a legitimate token issued by the server.
Not quite — the alg:none attack is about skipping signature verification, not about encryption or expiry. When a library respects the client-supplied algorithm and accepts "none", there's no signature check. The attacker writes whatever they want into the payload and the API believes it.
QUESTION 04 OF 05
Why does multi-factor authentication (MFA) stop credential stuffing, even when the attacker has the correct username and password?
Correct — credential stuffing succeeds because the attacker has a real, working password. But the second factor — a TOTP code from an authenticator app, a hardware key, a push notification to the owner's phone — is something the attacker doesn't have. The correct password is no longer enough.
Not quite — MFA doesn't rate-limit or encrypt anything. What it does is add a second proof of identity that the attacker physically doesn't have. A correct password from a breach list is useless if the next step requires a code from the victim's phone.
QUESTION 05 OF 05
An API passes auth tokens as URL query parameters: GET /export?token=abc123. Which of the following is a direct security consequence?
Correct — URL query parameters are logged by web servers, saved in browser history, and included in Referer headers when the user navigates to any third-party resource. A token that should last 1 hour can live in server logs for years. Tokens belong in Authorization headers, not URLs.
Not quite — the problem isn't brute force, encryption, or CORS. URLs are a persistence problem: they're saved in browser history, written to server access logs, and sent as Referer headers to any third-party site on the page. A short-lived token becomes a long-lived log entry.