En-têtes de sécurité HTTP : CSP, HSTS, Permissions-Policy et configuration complète

Ils ne constituent pas un pare-feu et ne réparent pas une autorisation défaillante, des API vulnérables, une injection SQL, des identifiants divulgués ou des dépendances obsolètes. Les en-têtes de sécurité sont une couche de défense en profondeur : ils réduisent la surface d'attaque du navigateur et restreignent ce qui peut se produire après qu'une autre faiblesse a déjà été exploitée.

En 2026, il est utile de distinguer trois catégories :

1. Les en-têtes de base qui ont du sens pour la plupart des sites web.
2. Les en-têtes dépendants de l'architecture qui peuvent casser OAuth, les paiements, les CDN, les iframes ou la diffusion de PDF lorsqu'ils sont copiés sans analyse.
3. Les en-têtes obsolètes qui ne devraient pas être activés simplement pour améliorer le score d'un scanner dépassé.

TL;DR : commencez par une Content Security Policy soigneusement conçue, HSTS une fois que HTTPS est entièrement déployé, X-Content-Type-Options: nosniff, un Referrer-Policy explicite et un Permissions-Policy restreint. Utilisez CSP frame-ancestors comme contrôle anti-framing principal et ne conservez X-Frame-Options que comme couche de compatibilité. Ne déployez COOP, COEP et CORP qu'après avoir examiné les intégrations cross-origin. Supprimez ou désactivez X-XSS-Protection, Expect-CT, HPKP et l'ancien en-tête Report-To.

Les recommandations et la compatibilité ont été vérifiées pour la dernière fois le 23 juillet 2026.

Les principaux en-têtes en un coup d'œil

En-tête	Recommandation typique	Ce qu'il limite	À utiliser partout ?
Content-Security-Policy	politique spécifique à l'application, de préférence basée sur un nonce ou un hash	XSS, injection, origines de ressources non approuvées et framing	oui pour le HTML, après tests
Strict-Transport-Security	max-age=31536000; includeSubDomains ; n'ajoutez preload qu'après examen	rétrogradation vers HTTP et contournement des erreurs de certificat	oui lorsque tout le domaine est prêt pour HTTPS
X-Content-Type-Options	nosniff	le MIME sniffing et certaines confusions de type MIME	oui
Referrer-Policy	strict-origin-when-cross-origin ou plus strict	fuite du chemin et de la chaîne de requête de l'URL	oui
Permissions-Policy	désactiver les capacités inutilisées telles que camera=(), microphone=(), geolocation=()	l'utilisation de certaines API du navigateur par les documents et les frames	généralement, après avoir testé les fonctionnalités
CSP frame-ancestors	'none', 'self' ou origines explicites	le clickjacking et le framing indésirable	oui pour les documents HTML
X-Frame-Options	DENY ou SAMEORIGIN pour la compatibilité	le framing dans les implémentations plus anciennes	souvent, en complément de frame-ancestors
Cross-Origin-Opener-Policy	souvent same-origin, sauf si des relations de type popup sont nécessaires	certaines XS-Leaks et l'accès à window.opener	dépend de l'architecture
Cross-Origin-Embedder-Policy	require-corp ou credentialless, uniquement de manière délibérée	l'intégration de ressources cross-origin sans permission	non, pas automatiquement
Cross-Origin-Resource-Policy	same-origin, same-site ou cross-origin selon la ressource	lectures cross-origin no-CORS indésirables	dépend de la ressource
Cache-Control	no-store pour les réponses très sensibles ; private pour le contenu personnalisé	le stockage dans le navigateur et les caches intermédiaires	pour les réponses sensibles
Set-Cookie	Secure; HttpOnly; SameSite=Lax/Strict selon le cas	le vol et l'envoi cross-site inapproprié des cookies	pour les cookies de session
Reporting-Endpoints	point de terminaison pour les rapports CSP/COOP/COEP	observabilité des politiques	optionnel
X-XSS-Protection	omettre ou définir à 0	filtre XSS hérité	ne pas activer
Expect-CT	supprimer	mécanisme de Certificate Transparency obsolète	non
Public-Key-Pins	ne pas utiliser	épinglage de certificat historique	non

L'OWASP considère les en-têtes de réponse comme des contrôles de durcissement précieux, tout en soulignant que chaque valeur doit correspondre au type de réponse et à l'architecture de l'application.

Un point de départ minimal

Il s'agit d'un modèle de départ, et non d'une réponse universelle à copier-coller :

Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; font-src 'self'; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: DENY

Cette politique bloque les scripts et styles inline, les origines de ressources non répertoriées, le framing, les formulaires soumis à d'autres origines, l'accès à la caméra/au microphone/à la géolocalisation et la navigation HTTP une fois HSTS enregistré.

Si le site utilise des polices externes, de l'analytique, des cartes, des widgets de paiement, OAuth, des gestionnaires de balises, des API tierces ou du code inline, la politique doit être adaptée.

1. Content-Security-Policy : l'en-tête le plus puissant et le plus difficile

Content-Security-Policy définit d'où le navigateur peut charger les scripts, les styles, les images, les polices, les frames et les connexions réseau. Une CSP correcte peut réduire considérablement l'impact des XSS et de l'injection de données, mais elle ne remplace pas la validation des entrées, l'encodage des sorties et des API DOM sûres.

Directives principales

Directive	Objectif	Valeur de départ courante
default-src	valeur de repli pour les types de ressources sans directive dédiée	'self'
script-src	scripts autorisés	nonce ou hashes, éventuellement 'self'
style-src	styles autorisés	'self', nonce ou hashes
img-src	images	'self' data: https:
font-src	polices	'self' et origines CDN explicites
connect-src	Fetch, XHR, WebSocket et EventSource	votre API et points de terminaison explicites
frame-src	frames intégrées par la page	uniquement les origines nécessaires
frame-ancestors	quels parents peuvent intégrer cette page	'none' ou 'self'
form-action	destinations de formulaire valides	'self' ou points de terminaison explicites
base-uri	URL <base> autorisées	'self' ou 'none'
object-src	plugins <object> et <embed>	'none'
upgrade-insecure-requests	réécrire les sous-ressources HTTP en HTTPS	aucune valeur

Listes d'autorisation ou CSP stricte

Une liste d'autorisation de domaines peut devenir fragile. Un CDN de confiance peut héberger de nombreux fichiers sans rapport, et un chargeur tiers peut récupérer dynamiquement des dépendances supplémentaires. web.dev recommande une CSP stricte basée sur des nonces ou des hashes ; strict-dynamic permet aux scripts chargés par un script de confiance d'hériter de cette confiance.

Exemple de politique par nonce :

Content-Security-Policy:
  default-src 'self';
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'none';
  form-action 'self';
  script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic';
  style-src 'self' 'nonce-{RANDOM_NONCE}';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  upgrade-insecure-requests

HTML correspondant :

<script nonce="{RANDOM_NONCE}">
  window.__APP_CONFIG__ = { apiUrl: "https://api.example.com" };
</script>

Un nonce doit être imprévisible, unique pour chaque réponse HTML, présent dans l'en-tête et dans les éléments de confiance, et généré par le serveur. Un nonce constant stocké dans la configuration ne fournit pas la protection prévue. Pour les pages statiques qui ne peuvent pas générer une nouvelle valeur à chaque requête, les hashes peuvent être plus pratiques.

Évitez unsafe-inline et unsafe-eval

'unsafe-inline' dans script-src autorise le JavaScript inline et affaiblit fortement la protection contre les XSS. 'unsafe-eval' active des API qui exécutent des chaînes de caractères en tant que code, notamment eval() et le constructeur Function.

Ne les ajoutez pas simplement pour faire taire les violations dans la console. À la place :

1. déplacez le code inline dans des fichiers externes ;
2. utilisez un nonce ou un hash ;
3. identifiez la dépendance nécessitant eval ;
4. recherchez une autre configuration de build ou de bibliothèque.

Trusted Types

Une politique telle que :

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy

peut exiger des valeurs typées au niveau de certains points de collecte (sinks) XSS du DOM tels que innerHTML. Depuis février 2026, require-trusted-types-for est disponible dans les principaux navigateurs actuels, bien que les versions plus anciennes puissent ne pas le prendre en charge.

Trusted Types est une défense avancée. L'application doit définir des politiques de transformation sûres, et les frameworks et dépendances doivent être compatibles. Ajouter le seul en-tête ne suffit pas.

Commencez par Report-Only

Un déploiement plus sûr commence par :

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/security/csp-reports"

Content-Security-Policy-Report-Only signale les violations sans bloquer les ressources, ce qui permet d'identifier les origines manquantes et les flux cassés avant l'application. Reporting-Endpoints remplace l'en-tête Report-To déprécié et doit être privilégié pour les déploiements actuels.

Un point de terminaison de rapport doit imposer des limites de taille de charge utile, une limitation de débit, une journalisation sûre, un encodage des sorties et une durée de conservation courte et spécifique à sa finalité. Les rapports CSP peuvent contenir des URL et des détails sur les ressources.

2. Strict-Transport-Security : HTTPS sans possibilité de rétrogradation

HSTS indique au navigateur qu'un hôte ne doit être contacté que via HTTPS. Une fois enregistré, le navigateur met à niveau les futures tentatives HTTP et empêche les utilisateurs de contourner certaines erreurs de certificat.

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

• max-age=31536000 stocke la politique pendant un an.
• includeSubDomains couvre les sous-domaines.
• preload indique une intention de rejoindre la liste de preload des navigateurs.

Ne commencez pas par preload

Un mauvais déploiement de HSTS peut bloquer l'accès à des utilisateurs légitimes. Un ancien sous-domaine uniquement HTTP, un certificat expiré ou un service tiers sous votre domaine peuvent rendre includeSubDomains et un max-age long dangereux.

Un déploiement prudent peut utiliser :

5 minutes → 1 day → 1 week → 1 month → 1 year

À chaque étape, testez le domaine apex, les sous-domaines actifs, les certificats wildcard et SAN, les services hérités, les panneaux d'administration, les API et les points de terminaison partenaires.

Le preload HSTS nécessite un certificat valide, des redirections HTTP vers HTTPS, un max-age suffisamment long, includeSubDomains et le jeton preload. La suppression peut prendre des semaines car la liste est livrée à l'intérieur des navigateurs.

3. X-Content-Type-Options : mettre fin aux suppositions MIME

X-Content-Type-Options: nosniff

Cela indique au navigateur de respecter le Content-Type déclaré plutôt que de réinterpréter une réponse comme un autre type. Les scripts et les styles peuvent être bloqués lorsque leur type MIME ne correspond pas à ce qui est attendu.

Cela ne remplace pas une configuration correcte du serveur. Les réponses ont toujours besoin de valeurs exactes :

Content-Type: text/html; charset=utf-8
Content-Type: text/css; charset=utf-8
Content-Type: application/javascript; charset=utf-8
Content-Type: application/json; charset=utf-8
Content-Type: image/avif

Ceci est particulièrement important pour les téléversements d'utilisateurs, les points de terminaison de téléchargement, les fichiers générés dynamiquement, le stockage d'objets, les CDN et les réponses d'erreur qui pourraient renvoyer du HTML au lieu de JSON.

4. Referrer-Policy : réduire la fuite d'URL

Referrer-Policy contrôle quelle part de l'URL de la page actuelle peut être envoyée dans l'en-tête Referer lors de la requête d'une autre ressource.

Une valeur par défaut raisonnable est :

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

Elle envoie l'URL complète pour les requêtes same-origin, uniquement l'origine pour les requêtes HTTPS cross-origin, et aucun référent lors d'une rétrogradation de HTTPS vers HTTP.

Les alternatives plus strictes incluent :

Referrer-Policy: no-referrer

ou :

Referrer-Policy: same-origin

Ce choix peut affecter l'analytique, les systèmes d'affiliation et les fournisseurs de paiement. Les secrets, les jetons, les adresses e-mail et les données personnelles ne devraient de toute façon jamais être placés dans les URL.

5. Protection contre le clickjacking : frame-ancestors et X-Frame-Options

Le contrôle le plus flexible est CSP :

Content-Security-Policy: frame-ancestors 'none'

ou :

Content-Security-Policy: frame-ancestors 'self' https://portal.partner.example

frame-ancestors définit quels parents peuvent intégrer un document dans <frame>, <iframe>, <object> ou <embed>.

Pour la compatibilité, ajoutez :

X-Frame-Options: DENY

ou :

X-Frame-Options: SAMEORIGIN

MDN recommande frame-ancestors pour les déploiements modernes car il est plus expressif. ALLOW-FROM est obsolète et peut amener les navigateurs actuels à ignorer l'en-tête. X-Frame-Options doit être un en-tête HTTP ; une version <meta http-equiv> n'a aucun effet.

6. Permissions-Policy : désactiver les capacités que le site n'utilise pas

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

L'en-tête contrôle l'accès d'un document et de ses frames à certaines capacités du navigateur, notamment la caméra, le microphone et la géolocalisation.

Autoriser l'origine actuelle :

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

Ou autoriser une origine explicite :

Permissions-Policy: geolocation=(self "https://maps.example")

Ne copiez pas une liste énorme de toutes les directives connues. Les différentes directives ont un support de navigateur différent et certaines restent expérimentales. Identifiez les capacités utilisées par l'application, puis désactivez explicitement celles qui sont pertinentes mais inutilisées.

7. COOP, COEP et CORP : l'isolation cross-origin n'est pas une valeur par défaut universelle

Ces en-têtes sont liés mais résolvent des problèmes différents.

Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy: same-origin

COOP contrôle si les documents ouverts via une navigation ou window.open() partagent un groupe de contextes de navigation. same-origin sépare le document des ouvreurs cross-origin et atténue certaines XS-Leaks.

Il peut casser les popups OAuth, les fenêtres de paiement et les intégrations reposant sur window.opener. Dans certains cas, ceci est plus approprié :

Cross-Origin-Opener-Policy: same-origin-allow-popups

Cross-Origin-Embedder-Policy

Cross-Origin-Embedder-Policy: require-corp

COEP exige que les ressources no-cors cross-origin accordent une permission via CORP ou soient récupérées avec CORS. L'absence d'en-têtes peut bloquer les images, les polices, les scripts, les frames et d'autres ressources tierces.

Une alternative est :

Cross-Origin-Embedder-Policy: credentialless

Cela autorise certaines ressources no-cors sans CORP explicite tout en supprimant les identifiants tels que les cookies.

Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy: same-origin

CORP est une politique sur la ressource elle-même et peut utiliser :

• same-origin,
• same-site,
• cross-origin.

Ce n'est pas un remplacement de CORS. MDN documente également un problème Chrome impliquant un rendu partiel des PDF sous certains déploiements CORP, aussi l'en-tête ne devrait pas être appliqué globalement sans tests.

La paire :

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

active l'isolation cross-origin requise par certaines API avancées, notamment l'accès complet à SharedArrayBuffer. Ne la déployez pas uniquement pour le score d'un scanner.

8. Cookies et mise en cache sécurisés

Set-Cookie et Cache-Control ne sont pas toujours répertoriés comme des en-têtes de sécurité, mais ils protègent directement les sessions et les données sensibles.

Cookie de session

Set-Cookie: __Host-session=RANDOM_VALUE; Path=/; Secure; HttpOnly; SameSite=Lax

• Secure restreint la transmission à HTTPS.
• HttpOnly empêche l'accès par JavaScript.
• SameSite limite l'envoi cross-site.
• __Host- nécessite Secure, Path=/ et aucun Domain, liant le cookie plus étroitement à l'hôte.

SameSite=Strict est plus fort mais peut perturber les retours depuis les fournisseurs de connexion ou de paiement. SameSite=None nécessite Secure et ne devrait être utilisé que pour un cookie réellement cross-site.

Réponses sensibles

Cache-Control: no-store

Cela demande aux caches privés et partagés de ne pas stocker la réponse. Le contenu personnalisé qui peut être mis en cache dans le navigateur mais pas par les intermédiaires peut utiliser :

