Quiz - The signed-in session
Most of your app sits behind auth; only a landing page, /sign-in, and /sign-up are public. You pick the matchall-minus-public matcher and a teammate asks why you didn’t just allowlist the protected sections. What’s the load-bearing reason?
Matchall-minus-public fails closed — forget to exclude a new public page and it’s locked, which you notice in seconds; an allowlist fails open, so a protected section you forget to add ships ungated and silent.
Matchall-minus-public is the only strategy that lets the proxy skip the database, so an allowlist would force a getSession call on every matched request.
An allowlist can’t express the auth pages, so the inverse gate that bounces signed-in users off /sign-in only works under matchall-minus-public.
You enable changeEmail with enabled: true and nothing else, then wire sendChangeEmailConfirmation to send the verification link to the user’s current address rather than the new one. Why send it to the address they’re leaving?
It proves the requester controls the account right now — closing the path where an attacker with a briefly-stolen session changes the email to one they own and locks the real owner out.
The new address can’t receive mail until user.email has already been flipped, so the current address is the only inbox able to receive the token.
Sending to the new address would leak the existence of the account to whoever owns it, reopening user enumeration.
On /settings/security/sessions, a user is signed in on a phone, a laptop (the one they’re using), and a desktop. Which statements about the revoke buttons and their effects are true? Select all that apply.
“Sign out other devices” (revokeOtherSessions) drops the phone and desktop but leaves the laptop signed in — the same revocation a password change can fire automatically.
“Sign out everywhere, including this device” (revokeSessions) clears the current cookie too, so the laptop also lands on /sign-in.
Right after the phone is revoked, its still-open tab can keep loading pages for a few minutes before it’s bounced.
The instant the delete runs, every revoked device is signed out — revokeSession takes effect immediately on all of them.
revokeOtherSessions spares the current session (and is the same endpoint changePassword({ revokeOtherSessions: true }) triggers), while revokeSessions kills it too and clears the cookie. And revocation is eventually consistent: with the cookie cache on, a revoked device reads its cached decode until the window lapses — so the toast must say so, or you disableCookieCache on the sensitive subtree.You need to render rich text from a CMS, so you reach for dangerouslySetInnerHTML. Which discipline actually keeps it from becoming an XSS hole?
Sanitize with an allowlist (e.g. DOMPurify) on the server, so the un-sanitized HTML never reaches the browser — and sanitize even “trusted” sources.
Sanitize in the client component right before the prop receives it, so the cleaning happens as late as possible against the freshest input.
Blocklist the dangerous tags — <script>, <iframe>, <object> — and let everything else through, since those are the tags that execute.
dangerouslySetInnerHTML bypasses React’s auto-escaping, so the input must be sanitized first — server-side, in the Server Component, so the raw string never crosses the wire (sanitizing client-side already shipped the dangerous payload). Use an allowlist, not a blocklist: you’ll never finish enumerating every dangerous tag, and the attacker only needs the one you forgot. Sanitize even trusted sources, since any input may become reachable.Quiz complete
Score by topic