Skip to main content
Tous les termes Glossary

Script propriétaire

Definition

Les scripts propriétaires sont des éléments JavaScript fournis directement à partir du domaine d'un site Web. Ils sont généralement contrôlés par l'équipe de développement de ce site, ce qui facilite leur audit et leur gestion. Comme le site lui-même les héberge, les administrateurs peuvent utiliser des revues de code internes, le contrôle de version et des en-têtes de sécurité stricts (tels que la politique de sécurité du contenu) pour réduire les vulnérabilités. Cependant, même les scripts propriétaires peuvent contenir des failles de sécurité dues à des chaînes de dépendance, qui sont généralement compilées via un gestionnaire de paquets. Dans un contexte de sécurité côté client, il est essentiel de vérifier et de mettre à jour correctement le code propriétaire pour se défendre contre des attaques telles que le cross-site scripting (XSS) et l'exfiltration de données.

Ce que sont les scripts first-party

Un script first-party est du JavaScript servi depuis le propre domaine d'un site et, en principe, contrôlé par la propre équipe de ce site. Parce que l'organisation héberge et livre le code, elle peut appliquer toute la palette de contrôles internes : revue du code source, gestion de versions, chaîne de build et en-têtes de sécurité comme la Content Security Policy. Les scripts first-party gèrent le comportement central d'un site, les formulaires, l'interactivité et la logique applicative, et constituent généralement le code auquel une équipe fait le plus confiance. En pratique, cependant, la plupart des bundles first-party sont assemblés à partir de paquets open source récupérés via un gestionnaire de paquets, si bien que le code effectivement livré inclut de nombreuses dépendances que l'équipe n'a pas écrites elle-même.

Pourquoi les scripts first-party comportent tout de même un risque

Digne de confiance ne veut pas dire sûr. Un script first-party hérite de chaque vulnérabilité de son arbre de dépendances, de sorte qu'un paquet npm compromis ou malveillant devient du code first-party au moment du build, un chemin de la chaîne d'approvisionnement logicielle à l'origine de plusieurs incidents réels. Le code first-party est aussi un point de destination fréquent pour le XSS : s'il insère une entrée non fiable dans le DOM ou évalue des chaînes dynamiques, il offre aux attaquants une exécution sous la propre origine du site. Et sur une page de paiement, le navigateur ne peut pas distinguer le first-party du third-party, les deux s'exécutent avec le même accès aux champs de formulaire et aux cookies, si bien qu'une faille dans le code first-party expose exactement les données que convoite un attaquant.

Sécuriser les scripts first-party

Contrôlez les dépendances avec des fichiers de verrouillage, des audits et des versions épinglées, révisez et encodez tout code qui écrit dans le DOM, et utilisez une CSP stricte pour qu'un script injecté ait une portée limitée. La Subresource Integrity protège le code que vous chargez depuis un CDN. Pour la conformité, PCI DSS 6.4.3 exige un inventaire et une autorisation de chaque script présent sur les pages de paiement, first-party compris, et 11.6.1 exige de détecter les modifications non autorisées qui leur sont apportées. cside surveille les scripts qui s'exécutent réellement dans le navigateur et analyse leur comportement, de sorte qu'un bundle first-party qui se met à lire des champs de carte ou à contacter un domaine inconnu, que ce soit via une dépendance empoisonnée ou une injection, est signalé, peut être bloqué en temps réel et est enregistré à des fins forensiques.

Définition

Les scripts first-party sont-ils plus sûrs que les scripts third-party ?

En général oui, parce que vous maîtrisez la source, l'hébergement et le processus de publication, mais pas automatiquement. Les bundles first-party incluent habituellement des dépendances third-party récupérées auprès de gestionnaires de paquets, de sorte qu'ils héritent du risque de chaîne d'approvisionnement. L'avantage réside dans le contrôle et l'auditabilité, non dans une immunité intrinsèque face à la compromission ou aux vulnérabilités.

Définition

PCI DSS traite-t-il les scripts first-party différemment des scripts third-party ?

Non. Les exigences 6.4.3 et 11.6.1 s'appliquent à chaque script qui s'exécute sur une page de paiement, quelle que soit son origine. Vous devez inventorier et justifier chacun d'eux, first-party compris, et être en mesure de détecter les modifications non autorisées qui leur sont apportées, car le navigateur leur donne à tous le même accès aux champs sensibles.

Got more questions

Talk to a security expert

We answer client-side security questions every day. Bring yours.

Réserver une démonstration

Envie de passer tout ça en revue avec un ingénieur ?

Trente minutes, sur votre propre site. Pas de slides.

Nous vous montrerons :

Quels scripts tiers s'exécutent actuellement sur votre site
Où vous en êtes sur les exigences PCI DSS 6.4.3 et 11.6.1
Quelle part de votre trafic provient de bots et d'agents IA

Vous préférez simplement poser une question ?

Recherche de créneaux…

Humains uniquement. On le saurait.

Un problème pour réserver ? Ouvrir le calendrier dans un nouvel onglet

Quel problème cherchez-vous à résoudre ?

Dites-le-nous en une ligne et nous reviendrons vers vous avec quelque chose d'utile, pas un discours générique.

Nous aidons souvent sur :

Voir quels scripts tiers s'exécutent sur votre site
Les preuves pour PCI DSS 6.4.3 et 11.6.1
Les bots, les agents IA et le vol de comptes

Vous préférez réserver un créneau ? Choisir un créneau