Website security does not start with antivirus software or a plugin. It starts with transport: how data travels between the browser and the server, and which instructions your server sends along with every page. That layer is free, takes little time to configure, and solves a large number of problems at once.
Why HTTP sites still exist and why that is a problem
HTTP sites still exist out of inertia. They were published when certificates were expensive, and nobody touched them afterwards. The problem is that without HTTPS everything travels in plain text. Any intermediate point on the network, a public network router, a badly configured provider, can read and alter the content in transit.
That does not only affect people filling in forms. It affects the integrity of the whole page: on an HTTP connection it is technically possible to inject code into a page before it reaches the visitor. And on the practical side, modern browsers flag the site as not secure in the address bar, which every visitor sees and reads as neglect.
There is also a treacherous middle case: mixed content. That is a site with a certificate that still loads an image, a script or a stylesheet over HTTP. The browser blocks part of those resources and the padlock disappears. After migrating, search the code for http:// references to your own domain.
Free vs paid SSL certificates: the real difference
The encryption is the same. A free Let's Encrypt certificate protects the connection exactly as strongly as an expensive one. What changes is the validation level and what comes bundled:
- Domain validation (DV): proves the requester controls the domain. That is what free certificates do, and it is enough for the overwhelming majority of sites.
- Organisation validation (OV) and extended validation (EV): the certificate authority checks company documents. Current browsers no longer give that any visual prominence, so the practical benefit for an ordinary site is small.
- Wildcard: covers every subdomain at once. Useful when you have many.
Let's Encrypt certificates last 90 days and renew automatically. That is exactly the catch: if automatic renewal is not working, the site breaks suddenly three months later. Set a reminder and an expiry monitor, a subject that also comes up in backup and continuity.
Forcing HTTPS without breaking SEO
Having a certificate is not enough if the HTTP version still answers. You need a permanent redirect, status 301, from HTTP to HTTPS.
Why 301 and never 302? Because 301 means moved permanently and passes the weight of the old address to the new one. A 302 means moved temporarily and signals to the search engine that the original address is still the official one. Using 302 for a protocol migration is asking for months of both versions competing with each other.
After the redirect, do three things: update the property in Search Console to the HTTPS version, update the sitemap URLs, and check that internal links and canonical tags point straight at https:// without going through the redirect. Every extra hop is time lost on every visit.
Watch out for redirect chains. Sites commonly accumulate hops like this: HTTP without www goes to HTTP with www, which goes to HTTPS with www, which goes to HTTPS without www. That is three redirects where there should be one. Pick a single canonical form of the address and send every other variant straight to it, in one hop.
HSTS and the preload list
Even with a redirect, the very first request still goes out over HTTP before being redirected, and that window can be exploited. HSTS closes the gap. The header tells the browser never to attempt HTTP on that domain again, internally converting any attempt to HTTPS.
The full header, with every directive:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadPart by part:
max-age=31536000: one year in seconds. That is how long the browser remembers the rule.includeSubDomains: applies the rule to every subdomain.preload: signals intent to join the browser preload list, which ships inside the browser and protects even the very first visit.
The risk here is real and worth stating plainly: HSTS is hard to undo. If one of your subdomains has no valid certificate and you enable includeSubDomains, it becomes unreachable until you fix it, and browsers that already stored the rule will keep refusing for up to a year. Joining the preload list is harder still to reverse. Start with a short max-age, confirm everything works over HTTPS including subdomains, and only then raise it to a year and add preload. On this site we currently run max-age=15552000; includeSubDomains — 180 days, no preload — for exactly that reason.
Content-Security-Policy without breaking the site
CSP defines where the page may load scripts, styles, images, fonts and frames from. It is the most powerful header on the list and also the easiest to get wrong: a badly written policy blocks legitimate resources and the site looks broken.
That is why CSP has a test mode. Start with Content-Security-Policy-Report-Only, which blocks nothing and only records what would have been blocked. Run it that way for a few days, adjust the list of allowed origins based on what shows up, and only then switch to the enforcing header.
Two common traps: using unsafe-inline in script-src cancels much of the protection against script injection, and forgetting the origins for analytics, fonts and embedded maps takes down features you had forgotten existed.
If you want a quick, low-risk win before tackling the full policy, start with two isolated directives. The first is frame-ancestors, which does the same job as X-Frame-Options with more control. The second is upgrade-insecure-requests, which converts internal requests still pointing at HTTP into HTTPS and clears most mixed-content cases without hunting down every reference in the code.
X-Frame-Options and X-Content-Type-Options
X-Frame-Options: DENY prevents your site from being loaded inside a frame on another page. That blocks clickjacking, the trick of placing your site invisibly over another interface to steal clicks. The possible values are DENY, which forbids any embedding, and SAMEORIGIN, which allows it only within your own domain. If your site legitimately needs to be embedded somewhere, use SAMEORIGIN; otherwise DENY is the right call.
X-Content-Type-Options: nosniff stops the browser from guessing a file type different from the one the server declared. Without it, a user-uploaded file served as text can end up interpreted as a script. This header has a single valid value, nosniff, has no side effects, and should be on every site.
Referrer-Policy and Permissions-Policy
Referrer-Policy: strict-origin-when-cross-origin controls how much of the origin URL is sent when someone leaves your site through a link. With that value, navigation inside your own site sends the full URL; leaving for another domain sends only the domain, with no path and no parameters; and going from HTTPS to HTTP sends nothing at all. It is the right balance: it preserves traffic attribution without leaking internal paths.
Permissions-Policy switches off browser features your page does not use, such as camera, microphone and geolocation. Declaring an empty list for those features guarantees that neither your page nor a third-party script embedded in it can request them.
How to test on securityheaders.com
Put your site URL into securityheaders.com and you get a grade with a list of what is present and what is missing. Use it as a task list, not as a trophy. A site can score high there and still have a form with no validation.
Complement it with the SSL Labs test, which evaluates the certificate, protocol versions and accepted ciphers, and with the browser console, which reports mixed content and CSP violations. After configuring, retest every change in production before calling it done, and fold that check into your maintenance routine. The HTTPS side also appears as an item in our technical SEO checklist, because the two overlap.
Want to know which of these headers are missing from your site and how to apply them without breaking anything? Talk to ALB Seven.