← Toutes les vérifications
SécuritéSévérité typique: Faible

En-têtes d'isolation d'origine

Vérifie s'il manque les en-têtes COOP et CORP qui isolent ton site contre les attaques cross-origin.

Ce qu'elle vérifie

Ce scanner vérifie s'il manque à ton site les en-têtes d'isolation d'origine COOP et CORP. Il détecte l'absence de ces en-têtes qui séparent ta page des autres origines dans le navigateur.

Pourquoi ça compte

Sans ces en-têtes, ta page est plus exposée à certaines attaques cross-origin où un autre site tente d'interagir avec la tienne ou de lire des données qu'il ne devrait pas. L'isolation d'origine est une couche de protection supplémentaire qui réduit ce type de risque.

Comment la corriger

Ajoute les en-têtes Cross-Origin-Opener-Policy et Cross-Origin-Resource-Policy dans la configuration de ton serveur ou de ton CDN. Commence par des valeurs prudentes et vérifie que tes ressources et intégrations fonctionnent toujours avant de les renforcer.

Comment fonctionne cette vérification

Scanaris regarde dans la réponse principale de ta page si deux en-têtes sont présents : Cross-Origin-Opener-Policy (COOP) et Cross-Origin-Resource-Policy (CORP). S'il en manque un ou les deux, il ouvre un seul constat de sévérité faible en indiquant lesquels. Il n'évalue pas la valeur, seulement la présence. Ce sont les deux en-têtes d'isolation d'origine les plus simples à adopter ; le troisième de la famille, Cross-Origin-Embedder-Policy, n'est pas exigé parce qu'il casse toute ressource tierce qui ne coopère pas et vaut rarement le coup sur un site ordinaire.

Ce que protège chacun

COOP décide si ta fenêtre partage un « groupe de contexte » avec celle qui l'a ouverte ou avec celles que tu ouvres. Avec same-origin, une page d'un autre domaine qui ouvre la tienne avec window.open n'a plus de référence utilisable vers elle (et inversement), ce qui coupe les attaques de manipulation entre onglets et ferme la voie par laquelle s'exploitent les fuites mémoire de type Spectre. CORP décide qui peut intégrer tes ressources. Avec same-origin, un autre site ne peut pas charger tes images, scripts ou polices avec une balise <img> ou <script> même si les URL sont publiques : le navigateur bloque la réponse avant qu'elle n'atteigne ce site. Aucun des deux ne corrige une faille existante ; c'est de la défense en profondeur, et c'est pourquoi leur absence est de sévérité faible.

Comment les ajouter

Valeurs recommandées pour un site qui ne partage pas de ressources avec d'autres domaines :

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
  • Nuxt : dans routeRules de nuxt.config, sous la règle '/**', à côté de tes autres en-têtes.
  • Next.js : dans la fonction headers() de next.config.js.
  • Vercel : dans vercel.json, section headers. Netlify : dans _headers, sous /*.
  • nginx : deux lignes add_header ... always; dans le bloc server. Apache : Header always set dans le VirtualHost.
  • Express : helmet() les ajoute par défaut dans les versions récentes ; vérifie la version installée.

Deux points à vérifier avant de les activer

  • Connexions par fenêtre surgissante. Si tu utilises « Se connecter avec Google » ou un autre fournisseur en mode popup, la popup doit dialoguer avec la fenêtre qui l'a ouverte. Avec same-origin, ça ne fonctionne plus ; utilise same-origin-allow-popups, qui garde la protection et autorise ce cas.
  • Ressources que tu sers à d'autres domaines. Si tes images ou polices sont chargées depuis un autre de tes sites (un blog sur un autre domaine, un widget que des tiers intègrent), same-origin les bloquera là-bas. Utilise same-site si l'autre site est un sous-domaine, ou cross-origin sur les routes précises de ces ressources.

Vérifie que c'est corrigé

curl -sI https://tondomaine.com | grep -iE "^cross-origin-(opener|resource)-policy:"

Les deux lignes doivent apparaître. Ouvre ensuite ton site, teste la connexion et toute intégration par popup, et regarde la console du navigateur : une ressource bloquée par CORP y apparaît avec un message explicite.

Questions fréquentes

Est-ce que ça remplace CORS ?

Non, ils sont complémentaires et vont dans des directions opposées. CORS ouvre tes réponses à des origines précises quand c'est nécessaire ; CORP les ferme par défaut à quiconque veut les intégrer. Tu peux avoir CORP same-origin sur tout le site et CORS ouvert sur une route d'API.

Ai-je aussi besoin de Cross-Origin-Embedder-Policy ?

Seulement si tu veux SharedArrayBuffer ou des minuteurs haute précision (montage vidéo, émulateurs, certaines applis WebAssembly). COEP exige que tout ce que tu intègres porte CORP ou CORS, et la plupart des scripts tiers ne le font pas. Pour un site courant, COOP et CORP suffisent.

De combien ça améliore la note ?

Peu en points, parce que c'est un constat de sévérité faible ; mais c'est l'une des rares améliorations sans effets secondaires si tu fais les deux vérifications ci-dessus. Les en-têtes qui pèsent vraiment sont dans en-têtes de sécurité et expliqués dans les en-têtes HTTP pour les humains.

Vérifie-le sur ton site

Analyse ton site gratuitement et vois si celle-ci et 44 autres vérifications passent, avec un fix prompt pour chaque problème.

Analyser mon site gratuitement

Sur le blog

Vérifications liées