Risque du script

Ouvrez un script dans Scripts, puis sélectionnez Script Risk, à côté de Insights, Served Hashes, Seen Pages et Script History. Cet onglet présente les ressources que cside a vu le script charger et les données de page auxquelles il a accédé.

Score de risque

0 signifie un risque plus faible. 100 signifie un risque plus élevé. Utilisez le score pour prioriser les scripts à examiner. Il ne représente pas une probabilité de compromission : un score de 45 ne signifie pas un risque d’attaque de 45 %. Des scripts légitimes de paiement ou d’authentification peuvent avoir un score plus élevé parce qu’ils accèdent à des données sensibles. Un score faible ne garantit pas la sécurité.

Trouver et trier les scores

Dans la liste Scripts d’un domaine ou de tous les domaines, utilisez la colonne Risk score et triez par risque connu, du plus élevé au plus faible ou inversement. Les scripts sans évaluation apparaissent en dernier dans les deux cas. Sélectionnez un score pour ouvrir son explication dans Script Risk.

Une ligne regroupée affiche le score ou le minimum connu le plus élevé parmi ses URL. La sélectionner ouvre le script qui contribue à cette valeur. Si un membre n’a pas d’évaluation ou présente des données incomplètes, le groupe reste incomplet.

Comprendre les états du score

Ce que vous voyez	Ce que cela signifie
Un nombre sur 100 avec Low risk, Medium risk ou High risk	L’évaluation dispose d’un score numérique. Plus le nombre est élevé, plus le risque est élevé.
Insufficient data et At least N/100	Les données disponibles établissent un minimum. Les données manquantes empêchent d’obtenir un score complet.
Pending	Aucune évaluation n’a été enregistrée pour ce script sur la période d’évaluation actuelle. Cela ne signifie pas un risque nul.
Unavailable	cside n’a pas pu charger l’évaluation. Cela ne signifie pas un risque nul.
Stale	La période couverte par les données n’est plus actuelle. Le score ou le minimum affiché décrit toujours cette période antérieure.

Par exemple, At least 45/100 signifie que les données connues établissent déjà un score de risque d’au moins 45. Le score complet peut être plus élevé. Cela ne signifie pas que 45 % des données ont été collectées.

Une évaluation peut afficher 100/100 tout en indiquant que les données sont incomplètes : les données connues atteignent déjà le maximum, donc les données manquantes ne peuvent pas augmenter davantage le score.

Ce qui contribue au score

L’explication distingue six facteurs de comportement :

• Accès aux champs de formulaire : la catégorie de champ la plus sensible observée, comme les données personnelles, les identifiants ou les données de paiement.
• API sensibles du navigateur : les indices d’utilisation de la caméra, du microphone, de la localisation ou du presse-papiers. Une tentative d’appel observée ne prouve pas qu’une autorisation a été accordée ni que des données ont été renvoyées.
• Ressources chargées : les destinations distinctes utilisées pour les ressources actives et passives.
• Iframes : les indices de cadres intégrés, y compris leur relation d’origine lorsqu’elle est connue.
• Modifications du contenu : les révisions distinctes du contenu du script sur la période d’évaluation.
• Première observation : le temps écoulé entre la première observation du script par cside et la fin de cette période.

Les résultats de sécurité peuvent établir un score minimum. Le résultat retient la valeur la plus élevée entre le total des facteurs de comportement et le minimum de sécurité applicable le plus élevé ; ces valeurs ne s’additionnent pas. Les résultats non résolus restent visibles. Cet aperçu vous aide à examiner les scripts et ne modifie ni les alertes ni les règles de blocage.

Pourquoi des données peuvent manquer

L’aperçu ne vérifie pas encore que la surveillance du navigateur et les contrôles de sécurité couvrent entièrement chaque révision du script. Vous pouvez donc voir Insufficient data même lorsque cside a correctement enregistré des observations. L’absence d’activité enregistrée ne suffit pas à prouver qu’il ne s’est rien passé.

D’autres lacunes incluent un historique des révisions incomplet, un historique conservé trop court pour établir la première observation du script, une collecte indisponible ou un échec de lecture des données. Chaque facteur explique les données manquantes. Ces lacunes ne sont pas traitées comme un risque nul, et actualiser la page ne les comble pas. Contactez cside si les évaluations restent Pending ou si une source demeure indisponible.

Période d’évaluation et durée depuis la première observation

Les scores couvrent sept jours UTC complets, sans inclure le jour actuel. Un script observé pour la première fois aujourd’hui peut rester Pending jusqu’à ce qu’une évaluation ultérieure l’inclue. Les filtres de dates et de révisions ne modifient pas cette période fixe, y compris le sélecteur de dates des tableaux de comportement ci-dessous.

L’explication affiche la période réelle et l’heure du calcul dans votre fuseau horaire local. La durée depuis la première observation est exprimée en jours, heures et minutes selon les besoins, par exemple 25 jours et 13 heures au lieu de 613 heures. Elle est mesurée à la fin de la période d’évaluation, pas au moment où vous ouvrez la page.

Comportement observé

Les deux tableaux affichent Permitted, Blocked ou un pourcentage bloqué selon Vendor Permissions, ainsi que la dernière observation. Les lignes de champs indiquent le type et le niveau de risque. Développez-les pour voir les créations, lectures, mises à jour ou suppressions par page. L’absence d’activité enregistrée signifie qu’il n’y a pas d’observation dans cette période, pas que cside a capturé toutes les actions possibles.

Plage de dates

Les deux tableaux de cet onglet partagent un sélecteur de plage de dates ancré sur la dernière date d’observation du script. La plage disponible est bornée par la plus étroite des deux : la fenêtre de rétention de votre offre, ou les dates où cside a réellement observé le script. Demander une plage en dehors de cette fenêtre affiche un message “No recorded behavior in this range” plutôt que des tableaux vides.

Loaded resources

Le tableau loaded resources liste une ligne par hôte et type de ressource que le script a fait charger, par exemple un script chargeant un pixel de suivi depuis un hôte spécifique, ou récupérant des données depuis un endpoint d’API.

Chaque ligne affiche :

• Une case colorée selon le type de ressource : Connect/XHR, Script, Object, Frame, Image, Style, Font, Media, Worker, Manifest ou Prefetch
• Le hôte, avec son favicon et le nom complet du pays quand il est connu
• Si le chargement a été autorisé ou bloqué

Déployez une ligne pour voir les pages où la ressource a été vue, des exemples d’URL, et une carte de localisation estimée construite à partir de là où la ressource a été observée.

Filtrer les loaded resources

Deux groupes de puces se trouvent au-dessus du tableau :

• Enforcement : filtrez les chargements autorisés ou bloqués
• Kind : filtrez sur un type de ressource spécifique, avec un compteur sur chaque puce

Les compteurs de Kind reflètent votre filtre d’enforcement mais pas votre sélection de kind, donc les compteurs restent stables lorsque vous changez de type et ne changent que si vous basculez Allowed ou Blocked.

Accessed fields

Le tableau accessed fields liste les champs de page et les données que le script a lus, par exemple des champs de formulaire ou des valeurs de stockage. Chaque ligne affiche le type du champ, un badge de risque, si l’accès a été autorisé ou bloqué, et un échantillon des pages où il a été vu. Déployez une ligne pour voir l’activité du script sur chaque page individuellement.

Pages associées

• Inventaire des ressources
• Autorisations des fournisseurs
• Détection des menaces
• Détection des vulnérabilités