Skip to main content
How it works
Language

Vulnerability Detection

Descubre cómo cside detecta scripts de terceros vulnerables en tu sitio usando bases de datos de vulnerabilidades estándar del sector.

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 a wide range of common CDN and hosting patterns:

CDN / PatternExample URL
cdnjscdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js
unpkgunpkg.com/lodash@4.17.21/lodash.min.js
jsDelivrcdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js
Version in query paramexample.com/lodash.js?v=4.17.21
Version in filenameexample.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:

FieldDescription
PackageThe identified library name (e.g., lodash.js)
VersionThe detected version (e.g., 4.17.21)
Vulnerability IDThe CVE, GHSA, or MAL identifier
SeverityThe severity rating of the vulnerability
SummaryA brief description of the issue
SourceWhich 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.js or package.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.

Filtrado de notificaciones de vulnerabilidades

El Noise Filter de Vulnerable Script Detected está activado por defecto y afecta a las notificaciones inmediatas de vulnerabilidades rutinarias. Puede omitir notificaciones cuando se confirma con alta confianza que el hallazgo solo afecta al código de servidor o compilación y no es accesible desde el navegador. Los hallazgos siguen puntuados y visibles en el panel, y permanecen en los resúmenes diarios y semanales.

Si aún no hay veredicto, la notificación puede esperar a la verificación. La espera predeterminada es de 30 minutos; después, los hallazgos sin resolver se liberan para su entrega. Es una ventana de verificación, no una garantía de tiempo de entrega. Los hallazgos de gravedad alta o crítica y el malware usan el activador inmediato High-risk Vulnerability y nunca se filtran con esta opción. Desactívala para recibir todos los hallazgos rutinarios con la programación inmediata.

Abrir una alerta desde el correo

Los correos de alertas individuales de scripts vulnerables y vulnerabilidades de alto riesgo incluyen un botón View alert in cside. Haz clic para abrir la alerta correspondiente en el panel y revisar los scripts afectados. El identificador o la referencia de la vulnerabilidad sigue siendo un enlace separado a OSV o al aviso de origen.

Si una notificación no incluye un enlace directo a la alerta, el botón muestra View alerts in cside y abre Alerts para el dominio afectado. Busca allí la alerta usando la búsqueda por objetivo y el filtro de estado.

Consulta Resolver alertas para conocer las acciones de revisión y Notificaciones para configurar el envío.

When cside flags a vulnerable script on your site:

  1. Review the vulnerability details in your dashboard to understand the severity and impact
  2. Update the script to a patched version if one is available
  3. Evaluate the risk -determine if the vulnerability is exploitable in your specific usage
  4. Remove the script if it is no longer maintained or no patched version exists
Was this page helpful?