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
routeRulesdenuxt.config, sous la règle'/**', à côté de tes autres en-têtes. - Next.js : dans la fonction
headers()denext.config.js. - Vercel : dans
vercel.json, sectionheaders. Netlify : dans_headers, sous/*. - nginx : deux lignes
add_header ... always;dans le blocserver. Apache :Header always setdans 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 ; utilisesame-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-originles bloquera là-bas. Utilisesame-sitesi l'autre site est un sous-domaine, oucross-originsur 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.