Cache-Control: private, no-cache

MDN recommande de marquer explicitement les réponses personnalisées comme private pour éviter une mise en cache partagée accidentelle.

9. Réduire la divulgation des technologies

Des en-têtes tels que :

Server: nginx/1.24.0
X-Powered-By: PHP/8.4
X-AspNet-Version: 4.0.30319

facilitent le fingerprinting. Les supprimer ne cache pas la stack à un attaquant déterminé, mais évite la divulgation directe des versions.

• supprimez X-Powered-By ;
• désactivez les en-têtes de version des frameworks ;
• limitez les détails dans Server ;
• ne publiez pas une version délibérément fausse ;
• ne confondez pas l'obscurité avec l'application de correctifs.

L'OWASP recommande de supprimer X-Powered-By et de limiter Server, tout en notant que les technologies peuvent toujours être déduites par d'autres moyens.

10. En-têtes obsolètes et conseils trompeurs

X-XSS-Protection

N'activez pas :

X-XSS-Protection: 1; mode=block

L'OWASP avertit que les filtres XSS hérités peuvent créer des vulnérabilités dans des pages par ailleurs sûres. Omettez l'en-tête ou désactivez-le explicitement :

X-XSS-Protection: 0

Utilisez plutôt CSP, l'encodage des sorties et des API sûres.

Expect-CT

Expect-CT est obsolète en pratique car les clients actuels exigent la Certificate Transparency pour les certificats modernes. MDN le décrit comme largement obsolète depuis juin 2021.

Public-Key-Pins

HPKP ne devrait pas être déployé. Un mauvais épinglage pourrait bloquer les utilisateurs pendant longtemps et l'en-tête a été retiré des navigateurs modernes. Privilégiez un TLS correct, le renouvellement automatisé, CAA, la surveillance des certificats et un preload HSTS soigneusement examiné.

Report-To

L'ancien :

Report-To: { ... }

est déprécié. Utilisez :

Reporting-Endpoints: csp="https://example.com/reports/csp"

Access-Control-Allow-Origin: *

CORS n'est pas un ensemble d'en-têtes de durcissement à ajouter globalement. Access-Control-Allow-Origin assouplit la Same-Origin Policy. Les réponses d'API avec identifiants ne peuvent pas combiner en toute sécurité le caractère générique * avec un accès cross-origin authentifié. N'autorisez que les origines nécessaires et validez-les côté serveur.

11. Exemples de configuration serveur

Nginx

add_header Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header X-Frame-Options "DENY" always;

always est important car il conserve les en-têtes sur les réponses d'erreur et de statut non standard.

Apache

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set X-Frame-Options "DENY"
</IfModule>

PHP

<?php

header("Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests");
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("X-Content-Type-Options: nosniff");
header("Referrer-Policy: strict-origin-when-cross-origin");
header("Permissions-Policy: camera=(), microphone=(), geolocation=()");
header("X-Frame-Options: DENY");

Les en-têtes doivent être envoyés avant le corps de la réponse. Générez un nonce cryptographiquement aléatoire séparément pour chaque requête.

Node.js / Express

