Een HTTP-reactieheader is wat de webserver terugstuurt naar de browser, vóórdat de content wordt getoond. Een header zie je dus niet altijd, het bevindt zich op de achtergrond. Dat wat de browser -of client- stuurt naar de webserver, heet een verzoekheader (vandaar: Request header en Response header).

In HTTP-reactieheaders staat veel informatie, soms te veel informatie. Ook kun je er veel zaken in regelen, zoals hoe een browser zich gedragen moet, of wat de server moet terugsturen. Ook maak je hiermee de beveiliging van je website beter en strikter.

Dit artikel geeft jou uitleg.

In een ander artikel hebben we je uitgelegd dat je met een HTTP Strict-Transport-Security reactieheader volledige SSL-versleuteling tussen client en server kunt forceren.

Zo is er nog een aantal headers dat aandacht nodig heeft:

  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection
  • Server
  • Content-Security-Policy

Ja, dit is een ingewikkelde materie, maar wij vinden het wél belangrijk dit te benoemen. In het kort uiteraard.

Let op: daar waar een voorbeeld code staat, interpreteer het als zodanig: een voorbeeld. Een foutief ingestelde header kan de werking van je website negatief beïnvloeden. Windows Server IIS web.config-bestand voorbeelden moeten op een juiste plaats in dat bestand opgenomen worden. Neem gerust contact op met onze klantenservice als je hierover vragen hebt.

Je vindt op de website van het Open Web Application Security Project (OWASP, en speciaal voor WordPress op OWASP WordPress Security Implementation Guideline), belangrijke en handige informatie over deze HTTP-headers. Op internet.nl en securityheaders.io vind je meer handige informatie.

Ook van belang is het goed instellen en terugsturen van beveiligde cookies.

Link naar deze kopX-Content-Type-Options

Als je de HTTP-header X-Content-Type-Options de waarde “nosniff” meegeeft dan houdt dat in dat een browser zoals Internet Explorer, en in sommige gevallen Google Chrome, niet zelf probeert te achterhalen welk type bestand wordt gestuurd.

De browser moet uitgaan van het Content-Type dat de website/server terugstuurt.

Windows Server IIS web.config voorbeeld

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<system.webServer>
		<httpProtocol>
            <customHeaders>
                <add name="X-Content-Type-Options" value="nosniff" />
            </customHeaders>
        </httpProtocol>
	</system.webServer>
</configuration>

Linux Apache .htaccess voorbeeld

Header set X-Content-Type-Options nosniff

Link naar deze kopX-Frame-Options

Met X-Frame-Options kun je instellen vanaf welk domein een frame of iframe geladen mag worden. De waarde kan “deny” zijn om het laden van externe frames tegen te gaan, “sameorigin” om alleen frames vanaf hetzelfde domein – of dus jouw website – te tonen, en “allow-from: DOMAIN“, om van een specifiek domein frames te laden. Hierbij moet je DOMAIN dus vervangen door de desbetreffende domeinnaam.

Let op: WordPress zet zelf een X-Frame-Options header ten behoeve van de Customizer. Forceer je deze header met behulp van een .htaccess of web.config-bestand, dan kan dat conflicteren. Dit kan ongewenst gedrag van je website geven. Test dit goed in een staging-website. Je kunt deze header wel zelf plaatsen als je zeker weet dat je website dit niet zelf doet.

Windows Server IIS web.config voorbeeld

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<system.webServer>
		<httpProtocol>
            <customHeaders>
				<add name="X-Frame-Options" value="SAMEORIGIN" />
            </customHeaders>
        </httpProtocol>
	</system.webServer>
</configuration>

Linux Apache .htaccess voorbeeld

Header set X-Frame-Options sameorigin

Link naar deze kopX-XSS-Protection

De X-XSS-Protection header schakelt het Cross Site Scripting filter van browser in. Hiermee wordt het moeilijker gemaakt om via de browser Cross Site Scripting (of XSS) aanvallen uit te voeren op websites.

Deze XSS-beveiliging staat vaak standaard ingeschakeld in browsers, maar mocht een kwaadaardige gebruiker dit hebben gedeactiveerd, dan kun je het hiermee forceren. Geef het de waarde “1; mode=block” mee.

Windows Server IIS web.config voorbeeld

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<system.webServer>
		<httpProtocol>
            <customHeaders>
				<add name="X-XSS-Protection" value="1; mode=block" />
            </customHeaders>
        </httpProtocol>
	</system.webServer>
</configuration>

Linux Apache .htaccess voorbeeld

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

Link naar deze kopServer

Server reactieheader: Een webserver mag graag vertellen welke software hij draait, bijvoorbeeld Windows Server IIS 8.5 of Apache 2.4. Voor aanvallers kan dit heel waardevolle informatie zijn en daarom heeft het de aanbeveling om deze Server: HTTP-reactieheader te verwijderen. In plaats van verwijderen kun je er ook andere, foutieve, informatie inzetten.

Windows Server IIS web.config voorbeeld

Let op: dit voorbeeld werkt alleen op Windows Server 2016 en hoger.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<system.webServer>
		<security>
			<requestFiltering removeServerHeader="true" />
		</security>
	</system.webServer>
</configuration>

Linux Apache .htaccess voorbeeld

Header unset Server

Link naar deze kopContent-Security-Policy

Content-Security-Policy, of CSP, is een heel ingewikkelde header. Hierin moet je precies aangeven welke content wel geladen mag worden op jouw website, en al het andere mag simpelweg niet. Ga je hiermee aan de gang, maak dan veelvuldig gebruik van de Chrome of Firefox hulpprogramma’s console. Deze console is bereikbaar via de sneltoets F12.

Omdat elke website weer anders is kunnen wij helaas geen goed voorbeeld hiervan geven, behalve een klein stukje ter illustratie.

Windows Server IIS web.config voorbeeld

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<system.webServer>
		<httpProtocol>
            <customHeaders>
				<add name="Content-Security-Policy" value="upgrade-insecure-requests;"/>
            </customHeaders>
        </httpProtocol>
	</system.webServer>
</configuration>

Linux Apache .htaccess voorbeeld

Header set Content-Security-Policy "upgrade-insecure-requests;"

Zie http://w3c.github.io/webappsec-csp/ voor alle relevante technische informatie, een beter begrijpbare introductie staat op http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

Wat vind jij van dit antwoord?

Bedankt voor je feedback!

Er is een fout opgetreden. Probeer het later opnieuw.