En-têtes de sécurité : comprendre les résultats
Examinez les valeurs des politiques et les en-têtes manquants sans perturber les fonctions légitimes du site.
Équipe technique de check.uk.app · Vérifié le 26 septembre 2026
La présence n’est que la première vérification
check.uk.app enregistre les en-têtes de la réponse testée. Leur présence ne prouve ni l’efficacité d’une politique ni son application à chaque route. Ouvrez les en-têtes HTTP pour examiner leurs valeurs. Comparez la page d’accueil, la connexion et les réponses d’erreur ; les règles du proxy et de l’application peuvent différer.
Maintien de HTTPS et types de contenu
Strict-Transport-Security impose aux navigateurs de continuer à utiliser HTTPS pendant la durée configurée. Vérifiez HTTPS sur tous les sous-domaines concernés avant d’utiliser includeSubDomains. Commencez par une durée courte : supprimer l’en-tête n’annule pas immédiatement une politique en cache. Le préchargement, ou preload, est une décision distincte.
X-Content-Type-Options: nosniff indique aux navigateurs de respecter le type de contenu déclaré. Vérifiez que JavaScript et CSS ont les bons types MIME. Corrigez un Content-Type erroné à sa source plutôt que de désactiver cette protection.
Intégration dans des cadres et données de provenance
X-Frame-Options limite l’intégration dans des cadres ; la directive CSP frame-ancestors permet de contrôler plus finement les sites autorisés à intégrer le contenu. Tenez compte des intégrations légitimes chez vos partenaires avant de les restreindre.
Referrer-Policy contrôle la quantité d’informations de l’URL de provenance envoyées par le navigateur. Examinez les parcours qui dépendent du referrer et gardez les secrets hors des URL, quelle que soit la politique.
Introduire CSP en mode observation
Content-Security-Policy-Report-Only observe les violations sans imposer cette politique candidate. Une CSP déjà imposée reste active. Les outils de développement du navigateur affichent les violations ; leur collecte sur un serveur nécessite un point de réception et une configuration correspondante.
Recensez les scripts, styles, cadres et requêtes nécessaires à la connexion, au CAPTCHA, aux paiements et à l’analyse du trafic. Testez ces parcours avant d’imposer la politique. Ne copiez pas une politique default-src stricte en production uniquement pour obtenir un résultat vert.
Vérifier une politique à la fois
Relevez les en-têtes actuels et le comportement du navigateur, modifiez une politique dans un environnement de test et recommencez les vérifications. Testez les réponses réussies et les erreurs via le proxy public, pas seulement directement sur l’application. Conservez une sauvegarde de la configuration et une procédure de retour arrière ; HSTS en cache demande une attention particulière.
Il s’agit d’un guide d’interprétation, pas d’une configuration universelle de serveur ni d’un test d’intrusion. Examinez la valeur derrière chaque constat et testez le parcours utilisateur concerné. Une analyse de la page d’accueil ne peut pas vérifier toutes les fonctions de l’application.
