Cookiebeveiligingsvlaggen oplossen in WordPress

Als InspectWP cookies rapporteert zonder de Secure-, HttpOnly- of SameSite-vlaggen, kan uw site kwetsbaar zijn voor sessiehijacking, op XSS gebaseerde cookiediefstal of cross-site request forgery (CSRF)-aanvallen. Deze drie vlaggen zijn de belangrijkste cookiebeveiligingsattributen, en samen beschermen ze de sessiegegevens van uw gebruikers. Gelukkig is het oplossen ervan in WordPress eenvoudig zodra u begrijpt wat elke vlag doet en waar u die moet toepassen.

Cookiebeveiligingsvlaggen en hun doel begrijpen

Voordat u oplossingen toepast, helpt het te begrijpen waartegen elke vlag beschermt:

• Secure-vlag: Zorgt dat de cookie alleen via HTTPS-verbindingen wordt verstuurd. Zonder deze vlag kan een cookie via onversleutelde HTTP worden overgedragen, waardoor een aanvaller op hetzelfde netwerk (bijv. publieke wifi) deze kan onderscheppen met een eenvoudige packet sniffer. Zodra zij de sessiecookie hebben, kunnen zij zich voordoen als de gebruiker. Deze aanval staat bekend als sessiehijacking of sidejacking.
• HttpOnly-vlag: Voorkomt dat JavaScript via document.cookie toegang heeft tot de cookie. Dit is cruciale bescherming tegen cross-site scripting (XSS)-aanvallen. Als een aanvaller erin slaagt schadelijke JavaScript in uw pagina te injecteren (via een kwetsbare plugin, reactieveld of gebruikersinvoer), voorkomt de HttpOnly-vlag dat dat script sessiecookies leest en naar een externe server stuurt.
• SameSite-vlag: Bepaalt of de cookie meegezonden wordt met cross-site verzoeken. Dit beschermt tegen CSRF-aanvallen, waarbij een kwaadaardige site de browser van een gebruiker verleidt om geauthenticeerde verzoeken naar uw site te doen. Het SameSite-attribuut heeft drie mogelijke waarden:
  • Strict: De cookie wordt nooit verzonden bij cross-site verzoeken. Dit biedt de sterkste bescherming, maar kan inlogflows breken wanneer gebruikers op links klikken vanuit externe bronnen zoals e-mails of andere websites.
  • Lax: De cookie wordt verzonden bij top-level navigatie (op een link klikken), maar niet bij ingebedde verzoeken (afbeeldingen, iframes, AJAX). Dit is de aanbevolen standaard voor de meeste WordPress-sites.
  • None: De cookie wordt verzonden bij alle verzoeken, ook cross-site verzoeken. Dit moet worden gecombineerd met de Secure-vlag en is alleen nodig voor cookies die in cross-site contexten moeten functioneren, zoals integraties van betaalproviders of ingebedde widgets.

WordPress-authenticatiecookies harden

WordPress plaatst diverse cookies voor ingelogde gebruikers, waaronder wordpress_logged_in_* en wordpress_sec_*. Dit zijn de meest beveiligingsgevoelige cookies op uw site, omdat ze de admintoegang regelen. Om deze te harden, voegt u de volgende constanten toe aan uw wp-config.php-bestand, vóór de regel die zegt "That's all, stop editing!":

// Forceer dat cookies alleen via HTTPS worden verzonden
define('FORCE_SSL_ADMIN', true);

// Stel cookiedomein en pad in
define('COOKIE_DOMAIN', 'example.com');
define('COOKIEPATH', '/');

// Hard PHP-sessiecookies
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

De constante FORCE_SSL_ADMIN is bijzonder belangrijk. Hij dwingt WordPress om HTTPS te gebruiken voor het adminpaneel en de inlogpagina's, wat ervoor zorgt dat authenticatiecookies alleen via versleutelde verbindingen worden geplaatst. Zonder dit zou een gebruiker die via HTTP inlogt zijn inloggegevens en cookies in platte tekst overdragen.

