Header HTTP : Guide complet pour sécuriser son site web PHP

La sécurité d’un site web est un enjeu crucial, et l’une des premières lignes de défense repose sur les Header HTTP en PHP. Ces en-têtes permettent de protéger votre application contre différentes attaques, comme le clickjacking, l’injection de scripts ou encore l’exploitation de failles MIME.

Nous allons voir comment sécuriser les headers en PHP en configurant des directives essentielles telles que X-Frame-Options PHP pour empêcher l’affichage de votre site dans un iframe malveillant, ou encore Content Security Policy en PHP (CSP), qui bloque l’exécution de scripts non autorisés et renforce la protection contre le cross-site scripting (XSS).

📌 Pourquoi un Header HTTP est important ?
Sans une configuration correcte de ces headers, votre site reste vulnérable à des attaques qui peuvent compromettre les données de vos utilisateurs et nuire à votre réputation. Heureusement, en quelques lignes de code PHP, il est possible de mettre en place une protection efficace.

Dans ce guide, nous allons passer en revue les headers HTTP essentiels à implémenter en PHP, expliquer leur rôle et voir comment les configurer pour renforcer la sécurité de votre site web.

Comment sécuriser son site web PHP grâce au Header HTTP ?

La sécurité d’un site web est un enjeu majeur pour tout développeur. En PHP, l’utilisation des headers HTTP permet de renforcer cette sécurité en contrôlant les interactions entre le serveur et le navigateur. Nous allons explorer les headers PHP essentiels pour protéger votre site contre les attaques courantes.

Qu’est-ce qu’un header HTTP ?

Les headers HTTP sont des métadonnées envoyées par le serveur au navigateur avant d’afficher la page. Ils peuvent être utilisés pour définir des règles de sécurité, empêcher des attaques ou améliorer les performances de votre site.

En PHP, on utilise la fonction header() pour envoyer ces directives.

Un header HTTP (ou en-tête HTTP) est un message que votre site web envoie au navigateur (Chrome, Firefox…) à chaque fois qu’une page est chargée.

Imaginez que vous envoyez un colis (votre page web) à un ami (le navigateur). Sur ce colis, il y a une étiquette avec des informations importantes comme :

• Qui a envoyé le colis ?
• Ce qu’il contient (livre, vêtement…)
• S’il doit être ouvert immédiatement ou plus tard
• S’il faut une signature à la réception

Un header HTTP, c’est comme cette étiquette ! Il donne des instructions au navigateur sur la manière de gérer la page web.

Exemples concrets de headers HTTP :

• « Content-Type » → Indique au navigateur quel type de contenu il reçoit (exemple : text/html pour une page web).
• « X-Frame-Options: DENY » → Interdit d’afficher votre site dans un cadre (iframe) pour éviter certaines attaques.
• « Strict-Transport-Security » → Force l’utilisation du HTTPS au lieu du HTTP pour plus de sécurité.

Header HTTP X-Frame-Options → Protection contre le clickjacking

Parmi les attaques les plus sournoises, il y a le clickjacking. Heureusement, il existe une solution simple pour s’en protéger : le header HTTP X-Frame-Options.

Le clickjacking, c’est quoi ?

Le clickjacking (ou détournement de clic) est une attaque qui consiste à piéger un utilisateur en affichant une page légitime à l’intérieur d’un iframe invisible sur un site malveillant.

📌 Exemple concret :
Imaginons que vous avez un site où les utilisateurs peuvent cliquer sur un bouton pour confirmer un paiement ou se déconnecter. Un pirate peut créer une page malveillante et y insérer votre site dans un iframe invisible. Il va ensuite afficher un faux bouton au-dessus de l’iframe, incitant l’utilisateur à cliquer. Résultat : la victime pense cliquer sur un bouton inoffensif, mais en réalité, elle interagit avec votre site (ex. : en validant un paiement à son insu).

Comment bloquer cette attaque ?

La solution est d’empêcher votre site d’être affiché dans un iframe en utilisant le header HTTP X-Frame-Options. Ce header indique au navigateur s’il est autorisé ou non à afficher votre site dans un iframe.

En PHP, il suffit d’ajouter cette ligne en haut de vos pages :

header("X-Frame-Options: DENY");

Avec cette directive, votre site ne pourra jamais être chargé dans un iframe, ce qui bloque totalement le clickjacking.

Autres options pour X-Frame-Options

