The Complete Guide to Web Security in 2026

Web security is not a single feature you bolt on at the end of a project. It is a stack of protocols, headers, and configurations that work together. Get one layer wrong and the others cannot compensate. This guide covers every layer that matters for a production website in 2026, from TLS negotiation up through cookie flags.

SSL/TLS Fundamentals

SSL (Secure Sockets Layer) is dead. SSLv2, SSLv3, and even TLS 1.0/1.1 are all deprecated by RFC 8996. When someone says “SSL” today, they mean TLS — specifically TLS 1.2 or TLS 1.3. The protocol sits between TCP and HTTP, encrypting the channel so that plaintext never crosses the wire.

TLS provides three guarantees: confidentiality (encryption prevents eavesdropping), integrity (MAC codes detect tampering), and authentication(certificates prove you are talking to the right server). If any of these fail, users see browser warnings — and most of them leave.

The TLS Handshake

Before any HTTP data flows, the client and server negotiate a shared secret. In TLS 1.2 this takes two round-trips: ClientHello → ServerHello+ certificate → key exchange → Finished. TLS 1.3 collapses this to a single round-trip by combining the key share with ClientHello. That difference alone shaves 50-100ms off every new connection, which matters for Time to First Byte (TTFB).

The handshake also decides the cipher suite. TLS 1.3 removes all legacy ciphers: no more RSA key exchange, no CBC mode, no SHA-1. The only key exchange available is ephemeral Diffie-Hellman (ECDHE), which provides forward secrecy by default. This means that even if your private key is compromised later, past traffic stays encrypted.

TLS 1.2 vs TLS 1.3

If you still support TLS 1.2, restrict cipher suites to ECDHE+AESGCM or ECDHE+CHACHA20POLY1305. Anything else is a liability. For a deeper look at certificate setup, see our SSL/TLS Certificates guide.

Certificate Types

Certificates come in three validation levels: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). DV certs only prove you control the domain — Let's Encrypt issues them free in minutes. OV and EV add identity verification, but browsers no longer display a green bar for EV, so the practical benefit is mostly for compliance paperwork. Pick DV for most sites. Pick OV/EV if your auditor demands it.

HTTP Security Headers

Security headers are response headers that tell the browser how to behave. They cost nothing to deploy — a few lines in your web server config — and they block entire categories of attacks. Despite this, most websites ship zero security headers. Our scanner checks seven of them. Here is what each one does and why it matters.

For a more detailed walkthrough with example configurations, see What Are HTTP Security Headers and Why They Matter.

Content-Security-Policy (CSP)

CSP is the single most effective defense against Cross-Site Scripting (XSS). It tells the browser which sources are allowed to load scripts, styles, images, fonts, and other resources. If a script is injected that does not match the policy, the browser blocks it.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

The key directives: default-src sets the fallback, script-src controls JavaScript origins, object-src 'none' kills Flash and Java embeds, and frame-ancestors 'none' replaces X-Frame-Options for modern browsers. Avoid 'unsafe-inline'for scripts — use nonces or hashes instead. The full spec is at MDN: Content-Security-Policy.

Strict-Transport-Security (HSTS)

HSTS tells the browser: “Never connect to this domain over plain HTTP again.” Once the browser sees this header, it upgrades all future requests to HTTPS automatically, even if the user types http://. This kills SSL-stripping attacks.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

max-age is in seconds — 63072000 is two years. includeSubDomains applies to all subdomains. preload lets you submit your domain to the HSTS preload list, which is hardcoded into browsers. Once preloaded, there is no first-visit vulnerability. Defined in RFC 6797.

X-Frame-Options

Prevents your site from being embedded in an <iframe> on another domain. This stops clickjacking attacks where an attacker overlays invisible frames to hijack clicks.

X-Frame-Options: DENY

DENY blocks all framing. SAMEORIGINallows framing by your own domain. CSP's frame-ancestors directive is the modern replacement, butX-Frame-Options is still needed for older browsers. See MDN: X-Frame-Options.

X-Content-Type-Options

Stops browsers from MIME-sniffing a response away from the declared Content-Type. Without this header, a browser might interpret a text file as JavaScript and execute it.

X-Content-Type-Options: nosniff

There is only one valid value: nosniff. Always set it. It is one line of config and blocks a real attack vector. Spec: MDN: X-Content-Type-Options.

Referrer-Policy

Controls how much URL information the browser sends in the Refererheader when navigating between pages. The default behavior leaks full URLs — including query parameters that may contain tokens, session IDs, or PII.

Referrer-Policy: strict-origin-when-cross-origin

