Les en-têtes de sécurité peuvent-ils casser mon site web ?

La plupart non. Content-Security-Policy le peut, si elle bloque des scripts dont vous avez besoin. Commencez par Content-Security-Policy-Report-Only pour voir ce qui serait bloqué.

X-XSS-Protection est-il encore nécessaire ?

Non. Les navigateurs modernes ont supprimé ce filtre. Utilisez plutôt une Content-Security-Policy.

Pourquoi le scan ne regarde-t-il que la page d’accueil ?

Les en-têtes sont généralement définis pour tout le site d’un coup. Le scan est volontairement passif : une seule visite, pas d’exploration.

Vérification des en-têtes de sécurité

Testez quels en-têtes de sécurité HTTP un site web envoie et obtenez une note de A à F avec l’en-tête exact à ajouter. Le HTTPS, les cookies et les versions de logiciels visibles sont vérifiés dans le même scan.

Les en-têtes qui comptent

Strict-Transport-Security (HSTS) : les navigateurs n’utilisent que le HTTPS pour votre site, même si quelqu’un tape http://.

Content-Security-Policy (CSP) : les scripts, styles et cadres que la page peut charger. La meilleure défense contre le cross-site scripting.

X-Frame-Options ou CSP frame-ancestors : empêche d’autres sites d’afficher le vôtre dans un cadre caché (clickjacking).

X-Content-Type-Options: nosniff, pour que les navigateurs ne devinent pas les types de fichiers.

Referrer-Policy et Permissions-Policy : ce que votre site partage avec d’autres sites et quelles fonctions du navigateur il peut utiliser.

Exemple pour nginx

Ajoutez ces lignes au bloc server de votre site et rechargez nginx. Construisez la Content-Security-Policy étape par étape, car une politique trop stricte peut casser des scripts.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

add_header X-Content-Type-Options "nosniff" always;

add_header X-Frame-Options "SAMEORIGIN" always;

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Apache, IIS, Cloudflare et panneaux d’hébergement

Apache utilise « Header always set » dans .htaccess ou dans le virtual host, IIS utilise customHeaders dans web.config, et Cloudflare utilise les Transform Rules. Sur un hébergement géré, envoyez le lien du rapport à votre hébergeur : chaque constat indique l’en-tête exact.

Questions

Les en-têtes de sécurité peuvent-ils casser mon site web ?: La plupart non. Content-Security-Policy le peut, si elle bloque des scripts dont vous avez besoin. Commencez par Content-Security-Policy-Report-Only pour voir ce qui serait bloqué.
X-XSS-Protection est-il encore nécessaire ?: Non. Les navigateurs modernes ont supprimé ce filtre. Utilisez plutôt une Content-Security-Policy.
Pourquoi le scan ne regarde-t-il que la page d’accueil ?: Les en-têtes sont généralement définis pour tout le site d’un coup. Le scan est volontairement passif : une seule visite, pas d’exploration.

OZAG Technologies · KVK 42167370 · Laan van Oversteen 20, 2289 CX Rijswijk · +31 6 24496620 · support@ozagsecurity.com