Hoe u ontbrekende beveiligingskoptekst-en toevoegt in WordPress

Beveiligingskoptekst-en zijn HTTP-responskoptekst-en die browsers vertellen ingebouwde beveiligingsfuncties te activeren. De meeste WordPress-sites missen standaard verschillende van deze koptekst-en omdat noch WordPress-core noch de meeste hostingproviders ze automatisch instellen. Het goede nieuws is dat het toevoegen ervan slechts enkele minuten kost, en de beveiligingsverbetering aanzienlijk is. Deze gids behandelt elke belangrijke beveiligingskoptekst, legt uit wat elk doet en laat zien hoe u ze allemaal in één keer kunt toevoegen.

Welke beveiligingskoptekst-en zou elke WordPress-site moeten hebben?

Hier is de complete lijst aanbevolen beveiligingskoptekst-en met hun waarden en waar zij tegen beschermen:

• X-Frame-Options: SAMEORIGIN: voorkomt dat uw site in een iframe op een ander domein wordt geladen. Dit voorkomt clickjacking-aanvallen waarbij een kwaadaardige site onzichtbare knoppen over uw pagina legt.
• X-Content-Type-Options: nosniff: belet browsers het MIME-type van een bestand te raden. Zonder dit zou een aanvaller een bestand kunnen uploaden dat eruitziet als een afbeelding maar JavaScript bevat, en de browser zou het kunnen uitvoeren.
• Referrer-Policy: strict-origin-when-cross-origin: bepaalt hoeveel URL-informatie wordt gedeeld wanneer gebruikers links naar andere sites volgen. Deze instelling stuurt de volledige URL voor verzoeken binnen dezelfde origin maar alleen het domein voor cross-origin-verzoeken, wat gevoelige URL-parameters beschermt.
• Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(): schakelt browserfuncties uit die uw site niet gebruikt. De lege haakjes betekenen "niemand mag deze functie gebruiken", wat voorkomt dat kwaadaardige scripts toegang krijgen tot camera, microfoon of locatie.
• Strict-Transport-Security: max-age=31536000; includeSubDomains: dwingt browsers altijd HTTPS te gebruiken. Zie onze speciale HSTS-gids voor details over een veilige uitrol.
• X-XSS-Protection: 1; mode=block: een legacy-koptekst voor oudere browsers die het ingebouwde XSS-filter inschakelt. Moderne browsers hebben dit ten gunste van CSP afgeschaft, maar het opnemen voor achterwaartse compatibiliteit kan geen kwaad.
• Content-Security-Policy: de krachtigste (en complexste) beveiligingskoptekst. Zie onze speciale CSP-gids voor een complete uitleg.

Hoe te prioriteren: welke koptekst-en eerst toevoegen

Voegt u voor de eerste keer beveiligingskoptekst-en toe, dan is dit de volgorde die u de grootste beveiligingsverbetering geeft met het minste risico:

1. X-Content-Type-Options: nul risico op het breken van iets. Voeg het gewoon toe.
2. X-Frame-Options: veilig tenzij u uw site bewust in iframes op andere domeinen insluit (onwaarschijnlijk voor de meeste WordPress-sites).
3. Referrer-Policy: zeer laag risico. De aanbevolen waarde strict-origin-when-cross-origin is in moderne browsers al het standaardgedrag.
4. Permissions-Policy: laag risico tenzij uw site daadwerkelijk de camera-, microfoon- of geolocatie-API's gebruikt.
5. X-XSS-Protection: legacy-koptekst, geen enkel risico.
6. Strict-Transport-Security: vereist eerst werkende HTTPS. Volg een geleidelijke uitrol (zie onze HSTS-gids).
7. Content-Security-Policy: hoogste risico op het breken van zaken op WordPress. Begin altijd met Report-Only-modus (zie onze CSP-gids).

Alle koptekst-en toevoegen via Apache .htaccess

Dit is de meest gangbare methode voor WordPress-sites op shared hosting. Open het .htaccess-bestand in uw WordPress-hoofdmap en voeg het volgende blok toe. Plaats het vóór de # BEGIN WordPress-sectie om de boel overzichtelijk te houden:

