Vulnerability Detection
Découvrez comment cside détecte les scripts tiers vulnérables sur votre site à l'aide de bases de données de vulnérabilités standard du secteur.
cside automatically scans every third-party script loaded on your site and checks it against known vulnerability databases. When a script with a known vulnerability is detected, we flag it and surface the details in your dashboard so you can take action.
How it works
When a script is loaded on your site, cside follows a three-step process to determine if it contains known vulnerabilities:
1. Extract the library and version
cside identifies the package name and version from the script URL. We support most common CDN and hosting patterns:
| CDN / Pattern | Example URL |
|---|---|
| cdnjs | cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js |
| unpkg | unpkg.com/lodash@4.17.21/lodash.min.js |
| jsDelivr | cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js |
| Version in query param | example.com/lodash.js?v=4.17.21 |
| Version in filename | example.com/lodash-4.17.21.min.js |
For example, given the script URL:
https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js
cside extracts:
- Package:
lodash.js - Version:
4.17.21
2. Check against vulnerability databases
The extracted package and version are checked against multiple industry-standard vulnerability databases that aggregate known security issues from sources like the National Vulnerability Database, GitHub Security Advisories, and the npm registry.
These databases are regularly synced to ensure up-to-date coverage.
3. Match against affected version ranges
Each vulnerability defines one or more affected version ranges. cside checks whether the detected version falls within any affected range. For example, a vulnerability might specify:
- Introduced in:
0.0.0 - Fixed in:
4.17.22
In this case, any version of lodash below 4.17.22 would be flagged -including 4.17.21.
Example: lodash 4.17.21
The script https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js is a real-world example of a script that cside would report as vulnerable.
Lodash 4.17.21 is affected by known vulnerabilities including prototype pollution issues tracked in public CVE records. When cside detects this script on your site, the alert includes:
- Vulnerability ID -The CVE or advisory identifier (e.g.,
CVE-2025-XXXX,GHSA-XXXX) - Severity -The severity level of the vulnerability
- Summary -A short description of the vulnerability
- Source -Which vulnerability database flagged the issue
What we report
When a vulnerable script is detected, cside creates a script alert visible in your dashboard with the following details:
| Field | Description |
|---|---|
| Package | The identified library name (e.g., lodash.js) |
| Version | The detected version (e.g., 4.17.21) |
| Vulnerability ID | The CVE, GHSA, or MAL identifier |
| Severity | The severity rating of the vulnerability |
| Summary | A brief description of the issue |
| Source | Which vulnerability database flagged the issue |
Scripts can have multiple vulnerabilities. cside will report each one individually so you have full visibility into the risk surface of every script on your site.
Types of vulnerabilities detected
cside detects several categories of vulnerable scripts:
- Known CVEs -Scripts with publicly disclosed vulnerabilities in the National Vulnerability Database
- GitHub Security Advisories -Vulnerabilities reported through GitHub’s advisory system (GHSA identifiers)
- Malicious packages -Scripts from npm packages that have been flagged as intentionally malicious (MAL identifiers)
Supported CDNs and URL formats
cside can extract library information from scripts served by any of these patterns:
- unpkg.com -
unpkg.com/@scope/package@version/file.js - jsDelivr -
cdn.jsdelivr.net/npm/package@version/file.js - cdnjs -
cdnjs.cloudflare.com/ajax/libs/package/version/file.js - Query parameters -Any URL with
?v=or?ver=version parameters - Filename versioning -Scripts like
package-1.2.3.min.jsorpackage.1.2.3.js - Path-based versioning -URLs like
/1.2.3/package.js
If a script URL does not contain recognizable version information, cside will not be able to perform a vulnerability check against it. We recommend using versioned CDN URLs for your third-party scripts wherever possible.
Filtrage des notifications de vulnérabilités
Le Noise Filter de Vulnerable Script Detected est activé par défaut et concerne les notifications immédiates de vulnérabilités courantes. Il peut supprimer une notification lorsqu’une forte confiance confirme que le constat ne concerne que du code serveur ou de compilation, inaccessible depuis le navigateur. Les constats restent évalués et visibles dans le tableau de bord, ainsi que dans les résumés quotidiens et hebdomadaires.
Sans verdict disponible, une notification courante peut attendre la vérification. L’attente par défaut est de 30 minutes ; les constats non résolus sont ensuite libérés pour envoi. Il s’agit d’une fenêtre de vérification, pas d’une garantie de délai de livraison. Les constats élevés ou critiques et les malwares utilisent le déclencheur immédiat High-risk Vulnerability et ne sont jamais filtrés par cette option. Désactivez-la pour recevoir tous les constats courants avec la programmation immédiate.
Ouvrir une alerte depuis un e-mail
Les e-mails d’alertes individuelles concernant les scripts vulnérables et les vulnérabilités à haut risque incluent un bouton View alert in cside. Cliquez dessus pour ouvrir l’alerte correspondante dans le tableau de bord et examiner les scripts concernés. L’identifiant ou la référence de la vulnérabilité reste un lien distinct vers OSV ou l’avis d’origine.
Si une notification ne contient pas de lien direct vers l’alerte, le bouton affiche View alerts in cside et ouvre Alerts pour le domaine concerné. Retrouvez l’alerte à l’aide de la recherche par cible et du filtre de statut.
Consultez Résoudre les alertes pour les actions de revue et Notifications pour configurer l’envoi.
Recommended actions
When cside flags a vulnerable script on your site:
- Review the vulnerability details in your dashboard to understand the severity and impact
- Update the script to a patched version if one is available
- Evaluate the risk -determine if the vulnerability is exploitable in your specific usage
- Remove the script if it is no longer maintained or no patched version exists
Thanks for your feedback!