# how to detect typosquatting in npm packages

## TL;DR
Before installing an unfamiliar package, check its download counts, maintainer history, and publish dates on the npm registry page, and compare the name character by character against the package you actually want. Add a lockfile review step and a scanner like Socket in CI so suspicious new dependencies get flagged before they merge. Most typosquats are caught by "this package is 3 days old with 12 downloads and no repo link".

## The query
```text
how to detect typosquatting in npm packages
```

## Use this when
- you are about to install a package you found via search or an AI suggestion
- someone asks "is this npm package legit" or reports a suspicious dependency
- you are reviewing a PR that adds new dependencies
- you want automated typosquat detection in CI

## Not for this skill when
- the package is already installed and you suspect compromise (audit and rotate, different workflow)
- you are vetting Python or Go packages (same ideas, different registries and tools)
- you need license compliance review (related but separate)

## Steps
1. Open the package page on the npm registry and check the basics: weekly downloads, first publish date, number of versions, and whether a repository link exists.
   Expected output: you can say "published 2 days ago, 40 downloads, no repo" or "10 years old, 20M weekly downloads, linked org repo".
2. Compare the name letter by letter with the package you intended (`loadsh` vs `lodash`, `react-dom` vs `react-domx`).
   Expected output: you either confirm an exact match or spot the typo.
3. Inspect the maintainer: click through to their profile and look for history across other packages versus a brand-new account with one package.
   Expected output: a maintainer story that is either established or brand new.
4. Check the tarball contents before installing: `npm view [package] dist.tarball` gives the URL, download it, and list the files. Look for install scripts doing network calls or obfuscated code in a package that should be simple.
   Expected output: a file list with nothing surprising for the package's stated purpose.
5. Add Socket (or your org's scanner) to CI so every new dependency in a lockfile diff gets a risk score.
   Expected output: PRs adding fresh, low-reputation packages get an automated comment or block.
6. Make lockfile review mandatory: `npm ci` in CI, and require human review of lockfile diffs the same way you review code diffs.
   Expected output: no dependency lands without a recorded review.

### Variant: catching it after install
Run `npm audit` and check for packages with install scripts you did not expect. If something looks wrong, remove it, rotate any credentials on that machine, and reinstall from a clean lockfile.

### Variant: scoped packages
Prefer `@org/package` scopes from orgs you trust. Scopes are harder to typosquat convincingly, though not impossible.

### Variant: private registries
Proxy the public registry through an artifact manager with an allowlist of approved packages. New packages require explicit approval before anyone can install them.

## Why this happens
npm has millions of packages and no human reviews names at publish time, so attackers register names one letter off from popular libraries. Install scripts run automatically on `npm install`, which turns a typo into code execution on the developer's machine.

## Edge cases and pitfalls
- Legit forks and renames exist. A new package from a known maintainer with a clear README is different from an anonymous 2-day-old copy.
- Download counts can be gamed upward. Combine signals instead of trusting one.
- `npm audit` covers known CVEs, not typosquats. You need the reputation signals too.
- AI coding assistants sometimes invent package names. Treat every suggested install as untrusted until you check the registry page.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sHwawmO-3WNISKv3DlpodQ