Selon votre besoin, il existe trois valeurs possibles pour ce header :

• DENY → Interdit totalement l’affichage dans un iframe (recommandé pour la sécurité).

  header("X-Frame-Options: DENY");

• SAMEORIGIN → Autorise l’affichage dans un iframe uniquement si la page vient du même site.📌 Exemple : utile si vous avez une application interne qui utilise des iframes mais que vous voulez bloquer les sites externes.

  header("X-Frame-Options: SAMEORIGIN");

• ALLOW-FROM [URL] → Autorise un site spécifique à afficher votre page dans un iframe (⚠️ cette option est obsolète et peu supportée).

  header("X-Frame-Options: ALLOW-FROM https://exemple.com");

Le clickjacking est une menace sérieuse qui peut piéger les utilisateurs et compromettre leur sécurité. Grâce au header X-Frame-Options, vous pouvez facilement empêcher votre site d’être embarqué dans un iframe malveillant.

✅ Bonnes pratiques :

• Si votre site n’a pas besoin d’être affiché dans un iframe, utilisez DENY.
• Si vous avez des iframes internes, préférez SAMEORIGIN.

En appliquant cette simple protection, vous améliorez significativement la sécurité de votre site contre les attaques de type clickjacking.

Header HTTP Content-Security-Policy (CSP) → Protection contre les attaques XSS

L’une des plus dangereuses est l’injection de scripts ou XSS (Cross-Site Scripting). Heureusement, il existe une solution efficace pour s’en prémunir : le header HTTP Content-Security-Policy (CSP).

L’attaque XSS, c’est quoi ?

L’XSS (Cross-Site Scripting) est une attaque qui consiste à injecter du code JavaScript malveillant dans une page web. Une fois exécuté, ce script peut :
✅ Voler des informations sensibles (cookies, identifiants, etc.).
✅ Rediriger l’utilisateur vers un faux site pour le piéger.
✅ Afficher du contenu frauduleux sur votre site.

📌 Exemple concret :
Imaginons que votre site affiche des commentaires laissés par les visiteurs. Sans protection, un pirate peut poster ce commentaire :

<script>alert('Votre compte a été piraté !');</script>

Si votre site n’empêche pas ce type d’injection, le navigateur va exécuter ce code et afficher une fausse alerte. Un attaquant plus expérimenté pourrait même voler des informations personnelles en injectant un script plus avancé.

Comment empêcher ces attaques ?

C’est là qu’intervient Content-Security-Policy (CSP) ! Ce header HTTP permet de contrôler quelles ressources (scripts, images, styles, etc.) peuvent être chargées par votre site. Il empêche ainsi l’exécution de scripts non autorisés.

En PHP, vous pouvez ajouter ce header en haut de vos pages :

header("Content-Security-Policy: default-src 'self'; script-src 'self';");

👆 Avec cette règle, votre site n’autorise que les scripts venant du même domaine ('self'), bloquant ainsi tout script injecté par un pirate.

Les principales règles CSP

Le header Content-Security-Policy fonctionne avec différentes règles que vous pouvez combiner :

1. default-src → Définit la source par défaut pour tout type de contenu.✅ Autorise uniquement les ressources venant du même site.

   header("Content-Security-Policy: default-src 'self';"); 

2. script-src → Contrôle l’origine des scripts JavaScript.✅ Autorise uniquement les scripts du site et de Google APIs.

   header("Content-Security-Policy: script-src 'self' https://apis.google.com;"); 

3. img-src → Définit d’où peuvent venir les images.✅ Autorise les images locales et les images en base64 (data:).

   header("Content-Security-Policy: img-src 'self' data:;");

4. style-src → Contrôle les feuilles de styles (CSS).⚠️ L’option 'unsafe-inline' permet le CSS inline, mais elle est risquée en matière de sécurité.

   header("Content-Security-Policy: style-src 'self' 'unsafe-inline';");

5. frame-ancestors → Empêche d’être chargé dans un <iframe> (protection contre le clickjacking).

   header("Content-Security-Policy: frame-ancestors 'none';");

Exemple complet de protection CSP

Voici un exemple plus avancé pour sécuriser un site :

