Les pages web modernes ne sont pas construites exclusivement à partir du JavaScript propre à une organisation. Les pages de paiement, les outils d'analyse, les widgets de chat, les systèmes de tests A/B, les balises publicitaires et les SDK de paiement peuvent chacun charger plusieurs scripts tiers. Si l'un de ces scripts est compromis, du code malveillant s'exécutant dans le navigateur de l'utilisateur peut contourner entièrement les contrôles classiques au niveau des requêtes d'un WAAP.
Dans les flux de paiement en particulier, le risque côté client n'est plus seulement une question de bonnes pratiques. PCI DSS 4.0 v4.0.1 a rendu plus visible le contrôle, l'inventaire et l'intégrité des scripts s'exécutant sur les pages de paiement. Les organisations doivent être en mesure de démontrer quelles sources sont autorisées à s'exécuter sur quelles pages.
Demander aux équipes applicatives d'ajouter manuellement des en-têtes CSP, HSTS, de protection contre les frames et de politique de référent à chaque page n'est pas viable. Les modifications de code sont difficiles dans les applications legacy ; dans les applications modernes, différentes équipes de service peuvent ne pas appliquer de manière cohérente le même standard de sécurité. Le résultat est des en-têtes de sécurité présents sur certaines pages et absents sur d'autres.
La bonne approche consiste à appliquer les en-têtes de sécurité navigateur de manière centralisée, indépendamment du code applicatif et depuis une position pilotée par politique. L'ADC doit réécrire les en-têtes de réponse pour standardiser CSP, HSTS, la protection contre le clickjacking, la prévention du MIME-sniffing, le contrôle du référent et le nettoyage des empreintes.
TR7 Protection des scripts côté client offre ce modèle : il applique les en-têtes de sécurité fondamentaux pour le risque côté client au niveau du vService et lie la sécurité navigateur à la politique WAAP centrale.
TR7 implémente la protection des scripts côté client via la réécriture des en-têtes de réponse, un profil CSP, le nettoyage des empreintes et la visibilité conformité.
TR7 applique les en-têtes de sécurité pendant la phase de réponse HTTP en utilisant le comportement set-header ou add-header. Les contrôles de sécurité navigateur peuvent être activés sans modifier le code applicatif ni la structure du certificat.
L'en-tête Content-Security-Policy communique le modèle de sources autorisées au navigateur. TR7 fournit actuellement une protection CSP de base via une approche fixe `default-src 'self';`.
Des en-têtes tels que Server, X-Powered-By, X-AspNet-Version et X-AspNetMvc-Version peuvent être supprimés des réponses. Cela rend plus difficile pour les attaquants de construire un inventaire technologique et de correspondre aux CVE.
Les vServices avec une règle securityHeaders active peuvent être mis en avant comme preuves dans les rapports de conformité. Cela renforce la piste d'audit pour la sécurité des pages de paiement et les processus de contrôle côté client.
La Protection des scripts côté client applique 8 en-têtes de sécurité prêts à l'emploi sous une seule règle securityHeaders.
TR7 peut ajouter l'en-tête Content-Security-Policy via la règle securityHeaders. Le comportement actuel produit une politique de sécurité de base avec `default-src 'self';`. Cette politique vise un comportement navigateur par défaut qui n'accepte que les ressources de la même origine. Les exigences CSP plus complexes doivent être traitées via une configuration d'en-tête personnalisée ou des modifications côté applicatif.
L'en-tête Strict-Transport-Security peut être appliqué sur les connexions TLS. Il demande au navigateur d'exiger HTTPS pour le domaine concerné. Des options telles que includeSubDomains et preload fournissent un comportement de sécurité plus strict. HSTS est appliqué uniquement dans le contexte TLS pour éviter l'émission d'une politique incorrecte aux hôtes HTTP uniquement.
L'en-tête X-Frame-Options peut être appliqué avec la valeur SAMEORIGIN. Cela restreint le chargement de la page dans un iframe sur une origine différente. Il aide à réduire le risque de clickjacking particulièrement sur les pages de connexion, de paiement, de panneau d'administration et de transactions sensibles. Il fournit une protection de base à faible coût contre les attaques de redressement d'interface utilisateur.
L'en-tête X-Content-Type-Options peut être ajouté avec la valeur nosniff. Cela aide à empêcher le navigateur de deviner un type de contenu et d'exécuter du contenu dans un format inattendu. Le contrôle est particulièrement précieux pour les flux de téléchargement de fichiers, le contenu statique et les applications legacy qui retournent des types de contenu incorrects. Le risque côté client lié à la confusion MIME est réduit.
L'en-tête Referrer-Policy peut être appliqué avec un défaut no-referrer-when-downgrade. Cela limite la fuite du référent dans des scénarios tels que les transitions de HTTPS vers HTTP. Le comportement du référent est important sur les URLs portant des paramètres de citoyen, de client ou de session. Les organisations peuvent limiter centralement la quantité d'informations URL source que le navigateur transmet aux sites externes.
L'en-tête Permission-Policy peut être utilisé pour restreindre l'accès aux capacités du navigateur telles que le microphone, la caméra, la géolocalisation et autres API similaires. TR7 applique cet en-tête sous la règle securityHeaders pour réduire la surface de permissions navigateur inutile. Sur les écrans de portail, de paiement et d'administration en particulier, cela empêche les pages d'accéder à des API inattendues. La sécurité côté client n'est pas limitée à la seule origine des scripts.
Bien que l'en-tête X-XSS-Protection ait un effet limité dans les navigateurs modernes, il peut être utilisé pour la compatibilité avec les clients plus anciens. Le comportement `1; mode=block` active un filtre XSS de base dans certains navigateurs legacy. Cet en-tête n'est pas une garantie de sécurité à lui seul et doit être considéré aux côtés des contrôles CSP et WAAP. Il fournit une couche supplémentaire à faible coût pour les organisations ayant une base d'utilisateurs legacy.
TR7 peut supprimer des en-têtes tels que Server, X-Powered-By, X-AspNet-Version et X-AspNetMvc-Version. Ces en-têtes peuvent donner des indications sur le serveur applicatif, le framework ou la version de runtime utilisée. Les attaquants peuvent utiliser ces informations pour la correspondance CVE et les tentatives d'exploitation ciblées. Le nettoyage des empreintes est une étape de durcissement pratique qui réduit la surface d'attaque visible.
securityHeaders peut être lié comme type de règle à des conditions spécifiques de vService, domaine ou chemin. Une page de paiement peut s'exécuter avec un ensemble plus strict, un portail interne avec un autre, et une application legacy avec une combinaison plus permissive. Cela empêche une politique d'en-tête globale unique de casser les applications. Les opérateurs appliquent les en-têtes de sécurité selon le contexte du service.
TR7 implémente le périmètre actuel de la protection des scripts côté client au niveau de la couche des en-têtes de réponse. Aucun agent JavaScript supplémentaire, SDK client ou reverse proxy séparé n'est nécessaire. Cette approche fournit une faible latence et une large compatibilité. La capacité actuelle réelle est la standardisation des en-têtes de sécurité ; aucune revendication n'est faite pour la détection de skimmers au runtime ou l'injection automatique de SRI.
Les vServices avec une règle securityHeaders active peuvent être mis en avant dans les rapports de conformité. Cela facilite le partage avec les auditeurs de l'endroit exact où les en-têtes de sécurité des pages de paiement sont appliqués. Il soutient la production de preuves techniques pour les attentes de sécurité côté client dans le cadre de PCI DSS 4.0 v4.0.1. Les rapports rendent visible non seulement qu'une politique d'en-têtes est configurée, mais sur quels services elle est active.
Lorsque des pages HTML personnalisées sont retournées — pour la protection bot ou le blocage d'accès par exemple — les en-têtes de sécurité peuvent être maintenus sur le même chemin de réponse. Cela empêche les pages d'erreur ou de challenge de retourner avec des en-têtes de sécurité plus faibles que l'application principale. Chaque réponse présentée à l'utilisateur se rapproche du même standard de sécurité navigateur de base. La cohérence est particulièrement importante dans les flux de connexion et de vérification bot.
La protection des scripts côté client opère à travers l'ordre des en-têtes de réponse, la condition HSTS, le comportement CSP fixe, le type de règle securityHeaders et le nettoyage des empreintes.
TR7 peut remplacer certains en-têtes avec set-header et en ajouter d'autres avec add-header. Cette distinction détermine comment se comportent les en-têtes applicatifs existants. Avant de passer en production, il est utile de tester si les en-têtes propres à l'application entrent en conflit avec ceux ajoutés par TR7.
HSTS ne doit être appliqué que sur les connexions TLS. TR7 associe cet en-tête à la condition ssl_fc pour éviter que les hôtes HTTP uniquement ne reçoivent un en-tête HSTS parasite. Une politique HSTS incorrecte peut causer des problèmes d'accès sur certains domaines et doit donc être utilisée avec précaution.
Lorsque le CSP est activé dans le comportement actuel de securityHeaders, l'en-tête `default-src 'self';` est produit comme valeur fixe. Il n'existe pas d'éditeur de directive personnalisée supplémentaire dans les capacités actives de cette page. Pour des exigences CSP plus détaillées, une règle d'en-tête personnalisée ou une configuration côté applicatif doit être planifiée.
securityHeaders ne fonctionne pas comme une règle de scoring de signatures WAAP. Il est traité comme une règle de durcissement des en-têtes de réponse qui est toujours appliquée. Par conséquent, il n'est pas lié à un score d'attaque ou à un résultat de seuil.
Les en-têtes Server, X-Powered-By, X-AspNet-Version et X-AspNetMvc-Version peuvent être supprimés. La suppression de ces en-têtes ne modifie pas le comportement applicatif ; elle réduit uniquement la visibilité externe des informations technologiques. Dans les applications legacy, cette étape simple peut réduire de manière significative les fuites d'informations.
Les politiques CSP et de frame peuvent affecter certains composants applicatifs. Les pages utilisant des scripts inline ou chargeant du contenu depuis des sources externes en particulier doivent être validées d'abord dans un environnement de test. L'approche basée sur les règles de TR7 permet d'expérimenter facilement une politique stricte sur un chemin ou domaine limité avant de la déployer largement.
Les équipes e-commerce peuvent activer CSP, HSTS et le nettoyage des empreintes serveur au niveau du vService sur les pages de paiement. Cette configuration produit des preuves techniques reportables pour les contrôles de sécurité côté client de PCI DSS 4.0 v4.0.1.
Les portails bancaires peuvent utiliser X-Frame-Options SAMEORIGIN et Permission-Policy pour restreindre l'intégration iframe non autorisée et l'accès inutile aux API du navigateur. La surface d'attaque côté client sur les pages de connexion et de transaction est réduite.
Les applications du secteur public peuvent appliquer Referrer-Policy sur les pages portant des informations URL sensibles. Cela réduit le risque que des fragments d'URL liés aux sessions des citoyens ou au contexte des transactions soient transmis aux sites externes.
Dans les anciennes applications .NET ou similaires, les en-têtes Server, X-Powered-By et de version de framework peuvent fuiter vers l'extérieur. TR7 supprime ces en-têtes, rendant plus difficile pour les attaquants de construire un inventaire technologique.
Les fournisseurs SaaS peuvent appliquer différentes combinaisons de securityHeaders pour chaque vService tenant. Les tenants B2B peuvent exécuter une politique plus permissive là où les exigences de conformité le permettent ; les flux B2C peuvent utiliser un ensemble d'en-têtes plus strict.
CSP, HSTS, protection contre le clickjacking et nettoyage des empreintes serveur — depuis une seule politique, sans toucher au code applicatif. Laissez-nous vous présenter une configuration en direct sur vos propres services.