External Script Count

This check is informational and does not affect your score (weight 0). It counts distinct third-party domains that serve JavaScript on your primary host. Each external script source is a supply-chain dependency: a compromise at any of those CDNs or services results in attacker code running under your origin's trust. The count is a structural risk indicator, not a vulnerability finding.

How the check works

Per primary host, the check parses the response HTML and counts unique domains in <script src="..."> tags that are NOT same-origin. Bands:

• 0-3 distinct domains: 1.0 (informational pass).
• 4-6 domains: 0.6. Reason: moderate_external_scripts.
• 7-10 domains: 0.3. Reason: high_external_scripts.
• 11+ domains: 0.0. Reason: excessive_external_scripts.

Verdict and score are reported but do not affect the overall RedScore. Reasons appear in evidence as advisory findings.

How the verdict maps to evidence

Verdict reflects the band above. The score is computed and shown in evidence but is not applied. Evidence shows third_party_script_domains (the actual list of detected domains).

Special states

• Not Applicable: response is not HTML (API JSON, redirect-only), or primary serves a default/empty placeholder.
• Degraded: probe data unavailable, or response body not captured.

How to interpret each band

0-3 domains (healthy)

Common pattern: one analytics provider, one tag manager, maybe one chat or support widget. The page does not depend heavily on third-party services. No action needed beyond the usual SRI hardening on those scripts.

4-6 domains (moderate)

Typical for marketing-heavy sites: analytics, ads, A/B testing, conversion tracking, chat, and a CDN. Each is a separate supply-chain dependency. Audit which are still in use:

• Map every external script to a business owner: which team needs it, what does it deliver?
• Identify scripts loaded but unused (legacy A/B test still firing, retired analytics provider's tag still on the page).
• Consolidate where possible: many marketing platforms now route through a single tag manager rather than multiple direct integrations.

7-10 domains (high)

Significant third-party surface area. Each script can read your page, modify the DOM, set cookies under your domain, and exfiltrate user data. The number itself is a meaningful risk signal even before considering individual scripts.

• Run an aggressive audit. Most teams find at least 2-3 scripts that nobody owns or actively uses.
• Move toward a tag manager strategy: a single GTM or similar loads everything else, simplifying ownership and audit.
• Self-host static dependencies (jQuery, fonts, simple libraries) on your own CDN; the external-domain count drops by one per item.

11+ domains (excessive)

The page is a marketplace for third-party scripts. Common on news sites, ad-monetized content, and aggressive marketing pages. Beyond the supply-chain risk, performance suffers (each domain costs a DNS lookup, TLS handshake, request) and user privacy is compromised (each domain can fingerprint visitors).

If your business model depends on this many third-party scripts, consider a structural shift: server-side analytics, first-party-only tracking with consent, ad networks that bundle into a single script tag.

Reduction strategies

• Tag manager consolidation. Loading 8 marketing scripts via Google Tag Manager appears to RedScore as 1 external domain (googletagmanager.com), not 8. Same scripts run; the count drops because the count is by source domain.
• Self-host stable libraries. jQuery, Bootstrap, fonts, charting libraries that do not need a third-party CDN. Add SRI when self-hosting cross-origin or move them to same-origin.
• Remove zombie scripts. Dead A/B test, retired analytics provider, deprecated chat widget. Each kill drops a domain.
• Privacy-friendly analytics. Server-side or first-party analytics (Plausible, Fathom, Pirsch, self-hosted Matomo) eliminate the third-party JS dependency entirely.
• Lazy-load non-critical scripts. Defer or async-load tags that are not needed for first paint. The count does not change but the performance and resilience impact does.
• Audit on a schedule. Add quarterly third-party audit to your security or marketing operations cycle.

Verify

• DevTools → Network → JS filter. Lists every external script load with origin domain.
• View page source: grep for <script src= and tabulate unique hostnames.
• Re-run the RedScore lookup. Domain count updates immediately on the next scan.

Common pitfalls

• Treating informational as no-action. The score is not affected, but supply-chain risk is real. Use this check as the trigger for the SRI fix and a tag-manager consolidation decision.
• Domain count drops without functionality dropping. Tag manager consolidation reduces the count without changing what runs. The count went down, but the supply-chain risk per script is the same; SRI on each script is still the right hardening.
• Double-counting via subdomains. Two scripts from cdn.example.com count as one domain. Two from cdn.example.com and assets.example.com count as two; the check uses exact hostname match.
• Self-hosted scripts on a different subdomain. Hosting on assets.yourdomain.tld may still be flagged as third-party depending on your apex; check whether the domains_observed reflect this. Same-origin policy looks at host:port, not registrable domain.
• Counting CSS-only third-party domains. The check counts script sources only. CSS, fonts, and images are in Resource Domain Count.