Checklist des en-têtes de sécurité : quoi configurer et pourquoi

Les en-têtes de sécurité indiquent aux navigateurs comment gérer le contenu, les connexions, l'encadrement, les requêtes inter-origines et les capacités du navigateur. Ils ne peuvent pas corriger un bug d'autorisation ni assainir du HTML non sûr, mais ils peuvent réduire l'impact des scripts intersites, du clickjacking, de la confusion MIME, des fuites de données et du transport non sécurisé accidentel.

Utilisez cette checklist comme référence, et non comme une politique à copier-coller. La bonne valeur dépend de la nature de ce que vous servez : site public, application authentifiée, API, téléchargements, contenu intégré ou scripts tiers. Appliquez les en-têtes de façon cohérente à la frontière finale de la réponse, y compris aux réponses d'erreur et aux redirections lorsque la sémantique de l'en-tête l'exige.

En-têtes fondamentaux

Content-Security-Policy

Objectif : limiter les scripts, styles, images, cadres, connexions et autres ressources qu'un navigateur peut charger. La CSP est une défense en profondeur contre les XSS et l'injection de données ; elle ne remplace pas l'encodage de sortie, la validation des entrées ni les API DOM sûres.

Configuration : commencez par une politique qui reflète les ressources réellement nécessaires à l'application. Préférez des contrôles de scripts fondés sur des nonces ou des hachages lorsque l'application peut les générer. Incluez des directives telles que object-src 'none', base-uri 'none' et une politique frame-ancestors appropriée. Évitez d'ajouter unsafe-inline ou unsafe-eval simplement pour faire passer une politique défaillante.

Déploiement : utilisez d'abord Content-Security-Policy-Report-Only, examinez les violations, supprimez les sources inattendues, puis appliquez la politique. Testez la connexion, les paiements, l'analytique, les widgets de support, les téléversements et les pages d'erreur. Une politique trop large offre peu de protection ; une politique trop restrictive peut briser un parcours client critique.

Strict-Transport-Security

Objectif : indiquer aux navigateurs d'utiliser HTTPS pour les futures requêtes et de ne pas contourner les erreurs de certificat.

Configuration : envoyez HSTS uniquement sur HTTPS. Commencez avec un max-age court pendant que vous confirmez que chaque hôte concerné prend en charge HTTPS. Ajoutez includeSubDomains uniquement lorsque tous les sous-domaines couverts sont prêts, y compris les noms oubliés, internes et gérés par des tiers. Considérez preload comme un engagement délibéré, difficile à annuler, et non comme un suffixe par défaut.

Content-Type et X-Content-Type-Options

Objectif : garantir que les navigateurs interprètent une réponse comme le type déclaré par le serveur et ne la détectent pas par reniflage MIME comme contenu exécutable.

Configuration : définissez le bon Content-Type pour chaque réponse et envoyez X-Content-Type-Options: nosniff. Portez une attention particulière aux fichiers téléversés par les utilisateurs, aux téléchargements, au JSON, au JavaScript et aux pages d'erreur. Cet en-tête ne rend pas sûr un fichier dangereux ; isolez les téléversements non fiables et utilisez une disposition de contenu orientée téléchargement lorsque c'est pertinent.

Protection contre le clickjacking

Objectif : empêcher un attaquant d'intégrer une page interactive et d'inciter un utilisateur à cliquer sur des contrôles cachés.

Configuration : utilisez CSP frame-ancestors pour définir si une page peut être encadrée. Si l'encadrement n'est pas nécessaire, frame-ancestors 'none' est une valeur par défaut forte. X-Frame-Options: DENY ou SAMEORIGIN reste utile pour la compatibilité, mais est moins expressif et ne remplace pas une politique CSP soigneusement testée. Les API qui renvoient du JSON nécessitent généralement d'autres contrôles plutôt qu'une protection contre l'encadrement.

Contrôles de confidentialité et inter-origines

Referrer-Policy

Objectif : contrôler la quantité d'informations d'URL envoyée dans l'en-tête Referer à une autre ressource.

Configuration : strict-origin-when-cross-origin constitue une base générale raisonnable. Utilisez une politique plus stricte pour les applications sensibles ou les pages dont les URL peuvent contenir des identifiants. Ne placez jamais de secrets dans les URL et ne comptez pas sur cet en-tête pour corriger une conception d'URL non sûre.

Permissions-Policy

Objectif : limiter les fonctionnalités du navigateur telles que la caméra, le microphone, la géolocalisation, le paiement et le plein écran.

Configuration : désactivez les fonctionnalités dont le site n'a pas besoin et accordez les fonctionnalités requises uniquement aux origines qui en ont besoin. Testez les cadres intégrés et les flux de consentement. La prise en charge des navigateurs et les noms des directives changent ; consultez donc la documentation actuelle des navigateurs au lieu de supposer que chaque jeton produit partout le même effet.

