Skip to main content
How it works
Language

Vulnerability Detection

Ontdek hoe cside kwetsbare third-party scripts op uw site detecteert met behulp van gangbare vulnerability-databases uit de 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.

Meldingen over kwetsbaarheden filteren

Het Noise Filter bij Vulnerable Script Detected staat standaard aan en beïnvloedt directe meldingen van reguliere kwetsbaarheden. Het kan meldingen onderdrukken als met hoge zekerheid is vastgesteld dat een bevinding alleen server- of buildcode betreft en niet vanuit de browser bereikbaar is. Bevindingen blijven beoordeeld en zichtbaar in het dashboard en blijven in dagelijkse en wekelijkse samenvattingen staan.

Zonder beschikbaar oordeel kan een reguliere melding op verificatie wachten. De standaardwachttijd is 30 minuten; onopgeloste bevindingen worden daarna vrijgegeven voor verzending. Dit is een verificatievenster, geen gegarandeerde bezorgtijd. Hoge en kritieke kwetsbaarheden en malware gebruiken de directe trigger High-risk Vulnerability en worden nooit door deze optie gefilterd. Schakel het filter uit om alle reguliere bevindingen via het directe schema te ontvangen.

Een waarschuwing vanuit e-mail openen

E-mails voor individuele waarschuwingen over kwetsbare scripts en kwetsbaarheden met een hoog risico bevatten een knop View alert in cside. Klik erop om de bijbehorende waarschuwing in het dashboard te openen en de getroffen scripts te bekijken. De kwetsbaarheidsidentificatie of referentie blijft een aparte link naar OSV of het oorspronkelijke beveiligingsadvies.

Als een melding geen directe link naar de waarschuwing bevat, heet de knop View alerts in cside en opent deze Alerts voor het getroffen domein. Zoek de waarschuwing daar met de targetzoekfunctie en het statusfilter.

Zie Waarschuwingen oplossen voor beoordelingsacties en Meldingen om de bezorging in te stellen.

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?