HTTPS Isn't Enough: What Security Headers Actually Protect You From

"We have HTTPS, so we're secure" is one of the most common misconceptions in web security. HTTPS encrypts the connection between a visitor's browser and your server — it says nothing about what happens once a malicious script gets onto your page, or whether your site can be embedded in an invisible frame on someone else's page to trick a visitor into clicking something they didn't intend to. That's what security headers actually protect against, and most business websites have none of them configured.

Strict-Transport-Security (HSTS)

HSTS tells browsers "never load this site over plain HTTP again, even if someone tries to redirect you there." Without it, a visitor's very first request could be intercepted on an untrusted network (public Wi-Fi, for instance) before the redirect to HTTPS even happens.

Content-Security-Policy (CSP)

CSP is the most powerful of the security headers and the hardest to get right. It tells the browser exactly which sources scripts, styles, images and fonts are allowed to load from — so if an attacker manages to inject a malicious script into your page (via a vulnerable plugin, a compromised third-party widget, or a comment field), the browser simply refuses to run it because it isn't from an allowed source. A wrong CSP can break your own site's legitimate embeds and fonts, which is exactly why it needs to be built deliberately, not copy-pasted from a generic template.

X-Frame-Options

This one blocks "clickjacking" — where an attacker loads your site inside an invisible iframe on their own page and tricks visitors into clicking buttons they can't actually see, believing they're interacting with the attacker's page. Setting this to SAMEORIGIN stops your site from being framed anywhere except its own domain.

X-Content-Type-Options

Set to nosniff, this stops browsers from trying to "guess" a file's type based on content rather than trusting the declared content type — a technique attackers have used to get malicious files executed when they were uploaded disguised as something harmless like an image.

Referrer-Policy

Controls how much of your URL gets sent as referrer data when a visitor clicks a link to another site. Without it, full URLs — including anything sensitive baked into the address, like session tokens on some poorly designed systems — can leak to whatever site they click through to next.

Permissions-Policy

Explicitly disables browser features your site doesn't use — camera, microphone, geolocation, payment APIs — so that even if a malicious script somehow got injected, it couldn't invoke capabilities your site was never meant to touch.

Check Your Own Headers

Our free Website Security Checker looks up all of these headers for any domain in seconds and tells you exactly what's missing — worth running against your own site right now, since in our experience most business websites are missing at least three or four of them without ever knowing it.

Getting the Configuration Right

The risk with headers like CSP isn't leaving them off — it's setting them wrong and quietly breaking your own site's fonts, analytics or embedded videos. Decoding IT's web application hardening work includes auditing exactly what your site loads before writing a policy that protects it without breaking it.

Decoding IT is a Muscat-based IT solutions provider helping businesses across Oman close the gaps that HTTPS alone doesn't cover. Contact our team to have your headers reviewed properly.