Let op dat @ini_set alleen invloed heeft op PHP-sessiecookies, niet op de WordPress-specifieke cookies. WordPress gebruikt zijn eigen cookieplaatsingsfuncties die niet afhangen van PHP-sessies. Om specifiek WordPress-cookies te beveiligen, hebt u de hieronder beschreven server-niveau-aanpakken nodig.

Cookievlaggen instellen via PHP-configuratie

Voor PHP 7.3 en later kunt u standaard cookieattributen instellen die van toepassing zijn op alle cookies die door PHP's setcookie()-functie worden aangemaakt. Voeg deze toe aan uw php.ini-bestand als u toegang hebt:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Hebt u geen toegang tot php.ini (gebruikelijk op shared hosting), dan kunt u deze waarden in plaats daarvan in uw .htaccess-bestand instellen:

# Stel veilige cookiestandaarden in voor PHP-sessies
php_value session.cookie_secure 1
php_value session.cookie_httponly 1
php_value session.cookie_samesite "Lax"

Houd er rekening mee dat deze instellingen alleen van toepassing zijn op cookies die via PHP's native sessieafhandeling worden aangemaakt. WordPress core en de meeste plugins gebruiken setcookie() of wp_set_auth_cookie() rechtstreeks, die deze ini-instellingen niet automatisch overerven. Voor uitgebreide dekking is de aanpak op serverniveau via koptekst betrouwbaarder.

Alle cookies oplossen via Apache .htaccess

De meest betrouwbare manier om beveiligingsvlaggen aan elke cookie op een Apache-server toe te voegen, is door de Set-Cookie-koptekst op serverniveau te wijzigen. Dit vangt alle cookies af, inclusief die welke door WordPress core, plugins en third-party scripts worden geplaatst:

# Voeg beveiligingsvlaggen toe aan alle cookies
<IfModule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Plaats dit in het hoofd-.htaccess-bestand van uw site. De directive Header always edit gebruikt een reguliere expressie om alle Set-Cookie-koptekst te matchen en voegt de beveiligingsvlaggen aan elke toe.

Er is een belangrijke kanttekening bij deze aanpak. Als een cookie al een van deze vlaggen heeft (bijv. een plugin plaatst zelf Secure), kunt u eindigen met dubbele vlaggen zoals Secure; Secure. De meeste browsers gaan netjes om met duplicaten, maar een schonere aanpak gebruikt een negative lookahead om te voorkomen dat reeds aanwezige vlaggen worden toegevoegd:

<IfModule mod_headers.c>
    # Voeg Secure-vlag toe als die nog niet aanwezig is
    Header always edit Set-Cookie "^((?!.*Secure).*)$" "$1; Secure"

    # Voeg HttpOnly-vlag toe als die nog niet aanwezig is
    Header always edit Set-Cookie "^((?!.*HttpOnly).*)$" "$1; HttpOnly"

    # Voeg SameSite=Lax toe als er geen SameSite-attribuut aanwezig is
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"
</IfModule>

Deze versie controleert elke cookie afzonderlijk en voegt de vlag alleen toe als deze er nog niet is. Het is uitvoeriger, maar voorkomt mogelijke problemen met dubbele attributen.

Alle cookies oplossen via Nginx-configuratie

Voor Nginx-servers hangt de aanpak af van uw Nginx-versie:

Nginx 1.19.3 en later ondersteunt de directive proxy_cookie_flags native:

# In uw server- of locationblok
proxy_cookie_flags ~ secure httponly samesite=lax;

De ~ matcht alle cookies. U kunt ook specifieke cookies bij naam targeten:

# Pas alleen toe op WordPress-sessiecookies
proxy_cookie_flags wordpress_logged_in_* secure httponly samesite=lax;
proxy_cookie_flags wordpress_sec_* secure httponly samesite=lax;

Oudere Nginx-versies (vóór 1.19.3) kunnen de directive proxy_cookie_path als workaround gebruiken:

# Workaround voor oudere Nginx-versies
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Als u Nginx als reverse proxy voor Apache of PHP-FPM gebruikt, moet u mogelijk ook koptekst toevoegen via de module more_set_headers of de directive add_header. Echter, add_header wijzigt geen Set-Cookie-koptekst, dus proxy_cookie_flags is de juiste aanpak.