header("Content-Security-Policy: 
    default-src 'self'; 
    script-src 'self' https://trusted-cdn.com; 
    img-src 'self' https://images.com data:; 
    style-src 'self' 'unsafe-inline'; 
    frame-ancestors 'none';");

📌 Ce que fait cette règle :
✅ Interdit les ressources externes non spécifiées.
✅ Autorise uniquement les scripts de votre site et de trusted-cdn.com.
✅ Permet les images de images.com et celles en base64.
✅ Bloque l’insertion de votre site dans un iframe.

Le Content-Security-Policy (CSP) est un outil puissant pour protéger votre site contre les attaques XSS et autres injections de contenu malveillant. En définissant des règles strictes, vous empêchez les pirates d’exécuter du code non autorisé sur votre site.

✅ Bonnes pratiques :

• Toujours commencer avec une politique restrictive ('self' uniquement).
• Tester son CSP avec l’outil de Mozilla : https://observatory.mozilla.org.
• Éviter 'unsafe-inline' et 'unsafe-eval' qui peuvent affaiblir la sécurité.

En appliquant ces règles, vous renforcez la protection de votre site et de vos utilisateurs contre les menaces XSS.

Header HTTP Strict-Transport-Security (HSTS) → Obliger l’utilisation du HTTPS

Un des moyens les plus simples et efficaces d’améliorer la sécurité d’un site est d’utiliser HTTPS plutôt que HTTP. Mais saviez-vous que même si vous avez un certificat SSL, votre site peut encore être vulnérable si les utilisateurs accèdent par erreur à la version non sécurisée (HTTP) ?

C’est là qu’intervient le header HTTP Strict-Transport-Security (HSTS). Il permet de forcer l’utilisation de HTTPS sur votre site et d’empêcher les visiteurs d’accéder à une version non sécurisée.

Pourquoi HTTPS est indispensable ?

HTTPS chiffre les données échangées entre le navigateur et le serveur, ce qui :
✅ Protège les informations des utilisateurs contre les pirates.
✅ Évite que les données soient modifiées en cours de route.
✅ Renforce la confiance des visiteurs (affichage du cadenas dans la barre d’adresse).

📌 Exemple concret :
Sans HTTPS, si un utilisateur se connecte à votre site depuis un Wi-Fi public (comme un café), un pirate peut intercepter ses données (mots de passe, informations bancaires, etc.). Avec HTTPS, ces informations sont cryptées et donc inexploitables par un attaquant.

Mais un problème subsiste : si un utilisateur tape directement http://monsite.com dans son navigateur, il peut accéder temporairement à la version non sécurisée avant d’être redirigé. C’est ce moment de faiblesse que HSTS corrige.

Qu’est-ce que HSTS et comment ça fonctionne ?

Le header HTTP Strict-Transport-Security (HSTS) indique au navigateur que votre site doit toujours être chargé en HTTPS et qu’il ne doit jamais utiliser HTTP.

Dès qu’un visiteur accède à votre site en HTTPS, son navigateur enregistre cette règle. La prochaine fois, il ne tentera même pas d’accéder à HTTP, il ira directement en HTTPS, et ce même si l’utilisateur tape http:// dans la barre d’adresse.

Comment activer HSTS en PHP ?

Ajoutez cette ligne dans votre fichier PHP principal (index.php par exemple) :

header("Strict-Transport-Security: max-age=31536000; includeSubDomains; preload");

Explication des paramètres :

• max-age=31536000 → Le navigateur forcera HTTPS pendant 1 an (31536000 secondes).
• includeSubDomains → Applique HSTS à tous les sous-domaines.
• preload → Permet d’inscrire le site dans la liste HSTS Preload de Google pour une sécurité encore plus forte.

Les avantages de HSTS

✅ Empêche l’accès en HTTP même si l’utilisateur le tape manuellement.
✅ Évite les attaques de type « man-in-the-middle » (interception des données).
✅ Améliore la rapidité de chargement en évitant une redirection inutile de HTTP vers HTTPS.
✅ Oblige tous les sous-domaines à utiliser HTTPS (si includeSubDomains est activé).

Un exemple d’attaque évitée grâce à HSTS

Sans HSTS, un pirate pourrait utiliser une attaque appelée SSL Stripping.
📌 Exemple :

1. Un visiteur tape http://monsite.com dans son navigateur.
2. Normalement, votre serveur redirige immédiatement vers https://monsite.com.
3. MAIS si un pirate intercepte la connexion à ce moment-là, il peut empêcher la redirection et afficher une fausse version de votre site en HTTP. L’utilisateur ne se rend compte de rien et entre ses identifiants, qui sont envoyés en clair au pirate.

Avec HSTS, ce type d’attaque est impossible, car le navigateur n’essaiera même pas de se connecter en HTTP.

Attention aux erreurs avec HSTS

Une fois activé, vous ne pourrez plus revenir en arrière facilement, car les navigateurs se souviendront de la règle. Avant d’activer HSTS, assurez-vous que votre site fonctionne parfaitement en HTTPS.

✅ Vérifications à faire avant d’activer HSTS :

• Vérifiez que toutes vos pages et ressources (images, scripts, CSS) sont bien chargées en HTTPS.
• Testez votre site sur https://hstspreload.org/ avant d’ajouter preload.

Le header Strict-Transport-Security (HSTS) est un élément clé pour sécuriser votre site et forcer l’utilisation de HTTPS. Il protège vos visiteurs des attaques par interception et assure qu’ils naviguent toujours sur une connexion sécurisée.

💡 En résumé :

• Activez HSTS avec max-age=31536000; includeSubDomains; preload.
• Vérifiez que votre site est 100% compatible HTTPS avant activation.
• Ajoutez votre site à la liste HSTS Preload pour une sécurité maximale.

En appliquant cette simple règle, vous renforcez la sécurité de votre site et améliorez l’expérience utilisateur.

Header HTTP X-Content-Type-Options → Empêcher certains exploits MIME

La sécurité des sites web est un sujet crucial, et parfois, des attaques peuvent venir de là où on ne s’y attend pas. L’un des problèmes connus est la mauvaise détection du type de fichier par les navigateurs, ce qui peut permettre à un attaquant d’exécuter du code malveillant sur votre site.

Pour éviter cela, on peut utiliser un header HTTP simple mais efficace : X-Content-Type-Options. Voyons ensemble ce qu’il fait, pourquoi il est important et comment l’utiliser.

Le problème : la détection automatique des types de fichiers

Lorsqu’un navigateur télécharge un fichier (comme une image, une vidéo ou un script), il regarde son type MIME pour savoir comment l’interpréter.

📌 Exemple :

• Un fichier image peut avoir le type MIME image/png.
• Une page web aura le type MIME text/html.
• Un fichier JavaScript sera application/javascript.

Normalement, le serveur indique le bon type MIME, et le navigateur se fie à cette information.

🚨 Mais attention ! Certains navigateurs, notamment les anciennes versions d’Internet Explorer, ne faisaient pas toujours confiance au type MIME envoyé par le serveur. À la place, ils tentaient de deviner le contenu du fichier.

Ce comportement, appelé MIME sniffing, peut être exploité par des pirates pour tromper le navigateur et exécuter du code malveillant.

L’attaque possible : détourner un fichier innocent

Imaginons que vous hébergez sur votre site un fichier .txt envoyé par un utilisateur. Ce fichier contient du texte simple, mais un pirate pourrait y cacher du code HTML et JavaScript malveillant.

Si le navigateur fait du MIME sniffing, il pourrait croire que ce fichier est une page HTML au lieu d’un simple texte et exécuter le code JavaScript à l’intérieur. Cela pourrait permettre à un attaquant de voler des informations, afficher de fausses pages ou détourner des sessions utilisateur.

Là où ça devient dangereux :

• Un utilisateur télécharge un fichier censé être inoffensif (fichier.txt).
• Le navigateur l’analyse et pense qu’il s’agit d’une page web contenant du JavaScript.
• Il exécute alors le code malveillant.

La solution : le header X-Content-Type-Options

Le header X-Content-Type-Options permet de désactiver le MIME sniffing et oblige le navigateur à respecter strictement le type MIME envoyé par le serveur.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

La seule valeur reconnue pour ce header est nosniff :

header("X-Content-Type-Options: nosniff");

Avec cette directive :
✅ Le navigateur ne tente plus de deviner le type du fichier.
✅ Il respecte uniquement le type MIME indiqué par le serveur.
✅ Il empêche donc l’exécution accidentelle de scripts déguisés en autres types de fichiers.

Exemple concret d’utilisation

Disons que vous hébergez des images sur votre site et que vous voulez éviter qu’un fichier malveillant déguisé en image puisse être interprété comme du code.

Dans la configuration Apache, vous pouvez ajouter cette ligne à votre fichier .htaccess :

Header set X-Content-Type-Options "nosniff"

Si vous utilisez Nginx, ajoutez ceci dans la configuration du serveur :

add_header X-Content-Type-Options "nosniff";

Pourquoi c’est important ?

🔒 Amélioration de la sécurité : empêche l’exécution de fichiers déguisés en scripts.
🚀 Performance : évite des erreurs de détection inutiles.
🌍 Bonne pratique recommandée : Google, Mozilla et d’autres grandes entreprises utilisent ce header pour protéger leurs sites.

Le header X-Content-Type-Options: nosniff est une solution simple mais essentielle pour empêcher les navigateurs de mal interpréter les fichiers. Il permet de bloquer certaines attaques basées sur le MIME sniffing et garantit que les fichiers sont traités comme ils devraient l’être.

💡 À retenir :

• Sans ce header, un navigateur peut mal identifier un fichier et exécuter du code dangereux.
• Avec ce header, il suit strictement le type MIME défini par le serveur.
• Il suffit d’une ligne pour renforcer la sécurité de votre site.

Un petit changement qui peut éviter de gros problèmes !

Header HTTP Referrer-Policy → Limiter les fuites d’informations

Lorsque vous naviguez sur Internet et que vous cliquez sur un lien, votre navigateur envoie des informations au site sur lequel vous arrivez. L’une de ces informations est le referer (ou référent en français). Il indique au site destination d’où vient le visiteur, c’est-à-dire quelle page il consultait avant de cliquer sur le lien.

Cela peut poser un problème de confidentialité et de sécurité, car certaines pages contiennent des informations sensibles dans leur URL. Heureusement, il existe une solution pour mieux contrôler ce comportement : le header HTTP Referrer-Policy.

Qu’est-ce que le referer et pourquoi peut-il être un problème ?

Le referer est une information envoyée automatiquement par le navigateur lorsqu’un utilisateur clique sur un lien.

📌 Exemple de fonctionnement sans protection :

1. Un utilisateur visite votre site https://mon-site.com/page-secrete?user=Jean.
2. Il clique sur un lien qui mène à https://autre-site.com.
3. Le site autre-site.com reçoit l’URL complète de la page d’origine (https://mon-site.com/page-secrete?user=Jean).

🚨 Problème : Si l’URL contient des informations sensibles (comme un identifiant, un jeton de session ou des données privées), elles seront transmises au site cible. Un site malveillant pourrait alors les exploiter.

La solution : le header Referrer-Policy

Le header HTTP Referrer-Policy permet de contrôler ce que le navigateur envoie comme information de référent lorsqu’un utilisateur clique sur un lien.

On peut définir plusieurs niveaux de protection en utilisant différentes valeurs :

1. no-referrer → Ne jamais envoyer le referer, aucune information sur la page d’origine ne sera transmise.
2. no-referrer-when-downgrade (valeur par défaut) → N’envoie pas de referer si l’on passe d’un site HTTPS vers un site HTTP.
3. same-origin → Envoie le referer uniquement si la destination est sur le même site.
4. strict-origin → Envoie uniquement l’origine (https://mon-site.com) mais pas le chemin détaillé (/page-secrete?user=Jean).
5. strict-origin-when-cross-origin (option recommandée) → Envoie l’URL complète sur le même site, mais uniquement l’origine (https://mon-site.com) vers des sites externes.
6. unsafe-url → Envoie toujours le referer complet, même aux sites externes (⚠ déconseillé pour la sécurité).

Comment configurer Referrer-Policy ?

En PHP

Vous pouvez ajouter ce header dans vos fichiers PHP pour l’appliquer à toutes les pages :

header("Referrer-Policy: strict-origin-when-cross-origin");

Dans Apache (fichier .htaccess)

Ajoutez cette ligne pour appliquer la politique à tout le site :

Header set Referrer-Policy "strict-origin-when-cross-origin"

Dans Nginx

Ajoutez cette directive dans la configuration du serveur :

add_header Referrer-Policy "strict-origin-when-cross-origin";

Exemple d’application concrète

Imaginons que vous gériez un site e-commerce https://ma-boutique.com.

1. Un client visite https://ma-boutique.com/commande?user=12345 (avec son identifiant dans l’URL).
2. Il clique sur un lien menant à https://partenaire.com.
3. Sans Referrer-Policy, partenaire.com reçoit l’URL complète (https://ma-boutique.com/commande?user=12345), exposant un identifiant utilisateur.
4. Avec Referrer-Policy: strict-origin-when-cross-origin, partenaire.com ne recevra que https://ma-boutique.com, protégeant ainsi les informations du client.

Pourquoi utiliser ce header ?

✅ Améliore la confidentialité : limite la fuite d’informations sensibles vers d’autres sites.
✅ Renforce la sécurité : empêche des attaquants d’exploiter des URL contenant des données privées.
✅ Optimise le référencement : évite d’exposer des pages internes aux moteurs de recherche via le referer.

Le header Referrer-Policy est une solution simple et efficace pour protéger la vie privée des utilisateurs et éviter de partager involontairement des informations sensibles.

💡 À retenir :

• Par défaut, le navigateur envoie le referer, même aux sites externes.
• Ce header permet de contrôler quelles informations sont partagées.
• strict-origin-when-cross-origin est recommandé pour un bon équilibre entre sécurité et fonctionnalité.

Un réglage simple qui protège à la fois vos utilisateurs et votre site ! 

Protéger les cookies en PHP avec les headers HTTP

Les cookies sont souvent utilisés pour garder des informations sur un utilisateur, comme une session de connexion ou ses préférences sur un site. Mais si ces cookies ne sont pas bien protégés, un pirate peut les voler et les utiliser pour se faire passer pour l’utilisateur.

Heureusement, en PHP, on peut renforcer la sécurité des cookies en utilisant les bonnes options et des headers HTTP adaptés. Voyons comment bien les configurer.

Pourquoi protéger les cookies ?

Quand un site utilise des cookies, ils sont envoyés avec chaque requête HTTP du navigateur au serveur. Si un attaquant réussit à intercepter ou à manipuler ces cookies, il peut en profiter pour voler une session, injecter du code malveillant ou usurper une identité.

Les principaux risques sont :
🔹 Le vol de cookies (attaque XSS) : Un pirate injecte un script sur un site pour récupérer des cookies via JavaScript.
🔹 L’interception des cookies (attaque Man-in-the-Middle) : Si le site utilise HTTP au lieu de HTTPS, un pirate sur un réseau Wi-Fi public peut intercepter les cookies.
🔹 L’utilisation frauduleuse des cookies (attaque CSRF) : Un site malveillant force un utilisateur à exécuter une action en exploitant ses cookies de session.

L’utilisation des headers HTTP permet de :
✅ Forcer le navigateur à appliquer certaines restrictions sur les cookies.
✅ Éviter la modification des cookies par des scripts malveillants.
✅ Ajouter un niveau de sécurité supplémentaire en complément des options de PHP.

Avec le bon header HTTP, on peut empêcher les vols de cookies via JavaScript (XSS), les attaques CSRF et l’interception sur un réseau non sécurisé.

Les bonnes pratiques pour sécuriser les cookies en PHP

En plus de bien configurer les cookies avec setcookie(), on peut renforcer leur sécurité en utilisant un header HTTP pour forcer certaines règles côté navigateur.

L’un des headers les plus utiles pour protéger les cookies est Set-Cookie, qui permet de définir des options avancées pour la gestion des cookies. Voyons comment l’utiliser en PHP.

Utilisation du header Set-Cookie en PHP

On peut envoyer un cookie sécurisé directement via un header HTTP avec PHP.

📌 Exemple : Protéger un cookie avec un header HTTP

header("Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Strict");

🔹 Explication des options :

• Secure → Le cookie ne sera envoyé que via HTTPS (protection contre l’interception).
• HttpOnly → Le cookie n’est pas accessible en JavaScript (protection contre le vol par XSS).
• SameSite=Strict → Le cookie n’est envoyé que pour les requêtes venant du même site (protection contre CSRF).

Avec ce header, aucun script JavaScript ne peut voler le cookie et il ne sera jamais transmis en HTTP.

Exemple complet : Définir un cookie sécurisé avec un header HTTP en PHP

<?php
// Envoyer un cookie sécurisé via un header HTTP
header("Set-Cookie: user_token=secureToken123; Path=/; Secure; HttpOnly; SameSite=Strict");

// Vérification du cookie (pour s'assurer qu'il est bien défini)
if (isset($_COOKIE['user_token'])) {
    echo "Le cookie sécurisé est actif.";
} else {
    echo "Le cookie n'est pas défini.";
}
?>

✅ Avec ce code, le cookie user_token est sécurisé et inaccessible aux scripts JavaScript.

Apprenez également comment sécuriser une session PHP.

Tests & Vérifications des Headers HTTP en PHP

Lorsqu’on met en place des headers HTTP pour sécuriser un site en PHP, il est important de vérifier qu’ils sont bien actifs et qu’ils fonctionnent comme prévu. Pour cela, on peut utiliser des outils gratuits comme Mozilla Observatory ou SecurityHeaders.com. Ces outils analysent les réponses HTTP de votre site et donnent une note de sécurité.

Voyons comment les utiliser et comment vérifier les headers directement avec PHP.

Pourquoi tester ses headers HTTP ?

L’ajout de headers HTTP est une excellente pratique pour protéger un site web contre des attaques comme le vol de cookies, le clickjacking ou les injections de scripts malveillants (XSS).

Mais mettre en place ces headers ne suffit pas. Il faut :
✅ Vérifier qu’ils sont bien envoyés par le serveur.
✅ S’assurer qu’ils sont bien configurés.
✅ Corriger les éventuelles erreurs ou faiblesses.

Vérifier ses headers HTTP avec Mozilla Observatory

Mozilla Observatory est un service gratuit en ligne qui analyse la sécurité de votre site.

📌 Comment tester votre site ?
1️⃣ Rendez-vous sur https://observatory.mozilla.org.
2️⃣ Entrez l’URL de votre site (ex: https://mon-site.com).
3️⃣ Cliquez sur « Scan Me ».

Mozilla Observatory va tester plusieurs points de sécurité, dont les headers HTTP. Vous recevrez une note allant de F (très mauvais) à A+ (excellente protection).

✅ Si certains headers manquent ou sont mal configurés, Mozilla Observatory vous indiquera comment les améliorer.

Vérifier ses headers avec SecurityHeaders.com

Un autre outil très utile est SecurityHeaders.com, qui fonctionne de la même manière que Mozilla Observatory.

📌 Comment l’utiliser ?
1️⃣ Allez sur https://securityheaders.com.
2️⃣ Saisissez votre URL.
3️⃣ Cliquez sur « Scan ».

L’outil affichera une liste des headers présents avec une analyse détaillée. Il vous indiquera si certains headers sont manquants ou mal configurés.

Vérifier les headers HTTP directement avec PHP

En plus des outils en ligne, vous pouvez vérifier les headers HTTP directement avec PHP.

📌 Exemple : Afficher les headers HTTP envoyés par votre serveur

<?php
// Afficher tous les headers HTTP envoyés par le serveur
$headers = get_headers("https://mon-site.com", 1);

// Afficher les headers
echo "<pre>";
print_r($headers);
echo "</pre>";
?>

✅ Ce code vous permet de voir tous les headers que votre serveur envoie. Vous pouvez vérifier si vos headers de sécurité sont bien présents.

Vérifier les headers dans le navigateur (Chrome & Firefox)

Vous pouvez aussi analyser les headers HTTP directement dans votre navigateur.

📌 Sous Chrome ou Firefox :
1️⃣ Ouvrez votre site (https://mon-site.com).
2️⃣ Faites clic droit → Inspecter → Onglet « Réseau ».
3️⃣ Rechargez la page et cliquez sur la première requête.
4️⃣ Allez dans l’onglet « Headers » pour voir tous les headers envoyés par le serveur.

Vous pourrez y voir vos headers comme Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, etc.

Conclusion

Les header HTTP sont un élément essentiel pour améliorer la sécurité de votre site en PHP. Ils permettent de protéger contre de nombreuses attaques comme le clickjacking, les injections de scripts malveillants (XSS), le vol de données via les cookies, ou encore les fuites d’informations.

Grâce à des headers comme X-Frame-Options, Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), X-Content-Type-Options, Referrer-Policy, et les protections des cookies, vous pouvez considérablement réduire les risques pour votre site et ses utilisateurs.

Cependant, mettre en place ces headers ne suffit pas. Il est important de tester leur bon fonctionnement à l’aide d’outils comme Mozilla Observatory et SecurityHeaders.com, ou encore de vérifier manuellement les réponses HTTP avec PHP et les outils de développement des navigateurs.

Enfin, la sécurité web ne se limite pas aux headers HTTP : ils doivent être intégrés dans une approche globale de protection incluant l’utilisation de HTTPS, des mises à jour régulières et une bonne gestion des accès.

En appliquant ces bonnes pratiques, vous renforcez non seulement la sécurité de votre site, mais aussi la confiance de vos utilisateurs.

Alban

Fondateur de l’agence Créa-troyes.
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr