Styrk sikkerheden i WP 7.1 med HTTP Security Headers

Så du har tunet performance, SEO og webtilgængelighed, Google Lighthouse i DevTools kvitterer med fanfarer og konfetti, og du læner dig velfortjent tilbage. Og så får du den idé, at tjekke dit site på HTTP Observatory

Det kan jo aldrig skade med en “second opinion”, vel?

Hvis du kæmper dig igennem artiklen her, bliver du klædt på til at vende dit websites Security Score, fra fesent F til et beundringsværdigt B+

---

Hvad mangler et site med en ringe security-score?

Det som WebPageTest.org og andre tjenester påpeger – hvis dit WordPress site ligner de flestes – er manglende HTTP Security Headers Disse er en slags regler, eller politikker, der fortæller din browser hvordan dit website skal opføre sig, hvad dit website må, og i særdeleshed hvad det ikke må. Det kan fx være krav om, at al kommunikation til og fra dit website skal være krypteret, og at dit website ikke må afvikle kode fra andre websites.

Med HTTP Security Headers på plads, er der en reduceret risiko for at dit site kompromitteres, og skulle det alligevel ske, er mulighederne for at misbrug stærkt begrænsede.

Hvad denne artikel ikke handler om

Jeg går ud fra, at du allerede har et SSL-certifikat på dit website, så det kommer jeg ikke ind på her. Jeg viser dog hvordan du kan sikre at certifikatet benyttes, når nu du alligevel er i gang med at redigere din .htaccess-fil.

Andre gode idéer til sikring af dit WordPress-website omhandler firewalls og 2-faktor login, brugerrettigheder, backup og oppetidsovervågning. Vil du læse mere om disse emner, så er du velkommen til at kontakte mig.

Online værktøjer til tjek af security headers

Security Headers by Probely

Hos Probely får du et nemt overblik over de “rå headers” og deres indstillinger. Probely et af de steder der tjekker for Content Security Policy og ikke bare om den er til stede, men også hvordan den er konfigureret.

The HTTP response headers that this site analyses provide huge levels of protection and it’s important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

securityheaders.com

HTTP Observatory

Den anden tjeneste jeg anbefaler er HTTP Observatory, tidligere kendt som Mozilla Observatory. Her får du helt konkrete anbefalinger til forbedrede indstillinger, og tjenesten har den mest omfattende Content Security Policy analysis, som afslører ikke bare om, men også hvordan du har konfigureret CSP.

Det er også den mest tekniske tjeneste, hvorfor jeg mener at Probely også har sin berettigelse. På den måde kan du komme i gang med at sikre dit website, uden at modet helt tages fra dig 🙂

Developed by Mozilla, the HTTP Observatory performs an in-depth assessment of a site’s HTTP headers and other key security configurations. Its automated scanning process provides developers and website administrators with detailed, actionable feedback, focusing on identifying and addressing potential security vulnerabilities.

HTTP Observatory fra MDN

---

Sådan tilføjer du HTTP security headers til dit website

Du skal bruge en Apache eller LiteSpeed webserver

Tipsene her på siden, tager udgangspunkt i at du har en Apache-webserver eller varianten LiteSpeed, og at du har adgang til at redigere .htaccess-filen, enten via dit webhotels kontrolpanel, FTP eller et plugin som den glimrende Htaccess File Editor.

Tag backup – og afprøv én header ad gangen

Lad nu være med hovedløst at smide samtlige headers ind på din trafikerede webshop, på en lønningsdag. Prøv dem lige af på et testsite og bliv fortrolig med processen. Tag en backup. Da du blot laver ændringer i .htaccess-filen, som er en simpel tekstfil, kan du fx kopiere hele det eksisterende indhold til notepad, inden du går i gang.

Redigering af .htaccess med Htaccess File Editor

Benytter du pluginet Htaccess File Editor, kan du redigere .htaccess-filer direkte i dit WordPress Dashboard.

Husk at læse afsnittet “Read carefully” inden du går i gang. Og brug knappen Test Before Saving før du gemmer. Funktionen kan fange visse syntax-fejl, men er ingen garanti.

Tjek om det virker

Sådan tjekker du hurtigt om en den tilføjede sercurity header er tråd i kraft:

1. Åbn Developer Tools
2. Vælg fanen Network
3. Vælg dit domæne i kolonnen Name
4. Kig under Response Headers. Kan du finde din nye header?

Det er også altid en god idé, løbende at tjekke fanen Console for eventuelle fejlmeddelelser.

Automatisk 301 redirect til https (SSL/TLS-kryptering)

Hvis du i forvejen har automatisk redirect fra http til https, f.eks. med det gratis plugin Really Simple SSL, behøver du ikke nedenstående stump kode. De gør præcis det samme. Men vælger du at implementere en eller flere af de anbefalede security headers og er derfor alligevel i gang med at redigere i din .htaccess-fil, kan du bruge stumpen her, og slippe afsted med ét plugin mindre i din WordPress-installation.

These Rewrite rules will redirect from the http:// insecure version to the https:// secure version of the URL as described in the Apache HTTPD wiki.

Apache Configuration: Forcing HTTPS

## Automatic 301 redirect to https
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

Anbefalede HTTP Security Headers – de syv nemme

Herunder finder du de headers du lettest implementerer. Ved hver header finder du en kort beskrivelse, et link til uddybende information, samt en kodeblok du kan paste ind i .htaccess. Linjen med hash-tagget # opfattes blot som en kommentar af serveren, så den kan du vælge at undlade.

Jeg har valgt ikke at kaste mig ud i et forsøg på at fordanske beskrivelserne af den enkelte header – det kan være svært nok at forstå i forvejen. I stedet er beskrivelserne citeret fra den linkede dokumentation, primært MDN Web Docs

X Frame Options (forældet, gemt til testformål)

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

X Frame Options dokumentation

# X Frame Options (obsolete but kept for testing)
Header always set X-Frame-Options "SAMEORIGIN"

X XSS Protection (forældet, gemt til testformål)

Non-standard: This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

X XSS Protection dokumentation

# X XSS-Protection (obsolete but kept for testing)
Header always set X-XSS-Protection "1; mode=block"

X-Content-Type-Options

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This is a way to opt out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured.

X Content Type Options dokumentation

# X Content-Type-Options
Header always set X-Content-Type-Options "nosniff"

X-Powered-By

May be set by hosting environments or other frameworks and contains information about them while not providing any usefulness to the application or its visitors. Unset this header to avoid exposing potential vulnerabilities.

X-Powered-By

# X-Powered-By and Server
Header always unset X-Powered-By

HTTP Strict Transport Security (HSTS)

If a website accepts a connection through HTTP and redirects to HTTPS, visitors may initially communicate with the non-encrypted version of the site before being redirected, if, for example, the visitor types http://www.foo.com/ or even just foo.com. This creates an opportunity for a man-in-the-middle attack. The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site.

Strict Transport Security documentation

# Enable Strict Transport Security
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS 

Referrer Policy

The Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML.

Referrer Policy dokumentation

# Referrer Policy
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Cross-Origin Resource Policy (CORP)

Cross-Origin Resource Policy (CORP) is set by the Cross-Origin-Resource-Policy response header, which lets websites and applications opt-in to protection against vulnerabilities related to certain cross-origin requests (such as those made by the script and img elements).

Cross-Origin Resource Policy (CORP) documentation

# Cross-Origin Resource Policy (valid 2026)
Header always set Cross-Origin-Resource-Policy "same-origin"

Tre extra avancerede politikker

Nu begynder det at blive en lille smule speget, og du skal kun implementere de følgende politikker hvis du har god tid. Politikkers effektivitet, især Content Security Policy, afhænger stærkt af om de er korrekt tilpasset netop dit website. Fortæller man, at et website fx ikke må anvende mikrofonen, ja så vil mikrofonen selvsagt ikke virke på sitet, og var det egentlig meningen at den skulle det, ja så står sikkerheden jo i vejen for funktionaliteten.

Bye bye Feature-Policy, hello Permissions-Policy

HTTP Toolkit

Desuden er nogle af politikkerne under ombygning og endnu sparsomt understøttet af alle browsere. Så jeg har valgt nogle politikker som er – for begyndere om man vil. De strammer stadigt op sammenlignet med ikke at have politikkerne implementeret, de er afprøvet på flere forskellige sites, og de fungerer som et godt udgangspunkt for mere minutiøs gennemgang, hvis du en dag ønsker at stramme yderligere op.