This sends the full URL for same-origin requests but only the origin (e.g., https://example.com) for cross-origin requests. For maximum privacy, use no-referrer. Spec at MDN: Referrer-Policy.

Permissions-Policy

Formerly Feature-Policy. Controls which browser features your page can use: camera, microphone, geolocation, payment, USB, and dozens more. If you do not use them, disable them.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Empty parentheses () disable the feature entirely. This prevents malicious scripts from accessing hardware even if they somehow execute on your page. Full list at MDN: Permissions-Policy.

Cross-Origin-Opener-Policy (COOP)

COOP isolates your browsing context from other origins. Without it, a page opened via window.open can retain a reference to the opener and potentially interact with it. COOP severs that reference.

Cross-Origin-Opener-Policy: same-origin

Setting same-origin means only pages from the same origin can share a browsing context group. This is also required (along with COEP) to enable SharedArrayBuffer and high-resolution timers that were restricted after Spectre. Spec: MDN: Cross-Origin-Opener-Policy.

Cross-Origin Resource Sharing (CORS)

CORS is not a security feature you add — it is a relaxation of the Same-Origin Policy that browsers enforce by default. When your frontend at app.example.com calls an API at api.example.com, the browser blocks it unless the API responds with the correct CORS headers.

The critical headers: Access-Control-Allow-Origin specifies which origins can make requests, Access-Control-Allow-Methods lists allowed HTTP methods, and Access-Control-Allow-Credentials controls whether cookies are sent.

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

The number one mistake: setting Access-Control-Allow-Origin: * while also setting Access-Control-Allow-Credentials: true. Browsers refuse this combination for good reason — it would let any site make authenticated requests to your API. Always whitelist specific origins. Never reflect the Origin header back without validation. Spec: RFC 6454 (Origin) and MDN: CORS.

Cookie Security

Cookies carry session tokens, CSRF tokens, and user preferences. An insecure cookie is a direct path to session hijacking. Every authentication cookie must have these flags:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=86400

• Secure— Cookie only sent over HTTPS. Without it, any HTTP request leaks the cookie in plaintext.
• HttpOnly— Cookie inaccessible to JavaScript. Blocks XSS-based session theft via document.cookie.
• SameSite=Lax— Cookie not sent on cross-origin POST requests. Stops most CSRF attacks. Use Strict if your site does not need cross-origin navigation with cookies.
• Path=/— Scope the cookie to the minimum path needed.
• Max-Age— Set an explicit expiration. Session cookies (no Max-Age) live until the browser closes, but persistent cookies should expire.

Cookie prefixes add an extra layer: __Secure- requires Secure flag, __Host- requires Secure, Path=/, and no Domain attribute. These are enforced by the browser and cannot be overridden by subdomain attacks. See MDN: Cookies.

HTTPS Enforcement

Having a certificate is not enough. You need to enforce HTTPS so that no user ever loads your site over plain HTTP. The enforcement chain:

1. Server-side redirect — Return 301 Moved Permanently from http:// to https://. Not 302 — a 301 tells browsers and search engines this is permanent.
2. HSTS header— After the first HTTPS response, the browser remembers to always use HTTPS for this domain (see HSTS above).
3. HSTS preload— Eliminates the first-visit vulnerability by hardcoding your domain into browser source code. Submit at hstspreload.org.

Without all three, there is a window where a user's first visit can be intercepted by an attacker on the same network (e.g., public Wi-Fi). This is not theoretical — tools like sslstrip automate it.

Redirect Chains and Mixed Content

A redirect chain is when a request passes through multiple redirects before reaching the final destination. Example: http://example.com → https://example.com → https://www.example.com. Each redirect adds latency and creates an opportunity for interception. Keep redirect chains to a maximum of one hop.

Mixed content happens when an HTTPS page loads resources (scripts, stylesheets, images) over plain HTTP. Browsers block mixed active content (scripts, iframes) entirely and warn on mixed passive content (images, video). Mixed content breaks the security promise of HTTPS because an attacker can tamper with the HTTP resources.

Fix mixed content by auditing all resource URLs. Use protocol-relative URLs (//cdn.example.com/script.js) or, better, always use https://. CSP can help catch it with the upgrade-insecure-requests directive, which tells the browser to automatically rewrite HTTP URLs to HTTPS:

Content-Security-Policy: upgrade-insecure-requests

Test Your Site

Our free scanner checks all of the above: TLS version, certificate validity, all seven security headers, mixed content, redirect chains, and more. You get results in 60 seconds with specific recommendations for each finding.

Scan My Website — Free