SSL, Security Headers, and Protecting Your Website

Go to securityheaders.com right now and type in your website's URL. If you see anything less than an A grade, your site is broadcasting to every browser, bot, and bad actor on the internet that security wasn't a priority when it was built.

That failing grade isn't theoretical risk. It's a measurable signal that affects how browsers treat your pages, how Google evaluates your site, and how vulnerable your visitors are to attacks you could have prevented with a few lines of server configuration.

Most web developers stop at the SSL certificate. They install it, confirm the padlock shows up in the address bar, and move on. But HTTPS is the floor, not the ceiling. The real protection comes from HTTP security headers — a set of instructions your server sends with every page load that tell browsers exactly what to allow and what to block. And the majority of websites, including ones built by professional agencies, ship without them.

HTTPS Is the Starting Point, Not the Finish Line

Let's get the basics out of the way. HTTPS encrypts the connection between your visitor's browser and your server. Without it, everything travels across the internet in plain text: form submissions, login credentials, even which pages someone visits. Anyone on the same network can read it.

Google has treated HTTPS as a ranking signal since 2014, and Chrome now flags HTTP sites with a "Not Secure" warning in the address bar. As of early 2026, roughly 87% of websites use SSL certificates by default. Getting a certificate is free through Let's Encrypt and takes minutes to install on most hosts. There's zero excuse for running a site over plain HTTP in 2026.

But here's what the padlock icon doesn't tell you: HTTPS protects data in transit. It doesn't protect your site from being embedded in a malicious iframe. It doesn't stop someone from injecting scripts into your page through a cross-site scripting attack. It doesn't prevent your site from loading resources from compromised third-party domains. That's what security headers do.

A site with HTTPS but no security headers is like a house with a deadbolt on the front door and every window left wide open.

The Security Headers That Actually Matter

Your web server can send special HTTP headers with every response that instruct the browser to enforce specific security policies. These aren't visible on the page. They work behind the scenes in the HTTP response. Here are the ones every site should have.

Strict-Transport-Security (HSTS)

HSTS tells the browser: "Always connect to this site over HTTPS. Don't even try HTTP." Without it, the first request to your site might still happen over HTTP before redirecting to HTTPS — and that initial unencrypted request is vulnerable to interception.

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

The max-age value is in seconds. 31536000 equals one year. includeSubDomains applies the policy to all subdomains. preload tells browser vendors to hardcode your domain into their HSTS preload lists, so the browser never even attempts an HTTP connection — not even the first one.

You can submit your domain for preload inclusion at hstspreload.org, but think carefully before you do. Removal from the preload list takes months. You need to be confident that every subdomain on your domain supports HTTPS before opting in.

Qualys SSL Labs recently updated their grading so that sites without valid HSTS headers get downgraded from an A to an A-. That's how expected this header has become.

Content-Security-Policy (CSP)

This is the most powerful security header available, and the one most sites skip because it takes effort to configure properly.

CSP tells the browser exactly which sources are allowed to load scripts, styles, images, fonts, and other resources on your page. If a source isn't on the approved list, the browser blocks it. This is your primary defence against cross-site scripting (XSS) attacks, which remain one of the most common web vulnerabilities year after year according to OWASP.

A basic CSP looks like this:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; frame-ancestors 'none'

Breaking that down: default-src 'self' means only load resources from your own domain unless a more specific directive says otherwise. script-src 'self' restricts JavaScript to your own files. frame-ancestors 'none' prevents other sites from embedding your pages in iframes — that's clickjacking protection, and it's the modern replacement for X-Frame-Options.

The hard part with CSP is that it will break things if you don't account for every legitimate resource your site loads. Google Fonts, analytics scripts, embedded videos, tag managers: they all need explicit permission. We recommend starting with Content-Security-Policy-Report-Only mode. In report-only mode, the browser logs violations without actually blocking anything, so you can see what would break before enforcing the policy.

Avoid 'unsafe-inline' and 'unsafe-eval' in your script-src if at all possible. These directives exist as escape hatches, but they massively reduce the protection CSP provides. If your site requires inline scripts, use nonces instead. Nonces are unique per-request tokens that allow specific inline scripts while blocking everything else.

X-Content-Type-Options

X-Content-Type-Options: nosniff

One line. No configuration. This header prevents browsers from guessing (or "MIME sniffing") the content type of a response. Without it, a browser might interpret a text file as JavaScript and execute it. MIME confusion attacks are real, and this header kills them. There is no reason not to include it on every site.

Referrer-Policy

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

This controls how much information your site shares with other sites when a visitor clicks an outbound link. The strict-origin-when-cross-origin setting sends the full URL for same-origin navigation but only sends the origin (domain, no path) for cross-origin requests. It also strips the referrer entirely when navigating from HTTPS to HTTP.

Why this matters: without a referrer policy, your full page URLs get sent to every external site you link to. If your URLs contain sensitive information (session IDs, internal paths, search queries), that data leaks to third parties through the Referer header.

Permissions-Policy

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

This header tells the browser which device features your site is allowed to use. Setting a feature to () means "nobody can use this, not even our own code." Most business websites have no reason to access a visitor's camera, microphone, or location. Declaring that explicitly means even if someone injects malicious code into your page, they can't access those APIs.

