How HTTPS works: TLS certificates, HSTS, CSP and secure cookies explained

1. Understand the certificate’s role in a visit

When a browser connects over HTTPS, TLS establishes encrypted communication. The browser checks the certificate against the requested hostname and trusted issuers. The certificate identifies the names it covers, its validity period and the information needed to build a trusted chain.

Make a list of public names such as the root domain, “www” and service subdomains. Check each intended name and note which provider manages its certificate. A CDN and the origin server may have separate certificates with separate renewal arrangements. The OWASP TLS guidance helps teams choose supported protocols and maintain their configuration. Recording the negotiated protocol during a connection gives that review a concrete observation. Plan for shorter lifetimes as well: publicly trusted TLS certificates issued since March 15, 2026 are valid for at most 200 days, falling to 100 days from March 15, 2027 and 47 days from March 15, 2029, so renewal has to be automated and monitored.

2. See how the layers complement each other

Think of these controls as complementary instructions. The certificate supports the connection, while the headers describe how a particular response should behave. Different pages can have different purposes: a public article, account page and intentionally embedded widget each benefit from a policy that reflects their role.

3. Build CSP from the resources people use

Content Security Policy describes allowed resource sources and browser behaviors. Begin with an inventory of scripts, images, fonts, network connections and frames. Walk through the whole journey so the list includes payment, authentication and support resources that appear after an interaction.

Use Report-Only mode to observe how a proposed policy matches actual use. Report-Only works only as an HTTP response header, not in a <meta> tag. Review the browser console or configured reporting destination, associate each message with its resource and decide the intended rule. After representative journeys are reviewed, apply the tested policy. Nonces or hashes provide a way to authorize specific scripts. A documented resource inventory makes future additions easier to evaluate and gives the team a clear explanation for each permission.

4. Make HTTPS a consistent habit for the browser

HSTS tells a browser to use HTTPS for a host for a chosen period. The browser learns the policy from a valid HTTPS response and applies it on later visits. Select an initial duration your team can comfortably review, confirm the behavior and extend it according to your operating plan.

The includeSubDomains option extends the policy to subdomains, so connect that choice to your domain inventory and HTTPS setup. Preloading adds the domain to a list built into browsers, so HTTPS applies from the very first visit. The preload list submission site now recommends HSTS but not preloading for most sites, because Chrome and Safari already upgrade HTTP navigations to HTTPS, and removing a domain from the list takes months. If you still choose to preload, treat it as a long-term commitment that covers every subdomain. The MDN HSTS explanation describes how these options work together.

5. Match cookies and headers to the journey

A session cookie lets the service recognize a continuing visit. Secure tells the browser to send the cookie only over HTTPS (localhost is the exception). HttpOnly stops JavaScript on the page from reading the cookie, for example through document.cookie. It does not encrypt the cookie or stop the browser from sending it with matching requests, so it limits cookie theft through XSS without preventing XSS itself. SameSite controls whether the cookie is sent with cross-site requests. Choose its value around the intended sign-in and return flow and set it explicitly, because browser defaults differ; a cookie with SameSite=None must also be Secure.

Other headers refine content handling. X-Content-Type-Options: nosniff makes the browser block scripts and stylesheets served with the wrong MIME type and stop guessing the type of other responses, so every response needs a correct Content-Type. Referrer-Policy controls how much referrer information the browser includes in the Referer header. For framing, the CSP frame-ancestors directive lists the pages allowed to embed yours; it works only as an HTTP header, not in a <meta> tag, and X-Frame-Options: DENY or SAMEORIGIN remains a fallback for older browsers. The OWASP header reference is a useful guide for choosing these settings. Write down the purpose of each header so application, proxy and CDN configuration express a coherent policy.

6. Observe the finished experience

Open a normal page request in browser developer tools and follow its redirects to the final response. Inspect the certificate, headers and cookies actually delivered. This connects the configuration to the visitor’s experience and shows which service contributes each setting. For a header-by-header lookup with DevTools or curl and safe starting values, see the security headers check.

1. Visit the supported public hostnames over HTTPS.
2. Record certificate details and the final response policy.
3. Complete sign-in, account recovery, an embedded payment and any return from an external service.
4. Review console observations and the chosen reporting destination.

Keep a dated configuration record and note who manages each layer. When hosting or an integration changes, use the same journey to verify the intended behavior. Roll out changes in stages and keep the previous configuration ready to restore. The resulting checklist also gives future maintainers a practical introduction to the website.

To check the headers of one site now, use the free security headers checker.

7. Keep the protection map close to the website

Record public names, certificate owners, browser resources and important journeys in one place. Sitelemetry can help organize observable TLS and response-header checks for that review.

The free Launch Readiness Snapshot runs eight passive checks on one public origin without signup, including the TLS certificate and the security headers the home page returns. It makes one TLS handshake and checks that the chain is trusted, that the certificate does not expire within 30 days and that the negotiated protocol is TLS 1.2 or 1.3; it does not list every supported TLS version or cipher suite. For headers, it mostly checks whether each one is present. The result is one score with a separate hardening grade and up to three signals to look at first, not a header-by-header report. It is not a pentest.

The website security audit guide explains how these layers connect to accounts, permissions and everyday maintenance.