Comprendre les en-têtes de sécurité web
Auteur : Rédaction Domeny.ForSale Publié le
En bref : les Security Headers sont des en-têtes de réponse HTTP qui indiquent au navigateur les règles à suivre pour traiter une page de manière sécurisée. Ils contribuent notamment à limiter l’exécution de scripts indésirables, l’intégration de la page dans les cadres d’autres sites et la divulgation d’informations lors du passage d’un site à l’autre. Ils ne remplacent ni un code sécurisé ni les mises à jour, mais constituent une couche de protection supplémentaire.
Comment fonctionnent les en-têtes de sécurité
Lorsque le navigateur récupère une page, le serveur lui envoie son contenu ainsi que des métadonnées, c’est-à-dire des informations décrivant la réponse. Les en-têtes HTTP font partie de ces métadonnées. Ils n’apparaissent pas dans le texte de la page, mais le navigateur peut s’en servir pour restreindre l’utilisation des ressources reçues.
Les en-têtes de sécurité peuvent imposer une connexion chiffrée, préciser les sources de scripts autorisées ou interdire l’intégration de la page dans un cadre d’un autre site. Ils se définissent généralement dans la configuration du serveur, de l’application, du proxy inverse ou du CDN, l’infrastructure qui sert d’intermédiaire pour distribuer le contenu.
Ces protections sont appliquées avant tout par le navigateur. Elles n’empêchent pas d’envoyer directement des requêtes à l’application avec d’autres outils et ne remplacent donc pas le contrôle des autorisations côté serveur.
Les principaux Security Headers et leurs usages
Il n’existe pas de configuration unique adaptée à tous les sites. Les en-têtes suivants répondent à des menaces différentes et doivent être adaptés au fonctionnement du site.
| En-tête | Rôle | Points de vigilance |
|---|---|---|
Content-Security-Policy | Définit notamment les sources autorisées pour les scripts, les styles et les autres ressources. | Une politique trop restrictive peut bloquer un formulaire, les paiements ou les outils d’analyse. |
Strict-Transport-Security | Impose au navigateur d’utiliser HTTPS pendant une durée définie. | Une longue durée d’application et l’inclusion des sous-domaines nécessitent de préparer toute l’infrastructure. |
X-Content-Type-Options | Avec la valeur nosniff, limite la détection d’un type de ressource différent de celui déclaré par le serveur. | Le serveur doit envoyer un Content-Type correct, notamment pour les scripts et les feuilles de style. |
Referrer-Policy | Contrôle les informations sur l’adresse de la page transmises dans l’en-tête Referer. | Le réglage doit tenir compte de la confidentialité et des besoins des intégrations. |
Permissions-Policy | Restreint l’accès à certaines fonctions du navigateur, comme la caméra ou la géolocalisation. | La prise en charge de chaque directive dépend du navigateur. |
X-Frame-Options | Limite l’intégration de la page dans des cadres. | Offre moins de souplesse que la directive frame-ancestors de CSP. |
CSP, pour Content Security Policy, aide à limiter les conséquences des attaques XSS, qui consistent à exécuter du code indésirable dans le contexte de la page. Une simple liste de domaines de confiance ne suffit pas à assurer une protection complète : les directives choisies, le mode de chargement des scripts et l’absence d’exceptions trop larges sont déterminants.
La directive frame-ancestors de CSP contribue notamment à protéger contre le clickjacking, une technique qui pousse l’utilisateur à cliquer sur un élément d’une page dissimulée dans un autre site. Elle peut interdire complètement l’intégration de la page ou ne l’autoriser que sur certains sites désignés.
Exemple : un site avec un formulaire et des services externes
Supposons qu’un site d’entreprise utilise un formulaire de contact, une carte et un outil d’analyse externe. Déployer une CSP qui n’autorise que les ressources provenant du domaine du site peut empêcher la carte et l’outil d’analyse de fonctionner. Avant le déploiement, il faut donc déterminer d’où proviennent les scripts, les styles, les images et les cadres chargés par le site, et vers quelles destinations il envoie des requêtes.
Si le site ne doit être intégré dans aucun cadre, voici un exemple de fragment de politique :
Content-Security-Policy: frame-ancestors 'none'
Il s’agit uniquement d’une règle relative à l’intégration dans des cadres, et non d’une politique CSP complète. Elle ne restreint ni les sources de scripts ni les connexions réseau. Si le site possède déjà une CSP, il faut intégrer cette règle à la configuration existante en connaissance de cause, plutôt que d’ajouter une autre politique sans vérification.
Pour un site qui n’a besoin ni de caméra ni de microphone, on peut envisager :
Permissions-Policy: camera=(), microphone=()
Ce réglage ne doit pas être repris dans une application proposant des appels vidéo. Un en-tête bien configuré limite les possibilités inutiles, pas les fonctions indispensables à l’utilisateur.
Comment vérifier et déployer les en-têtes en toute sécurité
Le plus simple est d’ouvrir les outils de développement du navigateur, d’accéder à l’onglet réseau, d’actualiser la page et de sélectionner la requête du document principal. La section des en-têtes de réponse permet de vérifier ce que le navigateur a réellement reçu. La présence d’un réglage dans la configuration du serveur ne signifie pas à elle seule que l’en-tête parvient à l’utilisateur.
Voici un ordre de déploiement pratique :
- Vérifiez des adresses représentatives : la page d’accueil, la connexion, les formulaires et les pages d’erreur. Les réponses peuvent passer par différentes couches de l’infrastructure.
- Déterminez où les en-têtes sont gérés. L’application, le serveur et le CDN ne doivent pas écraser accidentellement les réglages ni ajouter des règles contradictoires.
- Préparez la CSP en mode
Content-Security-Policy-Report-Only. Ce mode permet d’observer les violations sans bloquer les ressources ; la collecte des rapports nécessite une configuration supplémentaire. - Testez les actions essentielles de l’utilisateur, notamment la connexion, l’envoi d’un formulaire et le paiement, si le site en propose.
- Activez l’application de la politique et surveillez les erreurs après le déploiement.
Ne déployez HSTS, le mécanisme activé par Strict-Transport-Security, qu’une fois HTTPS pleinement fonctionnel. Le paramètre includeSubDomains englobe aussi les sous-domaines : avant de l’utiliser, vérifiez donc également les services moins évidents. Confirmez la syntaxe actuelle et la prise en charge des directives dans la documentation officielle de la plateforme utilisée et des navigateurs.
Ce que le résultat d’un scanner de sécurité ne dit pas
Un scanner peut détecter un en-tête manquant ou une valeur risquée, mais son évaluation ne prouve pas que l’application est sécurisée. Certaines politiques ne sont nécessaires que pour des usages précis, et les ajouter pour obtenir un meilleur score peut perturber les intégrations.
Les en-têtes ne corrigent ni les erreurs d’autorisation, ni les vulnérabilités de la base de données, ni la divulgation de secrets dans le code. Commencez par examiner les réponses réelles de votre site, puis choisissez une modification dont vous pouvez vérifier le fonctionnement avant la mise en production.
Voir aussi : Qu’est-ce que CSP ?
À lire aussi