CORS

Objectif : assouplir la politique de même origine du navigateur pour des origines web explicitement approuvées.

Configuration : traitez Access-Control-Allow-Origin comme une décision d'accès, et non comme un en-tête de sécurité générique. Utilisez une liste d'autorisation explicite pour les requêtes avec identifiants, validez l'Origin entrant, configurez précisément les méthodes et en-têtes, et ne combinez jamais des origines génériques avec des identifiants. CORS ne protège pas les clients hors navigateur et ne remplace ni l'authentification ni l'autorisation d'API. Consultez la protection des API pour les contrôles côté serveur qui doivent l'accompagner.

Isolation inter-origines

Objectif : COOP, COEP et CORP peuvent séparer les contextes de navigation et restreindre la façon dont les ressources sont intégrées ou chargées.

Configuration : utilisez-les lorsque l'application a un besoin d'isolation clair, comme l'accès à de puissantes capacités du navigateur ou la protection contre les canaux auxiliaires inter-origines. Ils peuvent casser les ressources tierces, les workers, les iframes et les intégrations. Déployez-les d'abord sur une route ou une origine testée et confirmez que chaque dépendance envoie des en-têtes compatibles.

En-têtes pour les sessions et les données

L'en-tête Set-Cookie ne figure généralement pas parmi les en-têtes de sécurité de réponse, mais ses attributs sont essentiels. Définissez Secure pour les cookies HTTPS uniquement, HttpOnly pour les cookies dont JavaScript n'a pas besoin et une valeur SameSite appropriée. Limitez Domain et Path. Examinez ensemble l'expiration des sessions, la rotation, la protection CSRF et le comportement de déconnexion ; les attributs des cookies seuls ne sécurisent pas une session.

Utilisez Cache-Control: no-store pour les réponses contenant des secrets ou des données sensibles propres à un utilisateur. private peut empêcher le stockage dans un cache partagé tout en autorisant le cache du navigateur, mais n'est pas équivalent à no-store. Rendez explicite le comportement du cache pour les API, les pages authentifiées, les redirections et les réponses d'erreur.

Supprimez les divulgations technologiques inutiles telles que X-Powered-By et les valeurs Server trop détaillées. Il s'agit d'une mesure de durcissement mineure, et non d'un substitut aux correctifs ou au contrôle d'accès. N'ajoutez pas d'en-têtes obsolètes comme X-XSS-Protection en guise de défense XSS moderne ; utilisez plutôt CSP et des pratiques de développement sûres.

Tester et surveiller la politique

Vérifiez des réponses représentatives avec curl -I et le panneau d'outils de développement d'un navigateur. Testez les réponses de succès et d'échec, les chemins mis en cache et non mis en cache, les redirections, les requêtes de prévol d'API, les téléchargements de fichiers, les pages authentifiées et les pages d'erreur personnalisées. Utilisez des tests automatisés d'en-têtes et un endpoint de rapport CSP lorsque c'est pertinent. Traitez les rapports comme des entrées non fiables et limitez le débit de l'endpoint de reporting.

Déployez par étapes :

1. Enregistrez les en-têtes actuels et les dépendances de l'application.
2. Ajoutez des en-têtes à faible risque tels que nosniff et une politique de référent validée.
3. Testez la préparation à HSTS avant d'en augmenter la durée ou la portée.
4. Déployez CSP en mode rapport uniquement, corrigez les violations, puis appliquez-la sur un canari.
5. Ajoutez Permissions-Policy et l'isolation inter-origines uniquement après avoir testé les fonctionnalités nécessaires.
6. Surveillez les erreurs de navigateur, les ressources bloquées, la finalisation de l'authentification, les tickets de support et les rapports de sécurité.

Erreurs fréquentes

• Copier une CSP stricte sans inventorier les scripts, cadres, polices et connexions.
• Activer HSTS includeSubDomains avant que chaque sous-domaine ne dispose d'un HTTPS valide.
• Considérer un score de sécurité élevé comme la preuve que l'autorisation et le traitement des entrées sont sûrs.
• Utiliser CORS générique avec des cookies ou refléter des origines arbitraires.
• Définir des en-têtes uniquement sur les réponses 200 et oublier les redirections, erreurs ou réponses d'API.
• Mettre en cache du contenu privé parce que no-cache a été confondu avec no-store.
• Supposer que X-Frame-Options protège une API ou remplace frame-ancestors.

Complétez cette checklist avec la protection WAF, la gestion des bots et la limitation de débit expliquée. Pour un examen plus large de l'architecture, lisez comment masquer et protéger votre serveur d'origine et contactez Optimi.

Références faisant autorité

• OWASP HTTP Headers Cheat Sheet
• Guide MDN sur la Content Security Policy
• Référence MDN Strict-Transport-Security
• RFC 6797: HTTP Strict Transport Security

Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le nommage des choses.