Styrk sikkerheden på dit website med disse 10 HTTP Security Headers

Sikring af websites er nørdet og måske er det svært at se hvad du umiddelbart får ud af indsatsen. Men bliver dit site misbrugt, risikerer du både at skade virksomhedens omdømme samt lavere placering i søgeresultater.

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å webpagetest.org

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

Hvis du kæmper dig igennem artiklen her, bliver du klædt på til at vende dit websites Security Score, fra et blodrødt Forkasteligt til et lysegrønt Alletiders.

WebPageTest.org efter screenshot
Du kan forbedre din security score fra F til A på et par timer inklusive grundig test.

Hvad mangler sitet 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.

Tænk på det som at du ud over at låse hoveddøren, også lægger dine værdifulde ejendele i pengeskabet. Hvis nogen bryder ind i huset, har du gjort arbejdet ekstra surt for indbrudstyven.

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å hvordan du erhverver dig sådan et, kommer jeg ikke ind på her. Jeg viser dog hvordan du kan sikre at certifikatet benyttes, når nu du alligevel er igang 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 et af de emner, så skriv gerne en kommentar nederst på siden.

Tre online tjenester til tjek af dine security headers

SerpWorx HTTP Security Headers Check Tool

På SerpWorx får du et hurtigt overblik over, om du har sat de anbefalede headers. Her er også nogle lidt let forståelige beskrivelser af de enkelte headers samt nogle korte eksempler. Vigtigt at ha’ i baghovedet er, at SerpWorx, og de fleste andre tjenester, tjekker om headeren er til stede, men ikke om den er sikret bedst muligt. Man kan sige, at der tjekkes om du har anskaffet et pengeskab, men ikke om du har husket at vælge en anden kode, end den der står i brugervejledningen.

This tool only detects the presence of a security policy in the header response. It doesn’t validate any policies for best practices. Therefore, even if you have a ‘Content Security Policy’ with a wildcard, it will still pass as having detected a valid ‘Content Security Policy’.

serpworx.com/check-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 få steder der tjekker for den nye og stadigt ikke så udbredte 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

Mozilla Observatory

Den tredje og sidste tjeneste jeg anbefaler er 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 meste tekniske tjeneste, hvorfor jeg mener at SerpWorx og Probely også har deres berettigelse. Så kan du nemlig komme igang med at sikre dit website, uden at modet helt tages fra dig 🙂

The scores and grades offered by the Mozilla Observatory are designed to alert developers when they’re not taking advantage of the latest web security features, as recommended in Mozilla’s web security guidelines and server side TLS guidelines. Individual developers will need to determine which of these security technologies is right for their sites.

observatory.mozilla.org

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 kontrolpanelet, FTP eller et plugin som den glimrende Htaccess File Editor De mest almindelige webhoteller benytter sådan et setup.

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 ind i notepad, inden du går igang.

Redigering af .htaccess med LiteSpeed Cache Toolbox

Benytter du LiteSpeed Cache, har du mulighed for at redigere .htaccess filer direkte i dit WordPress dashboard. Gå til LiteSpeed Cache > Toolbox > Edit .htaccess

Editing htaccess using LiteSpeed Cache Toolbox

Vær obs på at du skal trykke på Save Changes knappen under redigeringsfeltet. Knappen ovenover, gemmer eventuelle ændringer i .htaccess path settings. Jeps… Hele tiden 😉

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 efter 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.

HTTP Response Header in developer tools

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 igang med at redigere i din .htaccess fil, kan du bruge stumpen her, og slippe afsted med ét plugin mindre i din WordPress installation.

There are times when we need to tell users that a resource has moved, either temporarily or permanently. This is what we use Redirect and RedirectMatch for.

Apache Configuration: .htaccess
# Automatic 301 redirect to https
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [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 af serveren blot som en kommentar, 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

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
Header always set X-Frame-Options "SAMEORIGIN"

X XSS Protection

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript (‘unsafe-inline’), they can still provide protections for users of older web browsers that don’t yet support CSP.

X XSS Protection dokumentation
# X XSS-Protection
Header 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 set X-Content-Type-Options "nosniff"

X Permitted Cross Domain Policies

Specifies if a cross-domain policy file (crossdomain.xml) is allowed. The file may define a policy to grant clients, such as Adobe’s Flash Player (now obsolete), Adobe Acrobat, Microsoft Silverlight (now obsolete), or Apache Flex, permission to handle data across domains that would otherwise be restricted due to the Same-Origin Policy.

X Permitted Cross Domain Policies dokumentation
# X Permitted Cross Domain Policies
Header set X-Permitted-Cross-Domain-Policies "none"

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
# Strict Transport Security
Header 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 set Referrer-Policy "strict-origin-when-cross-origin"

Expect-CT

The Expect-CT header lets sites opt in to reporting and/or enforcement of Certificate Transparency requirements, to prevent the use of misissued certificates for that site from going unnoticed.

Expect-CT dokumentation
# Expect-CT
Header set Expect-CT "enforce; max-age=14400" env=HTTPS

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.

Feature Policy

Feature Policy allows web developers to selectively enable, disable, and modify the behavior of certain features and APIs in the browser. It is similar to Content Security Policy but controls features instead of security behavior.

Feature Policy dokumentation
# Feature Policy (rudimentary policies supported by most browsers)
Header set Feature-Policy "microphone 'none'; camera 'none'"

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 (rudimentary policies supported by chrome and FF)
Header set Permissions-Policy "autoplay=(self), encrypted-media=(self), fullscreen=(self), geolocation=(self), midi=(self), payment=(self)"

Content Security 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.

Content Security Policy dokumentation
# Content Security Policy (CSP - rudimentary policies enforcing https)
Header set Content-Security-Policy "default-src * data:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'"

Den samlede kode til din .htacess fil.

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

### BEGIN Improved Site Security by oldrup.dk - 2021-02-18

## Automatic 301 redirect to https

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

## Additional security headers

<ifModule mod_headers.c>

# X Frame Options
Header always set X-Frame-Options "SAMEORIGIN"

# X XSS-Protection
Header set X-XSS-Protection "1; mode=block"

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

# X Permitted Cross Domain Policies
Header set X-Permitted-Cross-Domain-Policies "none"

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

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

# Expect-CT
Header set Expect-CT "enforce; max-age=14400" env=HTTPS

## Advanced policies - basic implementation

# Feature Policy (rudimentary policies supported by most browsers)
Header set Feature-Policy "microphone 'none'; camera 'none'"

# Permissions Policy (rudimentary policies supported by chrome and FF)
Header set Permissions-Policy "autoplay=(self), encrypted-media=(self), fullscreen=(self), geolocation=(self), midi=(self), payment=(self)"

# Content Security Policy (CSP - rudimentary policies enforcing https)
Header set Content-Security-Policy "default-src * data:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'"

</IfModule>

### END Improved Site Security

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 🙂

Ecosia logo

Vidste du …

… at du kan plante træer samt beskytte dit privatliv, ved at benytte en søgemaskine der kører på 200% grøn strøm? Se historien og prøv Ecosia.org

Skriv en kommentar