<IfModule mod_headers.c>
    # Prevent clickjacking
    Header always set X-Frame-Options "SAMEORIGIN"

    # Prevent MIME-type sniffing
    Header always set X-Content-Type-Options "nosniff"

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

    # Restrict browser features
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"

    # Force HTTPS (only add if SSL is fully working)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # XSS Protection for legacy browsers
    Header always set X-XSS-Protection "1; mode=block"
</IfModule>

Een paar dingen om in gedachten te houden:

• De IfModule-wrapper zorgt dat Apache geen 500-fout geeft als mod_headers niet ingeschakeld is op uw server.
• Het gebruik van Header always set (in plaats van enkel Header set) zorgt dat de koptekst-en bij alle responses worden verstuurd, inclusief foutpagina's.
• Heeft u al een <IfModule mod_headers.c>-blok in uw .htaccess, voeg de afzonderlijke Header-regels dan binnen dat bestaande blok toe in plaats van een dubbel blok aan te maken.

Alle koptekst-en toevoegen via Nginx

Draait uw WordPress-site op Nginx (gangbaar bij managed WordPress-hosts zoals Kinsta, Cloudways, GridPane of SpinupWP), voeg deze regels dan toe binnen uw server-blok:

# Security Headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-XSS-Protection "1; mode=block" always;

Belangrijke Nginx-specifieke aandachtspunten:

• Het sleutelwoord always verstuurt de koptekst bij alle responscodes (inclusief 4xx en 5xx). Zonder dit verstuurt Nginx koptekst-en alleen bij 2xx-responses.
• Heeft u een afzonderlijk location-blok dat PHP afhandelt (bijv. location ~ .php$), dan kan het zijn dat u de koptekst-en daar ook moet toevoegen, afhankelijk van uw Nginx-configuratie. Nginx erft add_header-richtlijnen niet uit ouderblokken als het kindblok zijn eigen add_header heeft.
• Test en herlaad altijd na wijzigingen: sudo nginx -t && sudo systemctl reload nginx.

Koptekst-en toevoegen via PHP in WordPress

Heeft u geen toegang tot serverconfiguratiebestanden, dan kunt u beveiligingskoptekst-en vanuit PHP versturen. Voeg dit toe aan de functions.php van uw thema of aan een aangepaste site-specifieke plug-in:

function iwp_add_security_headers() {
    if ( is_admin() ) {
        return;
    }

    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'X-Content-Type-Options: nosniff' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()' );
    header( 'X-XSS-Protection: 1; mode=block' );
}
add_action( 'send_headers', 'iwp_add_security_headers' );

De is_admin()-controle slaat het WordPress-beheergedeelte over om mogelijke conflicten met beheerfunctionaliteit te vermijden. Let op dat deze PHP-aanpak een beperking heeft: hij geldt alleen voor pagina's die WordPress verwerkt. Statische bestanden (afbeeldingen, CSS, JS, lettertypen) die direct door uw webserver worden geserveerd, dragen deze koptekst-en niet. Voor volledige dekking is configuratie op serverniveau altijd de betere keuze.

WordPress-plug-ins voor beveiligingskoptekst-en

Geeft u de voorkeur aan een plug-in-aanpak, dan bieden deze opties een gebruiksvriendelijke interface voor het beheren van beveiligingskoptekst-en:

• HTTP Headers: een gratis plug-in met een uitgebreide UI voor het instellen van alle beveiligingskoptekst-en. Hij ondersteunt X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy en meer. U configureert alles vanuit het WordPress-beheergedeelte zonder bestanden aan te raken.
• Really Simple SSL Pro: de premium-versie bevat een module voor beveiligingskoptekst-en waarmee u individuele koptekst-en kunt aan- of uitzetten. Hij geeft ook aanbevelingen en legt elke koptekst uit.
• Headers Security Advanced & HSTS WP: een gerichte plug-in specifiek voor beveiligingskoptekst-en. Hij dekt alle belangrijke koptekst-en en bevat presets voor veelvoorkomende configuraties.
• Security Headers van Jeremykendall: een lichtgewicht optie die alle aanbevolen koptekst-en met zinvolle standaardwaarden toevoegt.

Hoewel plug-ins handig zijn, hebben zij nadelen. Wordt de plug-in gedeactiveerd, met een bug bijgewerkt of verwijderd, dan verdwijnen uw beveiligingskoptekst-en direct. Voor productiesites is configuratie op serverniveau betrouwbaarder, omdat het niet afhankelijk is van WordPress of een actieve plug-in.

