En-têtes de sécurité essentiels pour votre site

Security2026-09-19TryQuickToolBox

Vous avez sécurisé votre serveur, corrigé les failles de votre framework et formé votre équipe aux bonnes pratiques de codage sécurisé. Pourtant, votre site reste vulnérable s'il n'envoie pas les bons en-têtes HTTP de sécurité. Ces en-têtes de réponse indiquent aux navigateurs comment se comporter face à votre contenu, et des en-têtes manquants ou mal configurés laissent la porte ouverte aux attaques de cross-site scripting (XSS), au clickjacking, aux attaques de rétrogradation de protocole et aux fuites de données.

Dans ce guide, nous allons passer en revue les en-têtes de sécurité essentiels que tout site web devrait envoyer, expliquer le rôle de chacun et vous montrer comment les configurer correctement.

Pourquoi les en-têtes de sécurité sont importants

Les en-têtes de sécurité constituent une première ligne de défense car ils appliquent des politiques au niveau du navigateur que vous contrôlez. Ils ne remplacent pas la validation des entrées ni une authentification sécurisée, mais ils réduisent considérablement la surface d'attaque. Par exemple, une Content-Security-Policy stricte peut empêcher l'exécution d'un script injecté, même si un attaquant découvre une faille XSS.

Les principaux navigateurs prennent en charge ces en-têtes de manière cohérente, et leur ajout ne nécessite généralement que quelques lignes de configuration. Il y a peu de raisons de s'en passer.

Les en-têtes de sécurité essentiels

Voici les en-têtes que tout site web en production devrait envoyer. Nous couvrirons leur rôle, les valeurs recommandées et les pièges courants.

1. Content-Security-Policy (CSP)

La CSP est l'en-tête le plus puissant pour atténuer le XSS et l'injection de données. Elle restreint les sources à partir desquelles le navigateur peut charger des scripts, des styles, des images et d'autres ressources. Une bonne politique de départ pourrait ressembler à ceci :

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';

Commencez par default-src 'self' et ajoutez progressivement des exceptions selon vos besoins. Évitez 'unsafe-inline' pour les scripts si possible ; utilisez plutôt des nonces ou des hachages. Testez minutieusement car une CSP mal configurée peut casser votre site.

2. HTTP Strict Transport Security (HSTS)

HSTS force les navigateurs à utiliser HTTPS pour toutes les futures requêtes vers votre domaine. Il prévient les attaques de rétrogradation de protocole et le détournement de cookies. Un en-tête typique :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Le max-age est en secondes (un an). includeSubDomains applique la politique à tous les sous-domaines. preload permet d'ajouter votre domaine aux listes de préchargement des navigateurs, mais ne l'utilisez que si vous êtes absolument certain que tous les sous-domaines prennent en charge HTTPS.

3. X-Frame-Options

Cet en-tête empêche votre site d'être intégré dans une iframe, ce qui bloque les attaques de clickjacking. Utilisez :

X-Frame-Options: DENY

Ou SAMEORIGIN si vous devez encadrer votre propre contenu. Les navigateurs modernes prennent également en charge la directive frame-ancestors dans la CSP, qui est plus flexible. Si vous utilisez la CSP, vous pouvez omettre X-Frame-Options, mais inclure les deux offre une meilleure compatibilité.

4. X-Content-Type-Options

Cet en-tête empêche les navigateurs de deviner le type MIME d'une réponse en dehors du Content-Type déclaré. C'est simple et efficace :

X-Content-Type-Options: nosniff

Sans lui, un fichier malveillant pourrait être interprété comme un script exécutable. Configurez-le toujours.

5. Referrer-Policy

Referrer-Policy contrôle la quantité d'informations de référent envoyées avec les requêtes. Une valeur par défaut équilibrée :

Referrer-Policy: strict-origin-when-cross-origin

Cela envoie l'URL complète pour les requêtes de même origine et uniquement l'origine pour les requêtes cross-origin. Cela réduit la fuite d'informations sensibles sur le chemin tout en préservant les analytics.

6. Permissions-Policy

Anciennement Feature-Policy, cet en-tête vous permet d'activer ou de désactiver des fonctionnalités du navigateur comme la géolocalisation, la caméra et le microphone. Exemple :

Permissions-Policy: geolocation=(), camera=(), microphone=()

Désactiver les fonctionnalités inutilisées réduit l'impact de scripts tiers compromis.

Comparaison des en-têtes de sécurité

En-tête	Objectif	Valeur recommandée
Content-Security-Policy	Atténuer le XSS et l'injection de données	`default-src 'self'; script-src 'self' ...`
Strict-Transport-Security	Imposer HTTPS	`max-age=31536000; includeSubDomains`
X-Frame-Options	Prévenir le clickjacking	`DENY` ou `SAMEORIGIN`
X-Content-Type-Options	Empêcher le MIME sniffing	`nosniff`
Referrer-Policy	Contrôler la fuite de référent	`strict-origin-when-cross-origin`
Permissions-Policy	Restreindre les fonctionnalités du navigateur	`geolocation=(), camera=()`

Comment ajouter les en-têtes de sécurité

La méthode dépend de votre serveur web ou de votre framework. Voici les approches courantes.

Nginx

Ajoutez les en-têtes dans votre bloc server :

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

Le paramètre always garantit que les en-têtes sont envoyés même sur les réponses d'erreur.

Apache

Activez mod_headers et ajoutez :

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"

Node.js (Express)

Utilisez le middleware helmet, qui définit de nombreux en-têtes par défaut :

const helmet = require('helmet');
app.use(helmet());
// Personnalisez la CSP si nécessaire
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", "https://trusted.cdn.com"],
    styleSrc: ["'self'", "'unsafe-inline'"],
    imgSrc: ["'self'", "data:", "https://images.example.com"],
    objectSrc: ["'none'"],
    baseUri: ["'self'"],
    formAction: ["'self'"],
  }
}));

Helmet définit également d'autres en-têtes comme X-Content-Type-Options et Referrer-Policy par défaut.

Tester vos en-têtes

Après le déploiement, vérifiez vos en-têtes à l'aide des outils de développement du navigateur (onglet Réseau) ou de scanners en ligne comme SecurityHeaders.com. Vérifiez que :

Tous les en-têtes recommandés sont présents.
La CSP ne bloque pas les ressources légitimes (vérifiez les violations dans la console).
HSTS n'est activé que si HTTPS fonctionne parfaitement.
Les en-têtes sont également envoyés sur les pages d'erreur.

Révisez et mettez à jour régulièrement vos politiques à mesure que votre site évolue.

FAQ

Quel est l'en-tête de sécurité le plus important ?

La Content-Security-Policy est souvent considérée comme le plus important car elle atténue directement les attaques XSS et d'injection de données, qui figurent parmi les vulnérabilités web les plus courantes.

Les en-têtes de sécurité peuvent-ils remplacer d'autres mesures de sécurité ?

Non. Les en-têtes de sécurité sont une couche de défense en profondeur. Vous avez toujours besoin d'un codage sécurisé, de la validation des entrées, de l'authentification et d'autres bonnes pratiques.

L'ajout d'en-têtes de sécurité peut-il casser mon site web ?

S'ils sont mal configurés, en particulier la CSP, ils peuvent bloquer des ressources légitimes. Testez toujours dans un environnement de préproduction et surveillez la console du navigateur pour détecter les violations avant de déployer en production.

Prêt à sécuriser votre site ? Commencez par ajouter les en-têtes ci-dessus, puis testez avec les outils de développement de votre navigateur. Pour inspecter et formater rapidement les réponses JSON de votre scanner de sécurité, essayez notre JSON Formatter.