terug naar blogs

Security Headers

Afbeelding voor Security Headers
avatar van Danny
auteur
Danny
auteur
avatar van Danny
Danny
Security headers
8 november 2022 leestijd 5-7 minuten

Security headers zijn belangrijk voor het beveiligen van je websites. Ze helpen de gebruiker te beschermen tegen verschillende soorten hacks zoals cross-site-scripting, clickjacking en code injecties. Maar wat zijn security headers nu precies, welke zijn belangrijk en hoe implementeer je deze op jouw website? In deze blog behandelen we de vijf belangrijkste security headers die je volgens internet.nl altijd moet toepassen.

Wat zijn security headers?

Wanneer iemand een site bezoekt via de browser, zal de server reageren met HTTP Response Headers. Deze headers geven aan de browser aan hoe die zich moet gedragen tijdens de communicatie. Security headers zijn nooit standaard actief en moet je altijd expliciet instellen en activeren.

Om te controleren welke security headers actief zijn, en welke je mogelijk nog wilt toevoegen, adviseren wij een test te doen via internet.nl. Deze tool meet je website op verschillende punten met een sterke focus op security en het gebruik van moderne protocols. Onlangs schreven we een blog over de nieuw toegevoegde maatstaaf RPKI.Internet.nl controleert op de volgende headers: HTTP Strict Transport Security (HSTS), X-Frame-Options, X-Content-Type-Options, Content-Security-Policy en Referrer-Policy. 

HTTP Strict Transport Security (HSTS)

HSTS is in het leven geroepen om te voorkomen dat HTTPS verkeer onbedoeld gedowngrade kan worden tijdens een “man in the middle attack”. Dit is een aanval waarbij iemand het verkeer tussen een gebruiker en website weet af te luisteren. Als dit verkeer dan niet beveiligd is kunnen gevoelige gegevens zoals wachtwoorden uitgelezen worden. De HSTS header verbied het gebruik van een onbeveiligde HTTP verbinding.

Het risico van een HSTS header is dat een website zonder SSL certificaat niet te benaderen is. Ook niet als je de risico’s van een ontbrekend SSL certificaat accepteert. In het verleden, voor de tijd van gratis SSL certificaten, was dit risico reëler. Tegenwoordig zou je deze header standaard willen gebruiken.

HSTS security header resultaat

NGINX voorbeeld:
add_header Strict-Transport-Security: "max-age= 63072000; includeSubDomains"; preload;

  • Max-age : De leeftijd van de HSTS header in seconden : Deze leeftijd wordt onthouden door de browser zodat wanneer een SSL certificaat vervalt, de lokale browser onthoud dat er alleen een HTTPS verbinding opgezet mag worden. 
  • includeSubDomains : De header geld voor alle subdomeinen op dezelfde website : Sommige website hebben bijvoorbeeld een blog of shop gedeelte onder een subdomein zoals blog.voorbeeld.com maar ook www. Is technisch gezien een subdomein. Deze optie voorkomt dat er via een subdomein toch onbeveiligd verbinding gemaakt kan worden naar de website. 
  • Preload : De HSTS header wordt uit vanuit een Google Chrome lijst voorgeladen : Dit is geen officieel onderdeel van de header maar wordt gehost door Google Chrome en ondersteund door de meeste browsers. De preload voorkomt dat er bij een vers geïnstalleerde browser toch eerst een onbeveiligde verbinding opgezet kan worden voordat de HSTS header gevonden wordt. Voor deze functie moet de max-age minimaal een jaar zijn en de includeSubDomains actief zijn.  

X-Frame-Options

Met X-Frame-Options geef je aan welke content elementen van jouw website mogen worden ingeladen via een frame, iframe of object op een andere website. Deze verschillende frames worden bijvoorbeeld gebruikt om third party content in te laden zoals een socialmedia buttons, reviews of imbedded media. De X-Frame-Options header is ontwikkeld om clickbaiting/clickjacking te voorkomen.

Een aanvaller zou hierbij een gelijknamig domein claimen en heel gemakkelijk een website kunnen “koppieren” door de website in een frame te laden. Hierover plaatst men een onzichtbare laag waardoor een bezoeker niet op de onderliggende content klikt maar op een door de aanvaller ingestelde actie bijvoorbeeld het downloaden van malware of het vrij geven van persoonlijke gegevens.

NGINX voorbeeld:
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Frame-Options "DENY";

  • SAMEORIGIN : Vanaf de zelfde bron wordt het inladen toegestaan : Dezelfde oorsprong betekent dezelfde host, poort en protocol. Kortom, vanaf dezelfde server mag je de content van je website in een iframe, frame of object gebruiken.
  • DENY : Content kan niet worden gebruikt in een frame, iframe of object

X-Content-Type-Options

Een browser maakt gebruike van MIME (Multipurpose Internet Mail Extensions) sniffing. Dit betekent dat de browser een bestand analyseert om te bepalen wat voor type bestand het is en hoe de browser deze vervolgens moet lezen. Dit is een handige functie voor wanneer er niet genoeg meta-data beschikbaar is en de browser zelf moet bepalen hoe een bestand gelezen moet worden. Dit voorkomt weergave fouten op je website.

Het risico van MIME sniffing is dat dit misbruikt kan worden in hoe de browser een bestand leest. Dit noem je XSS (Cross Site Scripting). Bij een website waarbij users zelf afbeeldingen of bestanden kunnen uploaden kan een aanvaller zijn malafide code verstoppen als .png of .pdf. Wanneer de browser vervolgens zelf besluit dat dit bestand een script is en deze uitleest als script kan de gebruiker bijvoorbeeld geredirect worden of wordt er geprompd malware te downloaden.

De X-Content-Type-Options header zorgt er voor dat de browser de bestanden niet zelf analyseert maar de MIME-type gebruikt die de server mee stuurt. Verzoeken die een afwijkend type opvragen worden geweigerd.

MIME Type


NGINX voorbeeld:
add_header X-Content-Type-Options: 'nosniff’;

Content-Security-Policy (CSP)

Content-security-policy is de security header met de meeste opties. Dit maakt de CSP header de ingewikkeldste header om correct te plaatsen. Met deze header geef je aan vanuit welke bronnen de browser bepaalde type content mag laden. Zo voorkom je dat ongewenste bronnen, door bijvoorbeeld cross-site-scripting, content kunnen inladen op je website. Belangrijk is dat je bij iedere content type de juiste bronnen aangeeft. Wanneer je een bron vergeet of nieuwe bron toevoegd aan de website die niet in de header is opgenomen, dan wordt de content geblokkeerd door de browser. Hoe meer externe bronnen je hebt hoe ingewikkelder deze headers kan worden.

CSP Security header resultaat


NGINX voorbeeld:
add_header Content-Security-Policy "default-src 'self'; font-src 'fonts.google.com';img-src 'cdn.images.com'; script-src 'self' 'scripts.sources.com'; style-src 'css.domein.com';";

  • default-src ‘self’: Wanneer er geen specifieke bron wordt aangegeven voor een onderdeel zal de header terug vallen op zichzelf. : De header kijkt naar domeinen. ‘self’ betekent dus in dit geval het eigen domein. Hier vallen geen subdomeinen onder alleen het hoofddomein.
  • font-src ‘fonts.google.com’ : Dit zijn de domeinen die de fonts mogen inladen : Soms worden fonts intern geladen vanuit het eigen domein. Je ziet vaak ook fonts extern geladen worden zoals rootnet.nl bijvoorbeeld use.typekit.net gebruikt.
  • img-src ‘cdn.images.com’ : Dit zijn de domeinen die afbeeldingen mogen inladen : Het verscheelt per website waar de afbeeldingen vandaan komen. Soms worden zij vanuit een eigen media library geladen, soms wordt een CDN gebruikt.
  • script-src ‘self’ ‘scripts.sources.com’ : Dit zijn de domeinen die scripts mogen inladen : Je gebruikt altijd scripts vanuit je eigen domein maar het is mogelijk dat je ook extern scripts inlaad bijvoorbeeld google analytics, advertenties, payment gateways etc.
  • style-src ‘css.domein.com’ : Dit zijn de domeinen die styling (CSS) mogen inladen : In de meeste gevallen zal je dit vanaf je eigen domein laden. Heel soms gebruiken websites extra styling vanuit een externe bron.

Referrer-Policy

De referrer-policy header verteld de browser welke referrer informatie getoond mag worden. De referer-header bevat standaard het adres van de vorige webpagina waarvan de bezoeker een link naar de opgevraagde pagina heeft gevolgd. De informatie in de referrer header wordt voornamelijk gebruikt voor analyse en logging. Het risico hiervan is dat derde partijen dit kunnen gebruiken om informatie van gebruikers te verkrijgen. Met de referrer-policy header kun je dit risico beperken.

De Referer-Policy header heeft meerder opties;

  • no-referrer : geeft geen informatie over de bron
  • no-referrer-when-downgrade : geeft de complete URL behalve als het protocol van HTTPS naar HTTP gaat.
  • origin : geeft de informatie over de bron als deze van dezelfde website of een externe bron komt.
  • strict-origin : geeft de informatie over de bron weer wanneer deze gestuurd wordt over een HTTPS verbinding
  • origin-when-cross-origin : geeft de complete URL behalve wanneer deze naar een externe bron gaat, geeft dan alleen de bron op.
  • strict-origin-when-cross-origin : geeft de complete url vanaf dezelfde bron, geeft alleen het domein bij externe bronnen en geeft geen informatie als dit over HTTP gestuurd wordt.
  • same-origin : geeft alleen informatie als de bron hetzelfde is als de bestemming
  • unsafe-url : geeft altijd alle informatie

Internet.nl adviseert standaard de optie “no-refferer” of “same-origin”.

NGINX voorbeeld:
add_header Referrer-Policy "no-referrer";

Hoe voeg je security headers toe aan je website?

Security headers kunnen op zowel applicatie als server niveau toegevoegd worden. Het meest gebruikelijke is dat deze op server niveau worden toegepast door de hosting partij. Voor Rootnet klanten is het mogelijk om een set gestandaardiseerde security headers op te nemen in een template. Zo kan je ieder project laten uitrollen met security headers die voor de meeste websites hetzelfde zijn.

Vragen over de security van je website?

avatar van Danny
Danny staat klaar om je te helpen
Naar contactpagina

"*" geeft vereiste velden aan