Setting Up Security Headers in Apache (.htaccess)

If your site runs on Apache — and most shared hosting and cPanel environments do — you can add all of these headers through your .htaccess file. Here's a complete configuration:

<IfModule mod_headers.c>
  # Force HTTPS
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  # Prevent MIME type sniffing
  Header always set X-Content-Type-Options "nosniff"
  # Clickjacking protection (legacy, CSP frame-ancestors is preferred)
  Header always set X-Frame-Options "DENY"
  # Control referrer data
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  # Restrict browser features
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"
  # Content Security Policy — adjust sources to match your site
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none'"
</IfModule>

For Nginx, the equivalent uses add_header directives in your server block. For Cloudflare users, many of these can be set through the dashboard without touching server config at all.

One thing to watch: if you're using Google Tag Manager, Google Analytics, embedded YouTube videos, or any third-party service, your CSP needs to include those domains. A CSP that blocks your analytics script is protecting your site from itself. Test thoroughly.

Why Small Sites Are Not Exempt

We hear this constantly: "We're a small business. Nobody is going to attack our website." This is wrong, and it reflects a misunderstanding of how attacks work.

Automated bots don't check your company's revenue before targeting your site. They scan millions of URLs looking for known vulnerabilities, outdated software, and missing security configurations. A small WordPress site with no security headers is a softer target than a large site with proper protections. Attackers don't need to care about your business — they want your server resources for spam relay, cryptocurrency mining, or as a staging point for attacks on other targets.

Cross-site scripting vulnerabilities without CSP protection let attackers inject code that steals your visitors' data, redirects them to malicious sites, or modifies what they see on your page. Clickjacking without frame-ancestors protection lets attackers overlay invisible iframes on your site and trick visitors into clicking things they didn't intend to. These attacks don't require your site to be high-profile. They just require your site to be unprotected.

For Alberta businesses, there's also a legal dimension: PIPA compliance requires you to protect the personal information your website collects, and security headers are part of that obligation. There's also the SEO angle. Google has been explicit that HTTPS is a ranking signal, and site security feeds directly into Core Web Vitals and technical health assessments. A properly secured site with correct headers loads predictably, doesn't trigger browser warnings, and signals to search engines that the site is maintained by someone who knows what they're doing. Security headers won't single-handedly boost your rankings, but their absence is one of many signals that contribute to a slow, poorly configured site that underperforms in search.

Testing Your Security Configuration

Three tools. That's all you need.

securityheaders.com grades your HTTP response headers from A+ to F. It checks for all the headers we've discussed and tells you exactly what's missing. Run this after any server configuration change. It was created by security researcher Scott Helme and is now part of Snyk.

Qualys SSL Labs (ssllabs.com/ssltest) analyses your SSL/TLS configuration in depth — certificate validity, protocol versions, cipher suites, key exchange, and HSTS support. An A+ here means your encryption is properly configured. Anything less means something needs attention. This is the industry standard test, and it's free.

Browser Developer Tools are already on your computer. Open your site, press F12, go to the Network tab, click on the initial page request, and look at the Response Headers section. Every security header your server sends (or doesn't send) is visible there. The Console tab will show you CSP violations in real time — any resource that gets blocked will log an error.

If you're managing a site and you've never run these tests, do it now. The results might explain browser warnings, mixed content errors, or technical SEO problems you've been chasing from the wrong angle.

Getting This Right the First Time

Security headers cost nothing. They require no paid software, no subscriptions, and no ongoing maintenance beyond occasional testing. They're lines of text in a configuration file. And yet the overwhelming majority of websites ship without them because the developer either didn't know about them or didn't prioritize them.

If you're working with a web developer or agency and your site has an F on securityheaders.com, that tells you something about their standards. If they push back with "it's not necessary for a small site" or "we'll add that later," that tells you even more. We configure security headers as part of every site build and server setup we do because treating security as optional is how you end up spending money fixing problems that should never have existed.

The single thing to remember: SSL gets you the padlock, but security headers protect what's behind it. Check your site today. Fix what's missing. It will take less time than reading this article did.

Sources

• OWASP Secure Headers Project — OWASP's maintained reference for recommended HTTP security headers, updated January 2026 with analysis of 150,000 domains
• MDN: Content-Security-Policy — Mozilla's official documentation for CSP directives, syntax, and browser support
• MDN: Strict-Transport-Security — Mozilla's reference for HSTS configuration and preloading
• MDN: X-Frame-Options — Mozilla's documentation on frame-ancestors as the modern replacement for X-Frame-Options
• HSTS Preload List Submission (hstspreload.org) — Requirements and submission form for browser HSTS preload lists
• Qualys SSL Labs Server Test — Free SSL/TLS configuration analysis tool with grading from A+ to F
• Let's Encrypt Statistics — Certificate issuance data showing Let's Encrypt's role in HTTPS adoption (63.7% market share as of 2025)
• Scott Helme: Security Headers Grading Criteria — Background on securityheaders.com's grading approach and criteria
• Google Search Central: HTTPS as a Ranking Signal — Google's confirmation that HTTPS is used as a ranking signal
• OWASP HTTP Headers Cheat Sheet — Practical implementation guide for security headers with recommended values