Cookies oplossen op via Cloudflare of CDN geproxyde sites

Als uw WordPress-site achter Cloudflare of een andere CDN-proxy zit, komt er een extra laag bij cookieafhandeling. Cloudflare plaatst zijn eigen cookies (zoals __cf_bm voor botbeheer), en deze cookies worden door Cloudflare beheerd, niet door uw serverconfiguratie. U kunt geen beveiligingsvlaggen toevoegen aan Cloudflare-cookies via .htaccess of Nginx-config.

Cloudflare-cookies bevatten standaard al de Secure- en HttpOnly-vlaggen. Als InspectWP een Cloudflare-cookie markeert als ontbrekend van een vlag, gaat het waarschijnlijk om een weergaveprobleem of een cookie van een Cloudflare-functie die opzettelijk bepaalde vlaggen weglaat (bijv. analyticscookies die JavaScript-toegang nodig hebben en daarom HttpOnly missen).

Voor cookies die door uw originserver worden geplaatst, werken de hierboven beschreven .htaccess- of Nginx-oplossingen ook correct wanneer Cloudflare ervoor staat. Cloudflare laat Set-Cookie-koptekst van uw server zonder wijziging door naar de client.

Plugincookies aanpakken die geen beveiligingsvlaggen hebben

Veel WordPress-plugins plaatsen hun eigen cookies, en niet alle bevatten correcte beveiligingsvlaggen. Veelvoorkomende boosdoeners zijn:

• Cookietoestemmingsplugins: Plugins zoals CookieYes, Complianz of GDPR Cookie Consent plaatsen cookies om de toestemmingskeuze van de gebruiker te onthouden. Controleer in de instellingen van elke plugin op een optie "Veilige cookies" of "Cookiebeveiliging". Sommige plugins hebben deze opties in recente versies toegevoegd.
• Analytics- en trackingplugins: Google Analytics, Matomo en soortgelijke plugins kunnen trackingcookies plaatsen zonder beveiligingsvlaggen. De aanpak op serverniveau (Apache/Nginx) is de beste oplossing voor deze, aangezien plugins zelden cookievlaggenconfiguratie bieden.
• Cachingplugins: WP Rocket, LiteSpeed Cache en andere plaatsen cache-identificatiecookies die mogelijk vlaggen missen. Ook hier handelt de aanpak op serverniveau dit automatisch af.
• WooCommerce: WooCommerce plaatst diverse cookies voor winkelwagengegevens en sessiebeheer. Recente versies van WooCommerce (5.0+) plaatsen de Secure-vlag wanneer de site HTTPS gebruikt, maar oudere versies mogelijk niet. Werk WooCommerce bij naar de nieuwste versie en pas de header-oplossing op serverniveau toe als veiligheidsnet.
• Login- en lidmaatschapsplugins: Plugins zoals MemberPress, Restrict Content Pro of WP-Members plaatsen mogelijk hun eigen sessiecookies. Controleer op plugin-updates, want velen hebben ondersteuning voor beveiligingsvlaggen toegevoegd als reactie op browserwijzigingen rond SameSite-handhaving.

De aanpak op serverniveau (Apache Header edit of Nginx proxy_cookie_flags) is de meest betrouwbare oplossing, omdat hij alle cookies vangt ongeacht welke plugin of welk script ze plaatst. Zelfs als een plugin-update de vlaggen verwijdert, voegt uw serverconfiguratie ze weer toe.

Speciale overwegingen voor SameSite=None-cookies

Sommige functionaliteit vereist dat cookies in cross-site contexten worden verzonden. Veelvoorkomende voorbeelden zijn:

