Security headers: the 5 headers every Swedish website needs

HTTP security headers block entire categories of attacks. They cost nothing to implement and take minutes to configure. Yet the majority of Swedish websites are missing at least two of the five headers covered here.

If you operate a website that handles personal data, GDPR Article 32 requires you to implement "appropriate technical measures" to protect it. NIS2 Article 21(2)(e) goes further, requiring network and information systems security for entities in scope. Missing security headers are a measurable gap in both.

Why HTTP security headers matter

Every time a browser loads your website, your server sends HTTP response headers along with the page content. Security headers instruct the browser to enable specific protections: block scripts that shouldn't run, refuse to let attackers frame your site, and force encrypted connections.

Without these headers, you're relying entirely on the browser's default behavior. Defaults are permissive. Attackers know this.

1. Strict-Transport-Security (HSTS)

HSTS forces browsers to use HTTPS for all connections to your domain. Once the browser sees this header, it refuses to load your site over plain HTTP, even if a user types http:// or clicks an old bookmark.

This prevents SSL stripping attacks, where an attacker intercepts the initial HTTP request and downgrades the connection to unencrypted traffic. Without HSTS, every first visit to your site is vulnerable to this interception.

• Recommended value: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
• max-age=63072000 tells the browser to remember this policy for two years
• includeSubDomains applies the policy to all subdomains, so attackers can't exploit a subdomain without HSTS
• preload submits your domain to the HSTS preload list, built into Chrome, Firefox, Safari, and Edge. This eliminates even the first-visit vulnerability

Without HSTS, an attacker on the same network (public Wi-Fi, compromised router) can intercept and read traffic that should be encrypted. For sites handling personal data, this is a direct GDPR Article 32 risk.

2. Content-Security-Policy (CSP)

CSP gives you the most control of any security header. It tells the browser exactly which content sources are allowed on your page: scripts, styles, images, fonts, and frames. Anything not explicitly allowed is blocked.

This is the primary defense against cross-site scripting (XSS). If an attacker injects a malicious script tag into your page, CSP prevents it from executing because the script's origin isn't in your allow list.

• default-src 'self' — only allow resources from your own domain by default
• script-src 'self' — restrict JavaScript to your domain (add specific CDN domains if needed)
• style-src 'self' — restrict stylesheets to your domain
• img-src 'self' data: — allow images from your domain and data URIs
• frame-ancestors 'self' — prevent other sites from framing your pages (replaces X-Frame-Options)

Start with a restrictive policy and add exceptions as needed. A permissive CSP (script-src 'unsafe-inline' 'unsafe-eval') defeats the purpose. If your site uses inline scripts, refactor them into external files or use CSP nonces.

3. X-Frame-Options

X-Frame-Options prevents your website from being embedded in an iframe on another site. This blocks clickjacking attacks, where an attacker overlays your site with transparent elements to trick users into clicking buttons they can't see.

A clickjacking attack on a banking portal, admin panel, or consent form can lead to unauthorized actions. The user thinks they're clicking on the attacker's page, but they're actually clicking buttons on your embedded site.

• DENY — no site can frame your pages, including your own domain
• SAMEORIGIN — only your own domain can frame your pages
• Recommended: SAMEORIGIN unless you have no legitimate need for iframes

CSP's frame-ancestors directive is the modern replacement for X-Frame-Options and offers more granular control. However, X-Frame-Options remains important for older browsers that don't support CSP. Set both for full coverage.

4. X-Content-Type-Options

This single-value header prevents MIME type sniffing. Browsers sometimes try to "guess" a file's content type by examining its contents rather than trusting the Content-Type header. Attackers exploit this by uploading files that look like one type but execute as another.

For example, an attacker uploads a file disguised as an image that actually contains JavaScript. Without this header, the browser might execute it.

• Only valid value: X-Content-Type-Options: nosniff
• Forces the browser to respect the declared Content-Type
• Prevents script execution from mistyped MIME responses
• Zero configuration complexity. Set it and forget it

There is no reason not to set this header. It has one value, no compatibility issues, and no performance impact.

5. Referrer-Policy

The Referer header (yes, the original HTTP spec misspelled it) tells the destination site which URL the user came from. Without a Referrer-Policy, your site may leak full URLs (query parameters, internal paths, session tokens) to every external link and resource your page loads.

For websites that handle personal data, this is a privacy leak. URL parameters might contain search queries, user IDs, or other identifiers that constitute personal data under GDPR.

• strict-origin-when-cross-origin — sends only the origin (domain) to other sites, but the full URL for same-origin requests. Best balance of functionality and privacy.
• no-referrer — sends no referrer information at all. Maximum privacy but breaks analytics and some integrations.
• Avoid: unsafe-url sends the full URL to all destinations, including HTTP sites

Recommendation: strict-origin-when-cross-origin for most websites. Use no-referrer if you handle sensitive data in URL paths (healthcare portals, financial dashboards).

How Vakteye scans for missing headers

Vakteye's headers scanning task checks for 15+ security headers on every scan. Each missing header is flagged as a finding with FIRM confidence, mapped to GDPR Article 32 and NIS2 Article 21(2)(e). The report includes remediation guidance with the exact header value you should set.

The scan results show not just which headers are missing, but what attacks each gap enables and which legal requirements it violates. Findings include ready-to-use configuration snippets for common web servers and frameworks.

Legal requirements: GDPR and NIS2

GDPR Article 32 requires controllers and processors to implement "appropriate technical and organisational measures" to ensure security appropriate to the risk. Security headers are a textbook example: free, widely supported, and effective against well-known attack vectors.

NIS2 Article 21(2)(e) specifically addresses network and information systems security, including policies on the use of cryptography and encryption. HSTS and CSP both fall directly under this requirement.

IMY has cited missing technical security measures in multiple enforcement decisions. When basic, industry-standard protections are absent, it's difficult to argue that your measures were "appropriate."