Skip to content

JavaScript Tutorial JavaScript Security Basics

Third-Party Scripts and Dependencies

Lesson 233 of 258 3 min read By Deepak Paswan Updated Oct 4, 2026

Most sites include code they did not write: analytics, chat widgets, ad scripts, fonts, tag managers, and dozens of npm packages. Every third-party script runs with the same power as your own code. It can read the page, including form fields, and send data anywhere.

The risks

  • A compromised provider. If their server or build is attacked, the bad code reaches your visitors.
  • Over-collection. A tracking script may gather more data than you or your visitors expect (and creates privacy law obligations).
  • Performance. Third-party scripts are a common cause of slow pages (Performance).
  • Supply-chain attacks. A malicious or hijacked npm package, or a dependency of a dependency, gets into your build.
  • Abandoned code with known bugs.

Good habits

1. Add fewer. For every script ask: “Do we really need this? Can I do it myself in 10 lines?”

2. Load from trusted sources, and prefer self-hosting stable libraries you control.

3. Subresource Integrity (SRI). For a script loaded from a CDN, the integrity attribute makes the browser check that the file matches a known hash and refuse it if someone changed it.

index.html
HTML
<script src="https://cdn.example.com/lib.min.js"
        integrity="sha384-...hash..."
        crossorigin="anonymous"></script>

The hash comes from the provider or a tool. SRI only works for files that never change, so pin a specific version.

4. Use a Content Security Policy (CSP) to list which domains may serve scripts, so an unexpected script cannot load.

5. Isolate risky widgets in an <iframe> with the sandbox attribute where possible. (The Try it editors in this course use a sandboxed iframe exactly for this reason.)

6. Load them late. async/defer, or after user consent and interaction, so they do not delay your content.

7. Review and audit. Check what each script does in the Network panel. Remove the ones you no longer use.

npm and your dependencies

terminal
BASH
npm audit          # lists known vulnerabilities in your dependencies
npm outdated       # shows packages with newer versions
  • Keep a lockfile (package-lock.json) committed, so installs are repeatable.
  • Update regularly, and read the changelog for big upgrades.
  • Be careful with very new, tiny or oddly named packages, and watch for names that are one letter away from a popular package (“typosquatting”).
  • Prefer well-maintained packages with many users and active maintainers.
  • Avoid installing a package for something the platform already does (many small utility packages are now built in).
  • Never run install scripts or code you do not understand from random sources.

Scripts that track visitors may need user consent depending on your region and the laws that apply to you. Load them only after permission where required, and tell visitors what you collect.

Keep it proportionate

A small personal site with one trusted analytics script has a very different risk profile from a shop handling payments. Match your care to what is at stake, and always protect pages that handle logins or payments from unnecessary third-party code.

lightbulb
A fast check
Open the Network panel on your own site, filter by “JS”, and look at every domain that is not yours. For each one, can you say why it is there?