• Callbacks van betaalproviders: Diensten als PayPal, Stripe of Mollie kunnen gebruikers na betaling terug naar uw site sturen. Als uw sessiecookie SameSite=Strict gebruikt, wordt de gebruiker na de redirect uitgelogd, omdat de browser de cookie niet verstuurt bij de cross-site navigatie.
• Ingebedde inhoud (iframes): Als uw WordPress-site is ingebed in een iframe op een ander domein, hebben cookies SameSite=None; Secure nodig om te functioneren. Dit is relevant voor headless-WordPress-opzetten of sites die embedbare widgets aanbieden.
• OAuth- en SSO-flows: Single sign-on-implementaties die via third-party identityproviders redirecten, kunnen SameSite=None nodig hebben voor de sessiecookie tijdens de authenticatieflow.

Als u SameSite=None nodig hebt voor specifieke cookies en tegelijkertijd SameSite=Lax als standaard wilt aanhouden, hebt u een gerichtere configuratie nodig. In Apache:

<IfModule mod_headers.c>
    # Standaard: voeg SameSite=Lax toe aan alle cookies
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"

    # Override voor specifieke cookies die cross-site-toegang nodig hebben
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Cookiebeveiliging toevoegen via een WordPress-plugin

Hebt u geen toegang tot serverconfiguratiebestanden (gebruikelijk bij beheerde WordPress-hosting), dan kunt u een WordPress-plugin gebruiken om cookiebeveiligingsvlaggen toe te voegen. De pluginaanpak werkt door in te haken op het filter wp_headers of door PHP's header()-functie te gebruiken om Set-Cookie-koptekst aan te passen voordat ze naar de browser worden verzonden:

function add_cookie_security_flags($headers) {
    // Dit beïnvloedt koptekst die door WordPress wordt verzonden
    if (is_ssl()) {
        $headers['Set-Cookie'] = 'Secure; HttpOnly; SameSite=Lax';
    }
    return $headers;
}
add_filter('wp_headers', 'add_cookie_security_flags');

// Voor cookiebeveiliging op PHP-niveau
function enforce_cookie_security() {
    if (is_ssl() && PHP_VERSION_ID >= 70300) {
        ini_set('session.cookie_secure', '1');
        ini_set('session.cookie_httponly', '1');
        ini_set('session.cookie_samesite', 'Lax');
    }
}
add_action('init', 'enforce_cookie_security', 1);

Deze aanpak heeft beperkingen. Hij beïnvloedt alleen cookies die worden geplaatst nadat de WordPress-init-hook is afgevuurd, en hij kan geen cookies wijzigen die door JavaScript of door externe scripts worden geplaatst. De aanpak op serverniveau is altijd uitgebreider.

Cookiebeveiligingsvlaggen verifiëren na het toepassen van oplossingen

Na het implementeren van uw oplossingen is grondig testen essentieel om te bevestigen dat alles correct werkt:

1. Wis alle browsercookies: Open de developer tools van uw browser, ga naar het tabblad Application (Chrome) of Storage (Firefox) en verwijder alle cookies voor uw domein. Zo test u verse cookies met de nieuwe vlaggen.
2. Bezoek uw site en log in: Ga na het inloggen terug naar de developer tools en inspecteer elke cookie. In Chrome toont het paneel Application > Cookies kolommen voor Secure, HttpOnly en SameSite. Elke authenticatiecookie zou een vinkje moeten tonen voor Secure en HttpOnly, en "Lax" weergeven voor SameSite.
3. Test kritieke gebruikersflows: Navigeer door de belangrijkste functionaliteit van uw site: voeg artikelen aan een winkelwagen toe (bij WooCommerce), verstuur formulieren, doorloop het afrekenproces en gebruik eventuele lidmaatschapsfuncties. SameSite-wijzigingen kunnen incidenteel cross-site flows breken; test daarom alles wat redirects vanaf externe diensten omvat.
4. Test inloggen vanaf externe links: Stuur uzelf een wachtwoordreset-e-mail en klik op de link. Hebt u SameSite=Strict gebruikt (niet aanbevolen), dan kan deze flow breken omdat de cookie niet wordt verstuurd bij de cross-site navigatie vanuit de e-mailclient.
5. Voer InspectWP opnieuw uit: Voer een nieuwe scan van uw site uit met InspectWP om te bevestigen dat alle cookiebeveiligingswaarschuwingen zijn opgelost. InspectWP controleert elke cookie afzonderlijk, zodat u precies kunt zien welke cookies nu de juiste vlaggen hebben.