Uw koptekst-en testen met online tools

Verifieer uw koptekst-en na het toevoegen met deze gratis tools:

• securityheaders.com: voer uw URL in en ontvang een beoordeling van A+ tot F samen met een gedetailleerd overzicht van welke koptekst-en aanwezig zijn en welke ontbreken. Streef naar minimaal een A-beoordeling.
• observatory.mozilla.org: de tool van Mozilla voert een uitgebreidere analyse uit, inclusief CSP-evaluatie en cookiebeveiliging.
• Browser-DevTools: druk op F12, ga naar het tabblad Network, klik op het hoofddocumentverzoek en scroll naar Response Headers om precies te zien wat uw server stuurt.

U kunt ook vanaf de commandoregel controleren:

curl -sI https://example.com

Dit toont alle responskoptekst-en, inclusief uw nieuw toegevoegde beveiligingskoptekst-en.

CDN- en reverse-proxy-overwegingen

Zit uw WordPress-site achter een CDN zoals Cloudflare, Sucuri of Fastly, wees u er dan van bewust dat het CDN koptekst-en kan strippen, overschrijven of zijn eigen kan toevoegen. Hier is wat u moet weten:

• Cloudflare: stript standaard geen beveiligingskoptekst-en, dus koptekst-en die op uw origin-server zijn ingesteld worden doorgegeven. Cloudflare biedt ook eigen instellingen voor beveiligingskoptekst-en in het dashboard onder SSL/TLS > Edge Certificates (voor HSTS) en in managed rules.
• Sucuri: hun firewall kan automatisch enkele beveiligingskoptekst-en toevoegen. Controleer de instellingen in uw Sucuri-dashboard om te zien welke actief zijn en duplicaten te vermijden.
• Fastly / KeyCDN / BunnyCDN: de meeste CDN's laten u aangepaste responskoptekst-en in hun configuratiepaneel toevoegen. Dit kan een goed alternatief zijn als u de serverconfiguratie op uw origin niet kunt wijzigen.

Ziet u dubbele koptekst-en in uw response (bijv. twee X-Frame-Options-regels), dan kan dit onvoorspelbaar browsergedrag veroorzaken. Zorg dat elke koptekst slechts op één plek wordt ingesteld: ofwel op uw origin-server, ofwel op CDN-niveau, niet beide.

Veelvoorkomende fouten bij het toevoegen van beveiligingskoptekst-en

• Dubbele IfModule-blokken: heeft uw .htaccess al een <IfModule mod_headers.c>-blok (mogelijk van een plug-in), dan kan het toevoegen van een tweede conflicten veroorzaken. Voeg uw koptekst-en samen in het bestaande blok.
• Koptekst-en alleen via PHP instellen: dit mist alle statische bestanden. Gebruik configuratie op serverniveau voor volledige dekking.
• Koptekst-en overschrijven in location-blokken (Nginx): heeft een kind-location-blok ook maar één add_header, dan vervangt het alle koptekst-en uit het ouderblok. U dient alle koptekst-en te herhalen in elk location-blok dat zijn eigen definieert.
• Niet testen na plug-in-updates: een plug-in-update of themawisseling kan uw PHP-gebaseerde koptekst-en verwijderen. Test altijd opnieuw na grote wijzigingen.
• Subdomeinen vergeten: heeft u subdomeinen (staging, mail enzovoort), zorg dan dat ook deze beveiligingskoptekst-en geconfigureerd hebben. Aanvallers richten zich vaak op het zwakste subdomein.

Verifieer uw beveiligingskoptekst-en met InspectWP

Voer na het toevoegen van alle koptekst-en een nieuwe InspectWP-scan op uw WordPress-site uit. De beveiligingssectie van uw rapport somt elke beveiligingskoptekst op en toont de status. Elke koptekst die aanwezig en correct geconfigureerd is, verschijnt als groen. Ontbrekende koptekst-en verschijnen als rood of geel, afhankelijk van hun belang. Gebruik de functie automatische rapporten van InspectWP om uw koptekst-en in de tijd te monitoren en regressies door serverwijzigingen of plug-in-updates op te sporen.