Les 10 erreurs d’en-têtes de sécurité les plus courantes (et comment les corriger)

Les en-têtes de réponse HTTP sont ce rare contrôle de sécurité qui coûte quelques lignes de configuration et protège chaque visiteur immédiatement. C’est aussi pourquoi on les rate si souvent : faciles à copier-coller, difficiles à tester. Voici les dix problèmes qui reviennent sans cesse dans les analyses.

1. Pas de HSTS (ou HSTS sans le préchargement)

Sans Strict-Transport-Security, une seule requête en clair peut être interceptée avant la redirection HTTPS. Définissez un long max-age et incluez les sous-domaines :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

N’ajoutez preload que lorsque chaque sous-domaine est exclusivement HTTPS — c’est difficile à annuler rapidement.

2. Une Content-Security-Policy qui autorise unsafe-inline

script-src 'unsafe-inline' rouvre le trou XSS exact que la CSP est censée fermer. Passez aux nonces ou aux hachages :

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'

3. Laisser la CSP en report-only pour toujours

Content-Security-Policy-Report-Only sert à la phase de déploiement. Beaucoup de sites la laissent des mois, collectant des rapports sans rien appliquer. Utilisez report-only pour trouver les violations, puis basculez vers l’en-tête appliqué une fois le calme revenu.

4. X-Frame-Options au lieu de frame-ancestors

X-Frame-Options est hérité et ne peut exprimer de liste d’autorisation. Préférez la directive CSP, respectée par les navigateurs modernes :

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

5. X-Content-Type-Options manquant

Sans X-Content-Type-Options: nosniff, un navigateur peut faire du MIME-sniffing sur une réponse et exécuter ce que vous avez servi comme texte. Un seul en-tête sans inconvénient — mettez-le toujours.

6. Une Referrer-Policy dangereuse ou absente

La valeur par défaut divulgue les URL complètes (y compris les jetons dans la chaîne de requête) à des tiers. Un choix sûr et largement compatible :

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

7. Permissions-Policy laissée au défaut du navigateur

Si votre application n’utilise ni la caméra, ni le micro, ni la géolocalisation, dites-le explicitement pour qu’un script compromis ne le puisse pas non plus :

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

8. Définir les en-têtes sur le HTML mais pas sur l’API

Les en-têtes posés par un framework front-end oublient souvent les routes d’API, les redirections et les pages d’erreur. Les scanners testent ces chemins directement. Définissez les en-têtes de sécurité en périphérie — proxy inverse, CDN ou middleware de la plateforme — pour une couverture uniforme.

9. Des en-têtes en conflit venant de plusieurs couches

Quand votre application et votre CDN définissent tous deux Content-Security-Policy, le navigateur peut voir deux en-têtes et appliquer l’*intersection*, cassant des fonctions en silence. Choisissez une couche de référence et supprimez les doublons.

10. Mettre en cache des réponses sensibles

Les pages authentifiées et les réponses d’API contenant des données personnelles ne doivent pas être mises en cache par des proxys partagés :

Cache-Control: no-store

Confirmez par une nouvelle analyse

Les en-têtes interagissent : changez-les par petits lots et réanalysez après chacun. Si vous débutez dans la lecture des résultats, commencez par Comment lire un rapport d’analyse de sécurité de site web ; pour la couche de transport sous ces en-têtes, voyez Les erreurs de configuration SSL/TLS qui mettent votre site en danger. La vérification complète des en-têtes s’exécute à chaque analyse — voir toutes les vérifications sur la page des fonctionnalités.