app.use((req, res, next) => {
  res.setHeader(
    "Content-Security-Policy",
    "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  );
  res.setHeader(
    "Strict-Transport-Security",
    "max-age=31536000; includeSubDomains"
  );
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
  res.setHeader(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=()"
  );
  res.setHeader("X-Frame-Options", "DENY");
  res.removeHeader("X-Powered-By");
  next();
});

Un site utilisant des CDN, des WebSockets, OAuth, des paiements ou des cartes aura besoin d'une CSP plus large mais toujours explicite.

12. Un processus de déploiement qui évite les pannes

Inventaire

Répertoriez toutes les origines de scripts, de styles, de polices et d'images ; les points de terminaison API et WebSocket ; les iframes ; les popups OAuth/paiement ; les ressources CDN ; les téléversements d'utilisateurs ; les sous-domaines HSTS et les capacités du navigateur utilisées par l'application.

Observer

• exécutez CSP en Report-Only ;
• collectez les rapports et les violations dans la console du navigateur ;
• testez chaque parcours utilisateur critique ;
• incluez le mobile et les navigateurs pris en charge ;
• inspectez les pages d'erreur, les redirections et les ressources statiques.

Appliquer progressivement

• commencez par object-src, base-uri, frame-ancestors et form-action ;
• passez aux ressources statiques ;
• appliquez un script-src strict en dernier ;
• augmentez le max-age de HSTS progressivement ;
• testez COOP/COEP séparément par rapport aux popups et aux intégrations cross-origin.

Surveiller les régressions

Les tests de CI devraient récupérer des URL représentatives, détecter les en-têtes en double ou en conflit, confirmer les types MIME, détecter la suppression accidentelle de CSP/HSTS et exécuter des flux de connexion et de paiement de bout en bout.

13. Comment tester les en-têtes

Vérifiez la réponse directement :

curl -I https://example.com/

Suivez les redirections :

curl -IL https://example.com/

Inspectez une ressource spécifique :

curl -I https://example.com/assets/app.js

Vérifiez les en-têtes sur la page d'accueil, la connexion, les réponses 404 et 500 ; confirmez que la CSP n'est pas dupliquée avec des politiques en conflit ; assurez-vous que HSTS n'est envoyé que via HTTPS ; vérifiez les types MIME ; et vérifiez qu'un CDN ou un proxy inverse n'a pas supprimé les en-têtes.

Le Security Headers Inspector gratuit de POLPROG vérifie HSTS, CSP, la protection contre le framing et d'autres contrôles. Utilisez le DNS & SSL Inspector pour les vérifications de certificat et de DNS, et Website Health Check pour un examen plus large du SEO, des performances, de l'accessibilité et de la sécurité.

Liste de vérification pour le déploiement

CSP

• default-src restrictif.
• object-src 'none'.
• base-uri limité.
• frame-ancestors correspond au modèle d'intégration réel.
• form-action restreint les destinations de formulaire.
• Le code inline utilise un nonce ou un hash lorsque nécessaire.
• Le nonce est unique par réponse.
• Aucun 'unsafe-inline' injustifié.
• Aucun 'unsafe-eval' injustifié.
• Politique d'abord testée en Report-Only.
• Le point de terminaison de rapport a des limites de débit et une conservation limitée.

HTTPS et HSTS

• Chaque page et ressource fonctionne via HTTPS.
• HTTP redirige directement vers HTTPS.
• Les certificats sont surveillés.
• Tous les sous-domaines sont inventoriés.
• max-age augmenté par étapes.
• includeSubDomains est sûr.
• preload ajouté uniquement après avoir examiné les conséquences.

Autres contrôles

• X-Content-Type-Options: nosniff.
• Content-Type correct sur chaque réponse.
• Referrer-Policy explicite.
• Permissions-Policy désactive les capacités inutilisées.
• Aucun ALLOW-FROM dans X-Frame-Options.
• COOP ne casse pas OAuth ni les paiements.
• COEP ne bloque pas les ressources tierces nécessaires.
• CORP correspond au modèle de partage de chaque ressource.
• Les cookies de session utilisent Secure, HttpOnly et un SameSite approprié.
• Les réponses sensibles utilisent un Cache-Control correct.
• Les en-têtes de version des technologies sont supprimés.
• X-XSS-Protection est absent ou désactivé.
• Expect-CT, HPKP et l'ancien Report-To sont supprimés.

Verdict

Pour la plupart des sites web professionnels et des applications web, le bon ordre est :

1. HTTPS correct, types MIME et cookies sécurisés.
2. Une CSP spécifique à l'application déployée via Report-Only.
3. HSTS déployé par étapes.
4. nosniff, Referrer-Policy, Permissions-Policy et protection contre le framing.
5. COOP, COEP et CORP uniquement lorsque le modèle cross-origin est compris.
6. Suppression des en-têtes obsolètes et divulguant des informations.

Le meilleur ensemble d'en-têtes de sécurité n'est pas le plus long. C'est la plus petite politique qui correspond précisément à l'application, survit aux tests des parcours critiques et reste surveillée après chaque déploiement.