Entêtes HTTP de sécurité : un bouclier oublié du web

Quand on parle de sécurité informatique, on pense tout de suite aux mots de passe compliqués, aux antivirus ou aux pare-feux. Mais il existe un autre outil, discret et pourtant puissant : les entêtes HTTP de sécurité.

Ces petits réglages, souvent négligés, constituent une défense simple et efficace contre des attaques courantes comme :

• l’injection de scripts (XSS),
• le clickjacking (vol de clics via une fausse interface),
• ou encore la fuite d’informations sensibles.

La bonne nouvelle ? Leur mise en place est généralement rapide et gratuite.

Qu’est-ce qu’un entête HTTP ?

Chaque fois que votre navigateur charge un site, il échange des messages invisibles avec le serveur.
Ces messages, appelés entêtes HTTP, contiennent des instructions :

• quel type de contenu charger (texte, image, vidéo),
• comment gérer le cache,
• quelles autorisations appliquer.

Certains entêtes sont dédiés à la sécurité. Ce sont eux qui peuvent empêcher un pirate d’exploiter une faille.

Exemple :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff

Il existe des centaines d’entêtes, mais quelques-uns sont spécifiquement conçus pour la sécurité.

Les principaux entêtes de sécurité

Voici une sélection des plus utiles :

• Content-Security-Policy (CSP) : empêche l’exécution de scripts malveillants.
• X-Frame-Options : bloque l’affichage de votre site dans une iframe, et donc le clickjacking.
• Strict-Transport-Security (HSTS) : force le passage en HTTPS pour toutes les connexions.
• X-Content-Type-Options : empêche l’interprétation frauduleuse de fichiers.
• Referrer-Policy : limite les informations partagées quand un utilisateur clique sur un lien.
• Permissions-Policy : restreint l’accès aux fonctionnalités sensibles (caméra, micro, géolocalisation).

Exemple concret : sans et avec protection

• Sans CSP : un pirate injecte un script dans un formulaire → il est exécuté.
• Avec CSP : seul le code provenant de vos serveurs est autorisé → le script est bloqué.
• Sans X-Frame-Options : votre site peut être affiché dans une page pirate qui trompe l’utilisateur.
• Avec X-Frame-Options : impossible de charger le site ailleurs → attaque déjouée.

Comment les mettre en place ?

Bonne nouvelle : pas besoin d’être un expert sécurité pour commencer.

• Sous Apache (.htaccess) : quelques lignes à ajouter.
• Sous Nginx : même principe avec add_header.
• Sous WordPress : un simple bout de code ou un plugin spécialisé.
• Sous Node.js : utilisation du middleware helmet.

En clair : 3 à 5 minutes de configuration suffisent pour renforcer fortement la sécurité de votre site.

Sous Apache par le fichier .htaccess

Header always set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), microphone=()"

Sous NGinx

add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Permissions-Policy "geolocation=(), microphone=()";

Sous Node.JS / Express

const helmet = require("helmet");
app.use(helmet());

WordPress function

function ajouter_headers_securite() {
  header("X-Frame-Options: SAMEORIGIN");
  header("X-Content-Type-Options: nosniff");
  header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
  header("Referrer-Policy: strict-origin-when-cross-origin");
  header("Permissions-Policy: geolocation=(), microphone=()");
}
add_action('send_headers', 'ajouter_headers_securite');

HTTPS et CORS : à ne pas confondre

Deux notions proches mais différentes :

• HTTPS : chiffre les échanges entre le navigateur et le serveur. Objectif : empêcher qu’un mot de passe ou un cookie soit intercepté.
• CORS : contrôle qui peut accéder à vos ressources (API, données). Objectif : éviter qu’un site tiers exploite vos services sans autorisation.

Ces deux protections sont complémentaires.

Pourquoi si peu de sites les utilisent ?

Trois raisons principales :

• Ignorance : les headers ne sont pas enseignés en priorité.
• Crainte : une mauvaise configuration peut bloquer un script utile.
• Invisibilité : quand ils manquent, rien ne s’affiche… sauf pour les pirates.

Comment vérifier si votre site est protégé ?

Quelques outils simples permettent de savoir si vos entêtes sont bien configurés :

• SecurityHeaders.com (Scott Helme)
• Mozilla Observatory
• Chrome DevTools → onglet “Headers”

En un clic, vous obtenez un score de A à F.

La checklist de base

Pour débuter, mettez en place ces entêtes minimum :

• X-Frame-Options: SAMEORIGIN
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Strict-Transport-Security: max-age=31536000; includeSubDomains

Ensuite, ajoutez progressivement :

• Permissions-Policy pour limiter l’usage des fonctionnalités sensibles.
• CSP pour contrôler l’exécution des scripts,

Conclusion

Les entêtes HTTP ne remplacent pas un mot de passe solide ou un pare-feu, mais ils sont une ligne de défense essentielle.
Ignorés par la majorité des sites, ils représentent pourtant une sécurité simple, gratuite et efficace.

En clair : si vous gérez un site web, prenez 30 minutes pour les activer. Vous gagnerez en sécurité et en crédibilité.

Ressources complémentaires

La sécurité avec les headers HTTP : Tour d’horizon des attaques et défenses … (Mathieu Humbert)

La sécurité avec les headers HTTP Devoox France