Comment corriger les attributs de sécurité des cookies dans WordPress

Si InspectWP signale des cookies sans les attributs Secure, HttpOnly ou SameSite, votre site peut être vulnérable au détournement de session, au vol de cookies via XSS ou aux attaques de falsification de requête intersites (CSRF). Ces trois attributs sont les attributs de sécurité de cookies les plus importants, et ils fonctionnent ensemble pour protéger les données de session de vos utilisateurs. Heureusement, les corriger dans WordPress est simple une fois que vous comprenez ce que fait chaque attribut et où l'appliquer.

Comprendre les attributs de sécurité des cookies et leur objectif

Avant d'appliquer les correctifs, il est utile de comprendre contre quoi chaque attribut protège :

• Attribut Secure : Garantit que le cookie n'est envoyé que sur des connexions HTTPS. Sans cet attribut, un cookie peut être transmis sur HTTP non chiffré, permettant à un attaquant sur le même réseau (par exemple, Wi-Fi public) de l'intercepter en utilisant un simple analyseur de paquets. Une fois qu'il a le cookie de session, il peut usurper l'identité de l'utilisateur. Cette attaque est connue sous le nom de détournement de session ou sidejacking.
• Attribut HttpOnly : Empêche JavaScript d'accéder au cookie via document.cookie. C'est une protection critique contre les attaques de cross-site scripting (XSS). Si un attaquant parvient à injecter du JavaScript malveillant dans votre page (via une extension vulnérable, un champ de commentaire ou une saisie utilisateur), l'attribut HttpOnly empêche ce script de lire les cookies de session et de les envoyer à un serveur externe.
• Attribut SameSite : Contrôle si le cookie est envoyé avec les requêtes intersites. Cela protège contre les attaques CSRF, où un site malveillant trompe le navigateur d'un utilisateur pour qu'il effectue des requêtes authentifiées vers votre site. L'attribut SameSite a trois valeurs possibles :
  • Strict : Le cookie n'est jamais envoyé avec les requêtes intersites. Cela offre la plus forte protection mais peut casser les flux de connexion lorsque les utilisateurs cliquent sur des liens depuis des sources externes comme des e-mails ou d'autres sites web.
  • Lax : Le cookie est envoyé avec la navigation de premier niveau (cliquer sur un lien) mais pas avec les requêtes intégrées (images, iframes, AJAX). C'est la valeur par défaut recommandée pour la plupart des sites WordPress.
  • None : Le cookie est envoyé avec toutes les requêtes, y compris intersites. Cela doit être associé à l'attribut Secure et n'est nécessaire que pour les cookies qui doivent fonctionner dans des contextes intersites, comme les intégrations de passerelles de paiement ou les widgets intégrés.

Durcir les cookies d'authentification WordPress

WordPress définit plusieurs cookies pour les utilisateurs connectés, dont wordpress_logged_in_* et wordpress_sec_*. Ce sont les cookies les plus sensibles en matière de sécurité sur votre site car ils contrôlent l'accès administrateur. Pour les durcir, ajoutez les constantes suivantes à votre fichier wp-config.php, avant la ligne qui dit « That's all, stop editing! » :

// Forcer l'envoi des cookies uniquement sur HTTPS
define('FORCE_SSL_ADMIN', true);

// Définir le domaine et le chemin du cookie
define('COOKIE_DOMAIN', 'example.com');
define('COOKIEPATH', '/');

// Durcir les cookies de session PHP
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

La constante FORCE_SSL_ADMIN est particulièrement importante. Elle force WordPress à utiliser HTTPS pour la zone d'administration et les pages de connexion, ce qui garantit que les cookies d'authentification ne sont définis que sur des connexions chiffrées. Sans cela, un utilisateur se connectant via HTTP verrait ses identifiants et cookies transmis en clair.

Notez que @ini_set n'affecte que les cookies de session PHP, pas les cookies spécifiques à WordPress. WordPress utilise ses propres fonctions de définition de cookies qui ne reposent pas sur les sessions PHP. Pour sécuriser spécifiquement les cookies WordPress, vous avez besoin des approches au niveau du serveur décrites ci-dessous.

Définir les attributs de cookies via la configuration PHP

Pour PHP 7.3 et versions ultérieures, vous pouvez définir des attributs de cookies par défaut qui s'appliquent à tous les cookies créés par la fonction setcookie() de PHP. Ajoutez-les à votre fichier php.ini si vous y avez accès :

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

Si vous n'avez pas accès à php.ini (ce qui est courant sur l'hébergement mutualisé), vous pouvez définir ces valeurs dans votre fichier .htaccess à la place :

# Définir les valeurs par défaut sécurisées des cookies pour les sessions PHP
php_value session.cookie_secure 1
php_value session.cookie_httponly 1
php_value session.cookie_samesite "Lax"

Gardez à l'esprit que ces paramètres ne s'appliquent qu'aux cookies créés via la gestion native de session de PHP. Le noyau WordPress et la plupart des extensions utilisent setcookie() ou wp_set_auth_cookie() directement, qui n'héritent pas automatiquement de ces paramètres ini. Pour une couverture complète, l'approche par en-tête au niveau du serveur est plus fiable.

Corriger tous les cookies via Apache .htaccess

La façon la plus fiable d'ajouter des attributs de sécurité à chaque cookie sur un serveur Apache est de modifier l'en-tête Set-Cookie au niveau du serveur. Cela capture tous les cookies, y compris ceux définis par le noyau WordPress, les extensions et les scripts tiers :

# Ajouter des attributs de sécurité à tous les cookies
<IfModule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Placez ceci dans le fichier .htaccess à la racine de votre site. La directive Header always edit utilise une expression régulière pour faire correspondre tous les en-têtes Set-Cookie et ajoute les attributs de sécurité à chacun.

Il y a une mise en garde importante avec cette approche. Si un cookie a déjà l'un de ces attributs définis (par exemple, une extension définit Secure elle-même), vous pourriez vous retrouver avec des attributs dupliqués comme Secure; Secure. La plupart des navigateurs gèrent les doublons avec élégance, mais une approche plus propre utilise un négatif lookahead pour éviter d'ajouter des attributs déjà présents :

<IfModule mod_headers.c>
    # Ajouter l'attribut Secure si pas déjà présent
    Header always edit Set-Cookie "^((?!.*Secure).*)$" "$1; Secure"

    # Ajouter l'attribut HttpOnly si pas déjà présent
    Header always edit Set-Cookie "^((?!.*HttpOnly).*)$" "$1; HttpOnly"

    # Ajouter SameSite=Lax si aucun attribut SameSite n'est présent
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"
</IfModule>

Cette version vérifie chaque cookie individuellement et n'ajoute l'attribut que s'il n'y est pas déjà. C'est plus verbeux mais évite les problèmes potentiels avec les attributs dupliqués.

Corriger tous les cookies via la configuration Nginx

Pour les serveurs Nginx, l'approche dépend de votre version de Nginx :

Nginx 1.19.3 et versions ultérieures prennent en charge la directive proxy_cookie_flags nativement :

# Dans votre bloc server ou location
proxy_cookie_flags ~ secure httponly samesite=lax;

Le ~ correspond à tous les cookies. Vous pouvez également cibler des cookies spécifiques par nom :

# N'appliquer qu'aux cookies de session WordPress
proxy_cookie_flags wordpress_logged_in_* secure httponly samesite=lax;
proxy_cookie_flags wordpress_sec_* secure httponly samesite=lax;

Les versions plus anciennes de Nginx (avant 1.19.3) peuvent utiliser la directive proxy_cookie_path comme solution de contournement :

# Solution de contournement pour les anciennes versions de Nginx
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Si vous utilisez Nginx comme reverse proxy devant Apache ou PHP-FPM, vous devrez peut-être également ajouter des en-têtes en utilisant le module more_set_headers ou la directive add_header. Cependant, add_header ne modifie pas les en-têtes Set-Cookie, donc proxy_cookie_flags est la bonne approche.

Corriger les cookies sur les sites Cloudflare ou via CDN

Si votre site WordPress est derrière Cloudflare ou un autre proxy CDN, la gestion des cookies implique une couche supplémentaire. Cloudflare définit ses propres cookies (comme __cf_bm pour la gestion des bots), et ces cookies sont contrôlés par Cloudflare, pas par votre configuration de serveur. Vous ne pouvez pas ajouter d'attributs de sécurité aux cookies Cloudflare via .htaccess ou la configuration Nginx.

Les cookies Cloudflare incluent déjà les attributs Secure et HttpOnly par défaut. Si InspectWP signale un cookie Cloudflare comme manquant un attribut, il s'agit probablement d'un problème d'affichage ou d'un cookie d'une fonctionnalité Cloudflare qui omet intentionnellement certains attributs (par exemple, les cookies d'analyse qui nécessitent un accès JavaScript peuvent ne pas avoir HttpOnly).

Pour les cookies définis par votre serveur d'origine, les correctifs .htaccess ou Nginx décrits ci-dessus fonctionnent toujours correctement même lorsque Cloudflare est en frontal. Cloudflare transmet les en-têtes Set-Cookie de votre serveur au client sans modification.

Gérer les cookies d'extensions qui n'ont pas d'attributs de sécurité

De nombreuses extensions WordPress définissent leurs propres cookies, et toutes n'incluent pas les attributs de sécurité appropriés. Les coupables courants incluent :

• Extensions de consentement aux cookies : Les extensions comme CookieYes, Complianz ou GDPR Cookie Consent définissent des cookies pour mémoriser le choix de consentement de l'utilisateur. Vérifiez les paramètres de chaque extension pour une option « Cookies sécurisés » ou « Sécurité des cookies ». Certaines extensions ont ajouté ces options dans les versions récentes.
• Extensions d'analyse et de suivi : Google Analytics, Matomo et les extensions similaires peuvent définir des cookies de suivi sans attributs de sécurité. L'approche par en-tête au niveau du serveur (Apache/Nginx) est la meilleure solution pour ceux-ci, car les extensions offrent rarement la configuration des attributs de cookies.
• Extensions de cache : WP Rocket, LiteSpeed Cache et autres définissent des cookies d'identifiant de cache qui peuvent manquer d'attributs. Encore une fois, l'approche au niveau du serveur les gère automatiquement.
• WooCommerce : WooCommerce définit plusieurs cookies pour les données du panier et la gestion de session. Les versions récentes de WooCommerce (5.0+) définissent l'attribut Secure lorsque le site utilise HTTPS, mais les versions plus anciennes peuvent ne pas le faire. Mettez à jour WooCommerce vers la dernière version et appliquez le correctif d'en-tête au niveau du serveur comme filet de sécurité.
• Extensions de connexion et d'adhésion : Les extensions comme MemberPress, Restrict Content Pro ou WP-Members peuvent définir leurs propres cookies de session. Vérifiez les mises à jour des extensions, car beaucoup ont ajouté la prise en charge des attributs de sécurité en réponse aux changements de navigateurs concernant l'application de SameSite.

L'approche au niveau du serveur (Header edit Apache ou proxy_cookie_flags Nginx) est la solution la plus fiable car elle capture tous les cookies indépendamment de l'extension ou du script qui les définit. Même si une mise à jour d'extension supprime les attributs, votre configuration serveur les rajoute.

Considérations spéciales pour les cookies SameSite=None

Certaines fonctionnalités nécessitent que les cookies soient envoyés dans des contextes intersites. Les exemples courants incluent :

• Callbacks de passerelle de paiement : Des services comme PayPal, Stripe ou Mollie peuvent rediriger les utilisateurs vers votre site après paiement. Si votre cookie de session utilise SameSite=Strict, l'utilisateur sera déconnecté après la redirection car le navigateur n'envoie pas le cookie avec la navigation intersite.
• Contenu intégré (iframes) : Si votre site WordPress est intégré dans une iframe sur un autre domaine, les cookies ont besoin de SameSite=None; Secure pour fonctionner. Cela est pertinent pour les configurations WordPress headless ou les sites qui fournissent des widgets intégrables.
• Flux OAuth et SSO : Les implémentations d'authentification unique qui redirigent via des fournisseurs d'identité tiers peuvent nécessiter SameSite=None pour le cookie de session pendant le flux d'authentification.

Si vous avez besoin de SameSite=None pour des cookies spécifiques tout en conservant SameSite=Lax par défaut, vous aurez besoin d'une configuration plus ciblée. Dans Apache :

<IfModule mod_headers.c>
    # Par défaut : ajouter SameSite=Lax à tous les cookies
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"

    # Surcharge pour les cookies spécifiques nécessitant un accès intersite
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Ajouter la sécurité des cookies via une extension WordPress

Si vous n'avez pas accès aux fichiers de configuration du serveur (courant sur l'hébergement WordPress managé), vous pouvez utiliser une extension WordPress pour ajouter des attributs de sécurité aux cookies. L'approche par extension fonctionne en se branchant sur le filtre wp_headers ou en utilisant la fonction header() de PHP pour modifier les en-têtes Set-Cookie avant qu'ils ne soient envoyés au navigateur :

function add_cookie_security_flags($headers) {
    // Cela affecte les en-têtes envoyés par WordPress
    if (is_ssl()) {
        $headers['Set-Cookie'] = 'Secure; HttpOnly; SameSite=Lax';
    }
    return $headers;
}
add_filter('wp_headers', 'add_cookie_security_flags');

// Pour la sécurité des cookies au niveau PHP
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);

Cette approche a des limites. Elle n'affecte que les cookies définis après le déclenchement du hook init de WordPress, et elle ne peut pas modifier les cookies définis par JavaScript ou par des scripts externes. L'approche au niveau du serveur est toujours plus complète.

Vérifier les attributs de sécurité des cookies après application des correctifs

Après avoir implémenté vos correctifs, des tests approfondis sont essentiels pour confirmer que tout fonctionne correctement :

1. Effacer tous les cookies du navigateur : Ouvrez les outils de développement de votre navigateur, allez dans l'onglet Application (Chrome) ou Stockage (Firefox), et supprimez tous les cookies pour votre domaine. Cela garantit que vous testez de nouveaux cookies avec les nouveaux attributs.
2. Visitez votre site et connectez-vous : Après la connexion, retournez aux outils de développement et inspectez chaque cookie. Dans Chrome, le panneau Application > Cookies affiche des colonnes pour Secure, HttpOnly et SameSite. Chaque cookie d'authentification doit afficher une coche pour Secure et HttpOnly, et afficher « Lax » pour SameSite.
3. Tester les flux utilisateur critiques : Naviguez à travers les fonctionnalités clés de votre site : ajoutez des articles à un panier (si WooCommerce), soumettez des formulaires, passez par le processus de paiement et utilisez toutes les fonctionnalités d'adhésion. Les changements SameSite peuvent occasionnellement casser les flux intersites, alors testez tout ce qui implique des redirections depuis des services externes.
4. Tester la connexion depuis des liens externes : Envoyez-vous un e-mail de réinitialisation de mot de passe et cliquez sur le lien. Si vous avez utilisé SameSite=Strict (non recommandé), ce flux peut se casser car le cookie ne sera pas envoyé avec la navigation intersite depuis le client e-mail.
5. Relancer InspectWP : Effectuez une nouvelle analyse de votre site avec InspectWP pour confirmer que tous les avertissements de sécurité des cookies sont résolus. InspectWP vérifie chaque cookie individuellement, vous pouvez donc voir exactement quels cookies ont maintenant les bons attributs.

Dépannage des problèmes courants après l'activation des attributs de sécurité des cookies

• Les utilisateurs sont déconnectés après avoir cliqué sur des liens d'e-mail : Cela se produit lorsque SameSite=Strict est défini. Passez à SameSite=Lax, qui autorise les cookies sur les navigations de premier niveau depuis des sites externes tout en bloquant les requêtes intersites intégrées.
• L'intégration de la passerelle de paiement se casse : Certains processeurs de paiement redirigent les utilisateurs via leur propre domaine pendant le paiement. Si le cookie de session n'est pas envoyé après la redirection, l'utilisateur perd son panier ou son état de connexion. Définissez le cookie de session de paiement sur SameSite=None; Secure spécifiquement, tout en conservant les autres cookies à SameSite=Lax.
• La bannière de consentement aux cookies réapparaît sans cesse : Si le cookie de l'extension de consentement aux cookies est défini sans l'attribut Secure et que votre site redirige HTTP vers HTTPS, le cookie défini sur HTTP n'est pas envoyé sur HTTPS, ce qui fait réapparaître la bannière. Assurez-vous que votre site fonctionne entièrement sur HTTPS et que le cookie de consentement inclut l'attribut Secure.
• Conflits de cache : Certaines extensions de cache mettent en cache les en-têtes Set-Cookie avec le contenu de la page. Après avoir appliqué les changements d'attributs de cookies au niveau du serveur, videz tout votre cache (cache de page et cache d'objets) pour vous assurer que les nouveaux en-têtes prennent effet.
• Attributs de cookies dupliqués : Si vous voyez des attributs comme Secure; Secure ou SameSite=Lax; SameSite=Lax dans vos cookies, vous avez plusieurs couches ajoutant les mêmes attributs. Vérifiez votre .htaccess, wp-config.php, paramètres ini PHP et toute extension de sécurité pour des configurations qui se chevauchent. Utilisez l'approche regex avec négatif lookahead dans .htaccess pour éviter les doublons.

Bonnes pratiques de sécurité des cookies pour WordPress

• Utilisez toujours HTTPS : L'attribut Secure n'a aucun sens sans HTTPS. Assurez-vous que tout votre site se charge sur HTTPS, y compris toutes les ressources (images, scripts, feuilles de style). Utilisez la constante FORCE_SSL_ADMIN et envisagez un en-tête HSTS pour empêcher tout accès HTTP.
• Par défaut sur SameSite=Lax : Cela offre une forte protection CSRF sans casser la navigation normale. N'utilisez SameSite=None que pour les cookies spécifiques qui nécessitent réellement un accès intersite, et n'utilisez SameSite=Strict que si vous êtes certain qu'aucune navigation externe vers votre site n'a besoin de maintenir les sessions.
• Appliquez les attributs au niveau du serveur : La configuration au niveau du serveur (Apache .htaccess ou config Nginx) capture tous les cookies indépendamment de l'origine. C'est plus fiable que les approches au niveau de l'extension ou de PHP.
• Maintenez WordPress et les extensions à jour : Les versions modernes du noyau WordPress et de la plupart des extensions populaires définissent des attributs de cookies appropriés lorsque HTTPS est actif. Garder tout à jour réduit le nombre de cookies non sécurisés que vous devez corriger au niveau du serveur.
• Auditez les cookies régulièrement : Lancez des analyses InspectWP périodiques pour détecter les nouveaux cookies introduits par les mises à jour d'extensions ou les nouvelles intégrations. La sécurité des cookies n'est pas un correctif unique ; elle nécessite une attention continue à mesure que votre site évolue.
• Testez sur plusieurs navigateurs : Chrome, Firefox, Safari et Edge gèrent chacun les attributs de cookies légèrement différemment. Chrome est l'application la plus stricte des politiques SameSite, tandis que Safari a sa propre Intelligent Tracking Prevention qui affecte le comportement des cookies. Testez votre site sur tous les principaux navigateurs après avoir effectué des modifications.