Igen, test dit site grundigt efter implementering – og knækker filmen, så nøjes med at implementere én politik ad gangen, så du kan se hvor det eventuelt går galt.

Permissions Policy

Permissions Policy is a web platform API which gives a website the ability to allow or block the use of browser features in its own frame or in iframes that it embeds.

Permissions Policy dokumentation

# Permissions Policy
Header always set Permissions-Policy "camera=(), microphone=(), payment=(), display-capture=()"

Content Security Policy

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

Content Security Policy dokumentation

For at fungere uden problemer under WordPress og de plugins du måtte anvende, er nedenstående CSP ret løs – blot en smule bedre end ingenting. For rigtig at få fuld glæde af CSP’en bør den tilrettes netop dit site. Der er udmærkede ekstensions både til Firefox og Chrome, som kan hjælpe hermed, og værktøjer til at verificere syntaksen på din policy, som – indrømmet – kan være temmelig kringlet.

# Content Security Policy (WordPress 7.1 Compatible)
Header always set Content-Security-Policy "default-src 'self' https:; object-src 'none'; style-src 'self' https: 'unsafe-inline'; font-src 'self' https: data:; img-src 'self' https: data: blob:; frame-src 'self' https: blob:; connect-src 'self' https:; script-src 'self' https: data: blob: 'unsafe-inline' 'unsafe-eval'; frame-ancestors 'self';"

ForceSecureCookie

As of LSWS v 5.4.9 build 2, a new directive ForceSecureCookie has been introduced to enforce secure , SameSite and httponly cookie attributes

LiteSpeed Alternative to Apache Header Edit

## ForceSecureCookie (LiteSpeed Set Cookie HTTPOnly Secure alternative)
<IfModule LiteSpeed>
	ForceSecureCookie same_site_lax
</IfModule>

---

Den samlede kode til din .htacess-fil.

Herunder er den samlede kode jeg benytter på alle mine sites, inklusive SSL redirect-stumpen, de otte enkle politikker og de fire avancerede, lige til at sætte ind i toppen af .htaccess. Og jeg siger det lige igen: husk backup og test 🙂

### BEGIN Improved Site Security 7.1 by oldrup.dk - 2026-08-19

## Automatic 301 redirect to https
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

## Additional security headers

<IfModule mod_headers.c>
	
# X Frame Options (obsolete but kept for testing)
	Header always set X-Frame-Options "SAMEORIGIN"
	
# X XSS-Protection (obsolete but kept for testing)
	Header always set X-XSS-Protection "1; mode=block"

# X Content-Type-Options (valid 2026)
	Header always set X-Content-Type-Options "nosniff"
	
# X-Powered-By and Server (valid 2026)
	Header always unset X-Powered-By

# Enable Strict Transport Security (valid 2026)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS 

# Referrer Policy (valid 2026) 
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

# Cross-Origin Resource Policy (valid 2026)
    Header always set Cross-Origin-Resource-Policy "same-origin"


## Advanced policies - basic implementation
	
# Permissions Policy (Disable unused browser/hardware APIs)
Header always set Permissions-Policy "camera=(), microphone=(), payment=(), display-capture=()"

# Content Security Policy (WordPress 7.1 Compatible)
Header always set Content-Security-Policy "default-src 'self' https:; object-src 'none'; style-src 'self' https: 'unsafe-inline'; font-src 'self' https: data:; img-src 'self' https: data: blob:; frame-src 'self' https: blob:; connect-src 'self' https:; script-src 'self' https: data: blob: 'unsafe-inline' 'unsafe-eval'; frame-ancestors 'self';"

</IfModule>

## ForceSecureCookie (LiteSpeed Set Cookie HTTPOnly Secure alternative)
<IfModule LiteSpeed>
	ForceSecureCookie same_site_lax
</IfModule>

### END Improved Site Security 7.1

Opsummering

Tag det fra én der har prøvet begge dele; det er langt mindre tidskrævende at forebygge – end at rydde op efter et hackerangreb.

Hvad gør du for at sikre dine websites? Kunne du bruge forslagene her i artiklen til noget, og er det et emne du gerne vil læse mere om? Så efterlad gerne en kommentar herunder.

Tak for at du holdt ved så længe 🙂