Veelvoorkomende problemen na het inschakelen van cookiebeveiligingsvlaggen oplossen

• Gebruikers worden uitgelogd na het klikken op e-maillinks: Dit gebeurt wanneer SameSite=Strict is ingesteld. Schakel over op SameSite=Lax, dat cookies toestaat bij top-level navigaties vanaf externe sites en tegelijk ingebedde cross-site verzoeken blokkeert.
• Integratie met betaalprovider werkt niet: Sommige betaalproviders sturen gebruikers tijdens het afrekenen via hun eigen domein. Als de sessiecookie na de redirect niet wordt verzonden, verliest de gebruiker zijn winkelwagen of inlogstatus. Stel de cookie van de betaalsessie specifiek in op SameSite=None; Secure, terwijl andere cookies op SameSite=Lax blijven staan.
• Cookietoestemmingsbanner blijft verschijnen: Als de cookie van de cookietoestemmingsplugin zonder de Secure-vlag wordt geplaatst en uw site HTTP naar HTTPS redirect, wordt de op HTTP geplaatste cookie niet via HTTPS verzonden, waardoor de banner opnieuw verschijnt. Zorg dat uw site volledig op HTTPS draait en dat de toestemmingscookie de Secure-vlag bevat.
• Cachingconflicten: Sommige cachingplugins cachen de Set-Cookie-koptekst samen met de pagina-inhoud. Wis na het toepassen van wijzigingen in cookievlaggen op serverniveau uw volledige cache (zowel paginacache als object cache) om te zorgen dat de nieuwe koptekst van kracht wordt.
• Dubbele cookievlaggen: Ziet u attributen als Secure; Secure of SameSite=Lax; SameSite=Lax in uw cookies, dan voegen meerdere lagen dezelfde vlaggen toe. Controleer uw .htaccess, wp-config.php, PHP-ini-instellingen en eventuele beveiligingsplugins op overlappende configuraties. Gebruik de negative-lookahead-regex-aanpak in .htaccess om duplicaten te voorkomen.

Best practices voor cookiebeveiliging in WordPress

• Gebruik altijd HTTPS: De Secure-vlag is zinloos zonder HTTPS. Zorg dat uw volledige site via HTTPS laadt, inclusief alle resources (afbeeldingen, scripts, stylesheets). Gebruik de constante FORCE_SSL_ADMIN en overweeg een HSTS-koptekst om elke HTTP-toegang te voorkomen.
• Standaard SameSite=Lax: Dit biedt sterke CSRF-bescherming zonder normale navigatie te breken. Gebruik SameSite=None alleen voor specifieke cookies die echt cross-site-toegang nodig hebben, en gebruik SameSite=Strict alleen als u zeker weet dat geen externe navigatie naar uw site sessies hoeft te behouden.
• Pas vlaggen op serverniveau toe: Configuratie op serverniveau (Apache .htaccess of Nginx-config) vangt alle cookies ongeacht herkomst. Dit is betrouwbaarder dan benaderingen op plugin- of PHP-niveau.
• Houd WordPress en plugins bijgewerkt: Moderne versies van WordPress core en de meeste populaire plugins plaatsen correcte cookievlaggen wanneer HTTPS actief is. Alles bijgewerkt houden vermindert het aantal onveilige cookies dat u op serverniveau moet oplossen.
• Audit cookies regelmatig: Voer periodiek InspectWP-scans uit om nieuwe cookies te ontdekken die door plugin-updates of nieuwe integraties worden geïntroduceerd. Cookiebeveiliging is geen eenmalige fix; het vereist voortdurende aandacht naarmate uw site evolueert.
• Test op meerdere browsers: Chrome, Firefox, Safari en Edge gaan elk iets anders om met cookieattributen. Chrome is de strengste handhaver van SameSite-beleid, terwijl Safari zijn eigen Intelligent Tracking Prevention heeft die invloed heeft op cookiegedrag. Test uw site na wijzigingen op alle grote browsers.