The browser is a willing ally when given the right instructions. Security headers are HTTP response headers that add browser-side protections with little implementation effort. Content-Security-Policy restricts which scripts, styles, and resources may load — and crucially which can be embedded as frames via frame-ancestors, which replaces the older X-Frame-Options. X-Frame-Options: DENY forbids framing entirely (maximum clickjacking protection), while SAMEORIGIN allows only same-origin framing. X-Content-Type-Options: nosniff tells browsers not to MIME-sniff away from the declared Content-Type, reducing content-type confusion attacks. Referrer-Policy controls how much of the URL is sent in the Referer header on outbound navigation, limiting leakage of sensitive paths or query parameters. The headers Sec-Fetch-Site, Sec-Fetch-Mode, and Sec-Fetch-Dest help servers understand a request's origin relationship, useful for origin validation.
Transport security deserves equal attention. HTTPS encrypts traffic in transit and prevents tampering between client and server; the HTTP Strict Transport Security (HSTS) header instructs browsers to only contact the site over HTTPS for a max-age period, defeating TLS downgrade attacks. POODLE (Padding Oracle On Downgraded Legacy Encryption) showed what happens when downgrade to SSL 3.0 is allowed, and Heartbleed (CVE-2014-0160) demonstrated that implementation bugs in TLS libraries can leak server memory, including private keys and session tokens. Mitigation strategies also include certificate pinning — restricting which certificates the client will trust for a host — and DNSSEC, which cryptographically signs DNS records so clients can verify answers were not tampered with in transit. Mixed content (an HTTPS page loading subresources over HTTP) breaks these guarantees and is blocked by modern browsers.
The Same-Origin Policy (SOP) is the browser rule that scripts from one origin can normally only read responses from the same origin (scheme + host + port). Same-site is looser, matching only the eTLD+1 (so a.example and b.example qualify), which is what SameSite cookies use. Cross-Origin Resource Sharing (CORS) is a controlled relaxation of SOP: a server opts in via headers such as Access-Control-Allow-Origin, and the browser sends a preflight OPTIONS request for non-simple requests to confirm allowed methods, headers, and origins. Two recurring mistakes break CORS: reflecting the Origin header into Access-Control-Allow-Origin (effectively disabling SOP for any attacker site) and combining Access-Control-Allow-Credentials: true with a wildcard or reflected origin, which lets third-party sites read authenticated responses. CORS is explicitly not an authentication or authorization mechanism — the server must still authorize every request.