HTTPS, TLS and web security basics every site owner should know

A client once asked me why their site showed a padlock but their payment provider's fraud team still flagged transactions as "insecure origin." The answer was that HTTPS was configured, but their TLS setup allowed an outdated cipher suite from 2011, and their server sent no security headers at all. The padlock told visitors nothing about that. HTTPS is necessary but it's the floor, not the whole picture.

What actually happens during the handshake

When a browser connects to an HTTPS site, it and the server perform a TLS handshake: the server presents a certificate signed by a certificate authority, the browser verifies that signature against a list of trusted authorities baked into the OS or browser, then both sides negotiate a shared symmetric key for the session using asymmetric cryptography just for that negotiation step. Everything after that handshake is encrypted with the fast symmetric key, which is why HTTPS doesn't meaningfully slow pages down despite the extra round trip at connection time.

The three certificate tiers, and when the fancy ones matter

Domain Validation (DV) certificates only prove you control the domain and can be issued automatically in minutes — this is what Let's Encrypt provides for free and it's sufficient for the overwhelming majority of sites. Organization Validation (OV) additionally verifies the legal entity behind the domain. Extended Validation (EV) requires a much deeper legal and business verification. Browsers stopped visually distinguishing EV certificates around 2019, so for most small sites, the extra cost and paperwork of OV or EV buys reassurance for enterprise procurement checklists, not a better visitor experience.

HSTS: telling browsers to never even try HTTP

Even with HTTPS configured, a browser's first request to your domain often goes out over plain HTTP by default, then gets redirected. The Strict-Transport-Security header fixes this by telling browsers, after the first successful visit, to never attempt an HTTP connection to your domain again for a specified duration — closing the small window where a network attacker could intercept that initial request. Setting it with a long max-age and the includeSubDomains directive is a five-minute server config change with a real security benefit.

Headers most small sites forget entirely

Beyond HSTS, four headers do a disproportionate amount of protective work: Content-Security-Policy restricts which scripts and resources a page is allowed to load, meaningfully reducing the blast radius of a cross-site scripting bug; X-Content-Type-Options: nosniff stops browsers from guessing file types in a way attackers can exploit; Referrer-Policy controls how much of your URL leaks to external sites when someone clicks a link; and Permissions-Policy restricts which browser features like camera or geolocation a page can request. None of these require touching application code, only server or CDN configuration.

Mixed content: the silent padlock-breaker

A page served over HTTPS that loads even a single image, script, or stylesheet over plain HTTP will show a broken or missing padlock in most browsers, and modern browsers block mixed active content like scripts outright. This usually creeps in through an old hardcoded http:// URL in a theme, a third-party widget, or an embedded video. Run your live site through a browser's developer console and check for mixed-content warnings after any redesign or migration.

Testing your actual configuration

Don't trust the padlock icon alone. Qualys SSL Labs' free SSL Server Test grades your TLS configuration and flags outdated protocol versions like TLS 1.0/1.1 that should be disabled, weak cipher suites, and certificate chain problems. securityheaders.com does the equivalent for your HTTP response headers. Both take under a minute and routinely surface issues on sites that looked fine at a glance.

Security basics, answered directly

Is a free Let's Encrypt certificate less secure than a paid one? No, the encryption strength is identical; paid certificates buy longer validity periods, warranty guarantees, and sometimes OV/EV identity verification, not stronger cryptography.

Do I need HTTPS on a purely informational site with no login or payment forms? Yes, browsers now flag any HTTP page as "Not Secure" regardless of content, search engines use HTTPS as a minor ranking signal, and it also prevents your visitors' traffic from being tampered with or injected with ads by intermediate networks.

How often do TLS certificates need renewal? Let's Encrypt certificates last 90 days and are meant to be renewed automatically via a scheduled tool like certbot; commercial certificates typically run 1 year following industry-wide moves to shorten maximum validity periods.

Can HTTPS alone stop a data breach? No, HTTPS protects data in transit between browser and server, but does nothing for data at rest in your database, weak admin passwords, or vulnerable plugins — it's one layer of a much larger security posture.

Certificate pinning and why most sites should avoid it

Certificate pinning locks a site or app to trust only a specific certificate or public key rather than any certificate signed by a trusted authority, which sounds like extra security but creates a serious operational risk: if that pinned certificate needs emergency replacement and the pin isn't updated everywhere in time, you lock out your own legitimate users. It's appropriate for high-security mobile apps with controlled update cycles, and a liability for most ordinary websites.

Subresource Integrity for third-party scripts

When you load a script from a third-party CDN, adding an integrity attribute with a cryptographic hash of the expected file content lets the browser refuse to execute that script if the CDN is compromised and serves altered code, which has happened to real, well-known CDNs before. It costs one extra attribute per script tag and closes a supply-chain attack vector that HTTPS alone does not address.

The certificate transparency log as a monitoring tool

Every publicly trusted certificate issued for your domain gets logged in a public, searchable certificate transparency log, and services like crt.sh let you monitor that log for free. This catches a scenario HTTPS itself can't prevent: someone fraudulently obtaining a certificate for your domain through a compromised registrar or DNS provider. Checking it periodically, or setting up an alert, is a cheap way to catch domain-level compromise early.