Chapter 12Lesson 4

Quiz - URLs, origins, and security boundaries

Quiz progress

0 / 0

You build a search URL by hand: `?q=${encodeURIComponent(searchTerm)}`. Later, on the server, you parse it with new URLSearchParams(req.url.search). A user searches for the literal string a+b. What goes wrong?

Nothing — encodeURIComponent and URLSearchParams agree on every character, so the round trip is safe.

encodeURIComponent leaves the + untouched, and URLSearchParams decodes that + as a space — so the search term comes back as a b.

URLSearchParams throws because the query string was not built by a URLSearchParams instance.

The two tools disagree about +. In a form-urlencoded query, + means space, so URLSearchParams reads a+b as a b. The fix is a posture, not a character lookup: encode and decode with the same model end to end — do both with URLSearchParams.

Your base URL comes from a validated environment variable at boot, while a next redirect target comes from a query string a user controls. Which construction pattern fits each?

Use new URL() for the env-derived base and let it throw; guard the user-supplied next with URL.canParse() before parsing.

Wrap both in try/catch so neither can ever crash the request.

Use URL.canParse() for the base and new URL() for next, since user input is the one you want to fail fast on.

The rule splits by trust. A malformed config value is a deploy bug you want to fail fast and loud, so let new URL() throw. Bad user input is data you fully expected to receive, so guard it with URL.canParse() instead of throwing.

Classify the pair https://a.github.io and https://b.github.io on both axes.

Same site (they share github.io), different origin.

Different origin and different site — github.io is on the Public Suffix List as an eTLD, so the registrable domain is the whole a.github.io.

Same origin and same site — they only differ by a subdomain label.

”Same site = last two labels” is the shortcut that breaks here. github.io is an eTLD on the Public Suffix List, so eTLD+1 is the full a.github.io / b.github.io — two unrelated owners, two different sites.

A developer wires account deletion to GET /account/delete?id=42 and assumes the same-origin policy protects it from evil.com. Why is the account still deletable from an attacker’s page?

The same-origin policy gates the response read, not the request. The GET fires (e.g. from an <img>), the session cookie attaches, the delete runs — and no CORS error ever appears because the attacker never needed to read the response.

The same-origin policy only applies to fetch, so embedding the URL in an <img> bypasses it entirely as a loophole.

It is protected — the browser would block the cross-origin GET and show a CORS error, so the account is safe.

The policy protects the user (confidentiality of the response), not the server. It blocks the read, never the request. State changes belong behind POST/PUT/PATCH/DELETE, defended by SameSite cookies and CSRF tokens — never a GET.

Which of these cross-origin fetch calls trigger a preflight OPTIONS request? Select all that apply.

A POST sending Content-Type: application/json.

A GET carrying an Authorization: Bearer … header.

A plain GET with no custom headers and no body.

A request is “simple” only when method, headers, and Content-Type all stay on the CORS-safelist. application/json is not safelisted, and Authorization is not a safelisted header — so both preflight. The working reality: any JSON or token-bearing call preflights, which is nearly your whole authenticated API surface.

Your client sends fetch(url, { credentials: 'include' }) and the server replies with Access-Control-Allow-Origin: * plus Access-Control-Allow-Credentials: true. The browser blocks the read. What is the fix?

Validate the incoming Origin against an allow-list, echo that exact origin back in Access-Control-Allow-Origin, and add Vary: Origin.

Change the client to credentials: 'same-origin' so the wildcard becomes legal again.

Add Access-Control-Max-Age so the browser caches the preflight and stops re-checking the wildcard.

The wildcard is legal only without credentials — “anyone may read this, with the user’s cookies attached” is the one combination the browser forbids. Echo the exact validated origin instead, and because the response now depends on Origin, send Vary: Origin so caches key by origin.

A cross-origin call fails with the console error “Response to preflight request doesn’t pass access control check: It does not have HTTP ok status.” Where is the bug?

The OPTIONS preflight handler returned a non-2xx status — it should return 204 with the CORS headers.

The client fetch call set the wrong mode; switch it to 'no-cors'.

Access-Control-Allow-Origin is missing from the real request’s response — add it to the GET/POST handler.

This error is specifically about the preflight round trip. The browser sent an OPTIONS and got back a non-OK status, so it cancelled the real request. A CORS error is almost always a server fix — here, make the OPTIONS export return 204 with the headers.

Quiz complete

Score by topic