PawaHeaders — HTTP Security Headers Builder

Pourquoi les headers HTTP de sécurité sont importants

Les headers HTTP de sécurité sont une couche de durcissement côté navigateur. Ils ne corrigent pas une application vulnérable, ne remplacent pas les mises à jour, ne sécurisent pas une authentification faible et ne rendent pas un site invulnérable. Mais leur absence est souvent un signe d’hygiène technique faible.

En pratique, ces headers indiquent au navigateur comment traiter certaines situations : chargement de scripts, intégration en iframe, permissions accordées aux APIs navigateur, politique de référent, protection contre l’interprétation incorrecte des types MIME, ou comportement cross-origin.

Les headers les plus courants

Strict-Transport-Security

Strict-Transport-Security, souvent appelé HSTS, force le navigateur à utiliser HTTPS pendant une durée donnée. Il est utile uniquement si HTTPS est correctement configuré sur le domaine et ses sous-domaines.

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

Attention : activer HSTS trop tôt peut créer des problèmes si certains sous-domaines ne sont pas prêts en HTTPS.

Content-Security-Policy

Content-Security-Policy, ou CSP, est l’un des headers les plus puissants. Il permet de définir quelles sources sont autorisées pour les scripts, styles, images, polices, frames et autres ressources.

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self';

C’est aussi le header le plus susceptible de casser un site s’il est déployé sans test. WordPress, les thèmes, les plugins, les outils analytics ou les systèmes de paiement peuvent charger des ressources externes.

X-Content-Type-Options

X-Content-Type-Options: nosniff demande au navigateur de ne pas deviner le type MIME d’une ressource. C’est un header simple, peu risqué et généralement recommandé.

X-Frame-Options

X-Frame-Options limite l’intégration du site dans une iframe. Il aide à réduire certains risques de clickjacking.

X-Frame-Options: SAMEORIGIN

Pour une interface d’administration, DENY peut être plus pertinent.

Referrer-Policy

Referrer-Policy contrôle les informations envoyées dans l’en-tête Referer lorsqu’un utilisateur quitte une page ou charge une ressource.

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

Permissions-Policy

Permissions-Policy permet de désactiver certaines fonctionnalités navigateur comme la caméra, le micro ou la géolocalisation lorsqu’elles ne sont pas nécessaires.

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

Adapter selon le contexte

Site vitrine

Un site vitrine peut généralement utiliser une base raisonnable : HSTS si HTTPS est propre, nosniff, referrer policy, permissions limitées et protection iframe.

WordPress

WordPress nécessite plus de prudence, surtout avec CSP. Les thèmes, builders et plugins peuvent utiliser des scripts inline, des styles inline et des ressources externes. Une politique trop stricte peut casser l’éditeur, les formulaires ou certaines intégrations.

API

Une API n’a pas les mêmes besoins qu’un site web classique. Les headers navigateur sont parfois moins importants que CORS, l’authentification, les limites de taux, la gestion des erreurs et la journalisation.

Admin panel

Une interface d’administration mérite une politique plus stricte : pas d’intégration iframe inutile, peu de ressources externes, permissions navigateur fermées et session correctement protégée.

Déployer proprement

Après avoir généré une configuration, il faut vérifier ce qui est réellement envoyé par le serveur public :

curl -I https://example.com

Une erreur fréquente consiste à modifier un fichier de configuration sans que le service ne l’utilise vraiment, ou à définir les headers à plusieurs niveaux : application, reverse proxy, CDN. Dans ce cas, les règles peuvent être écrasées ou devenir incohérentes.

Position d’admin systèmes

Les headers HTTP sont une mesure de durcissement. Ils doivent être testés, documentés et adaptés au contexte. Un bon réglage est celui qui améliore la sécurité sans casser les parcours utilisateur ni rendre la maintenance opaque.

HTTP security headers are a hardening layer. They must be tested, documented and adapted to the real service.