Typosquatting
Typosquatting registers package or domain names that look like popular ones, tricking developers into installing malware through a single mistyped character.
Definition
Typosquatting is an attack that exploits human error in naming by publishing malicious packages, domains, or repositories with names visually or typographically similar to legitimate ones, such as a transposed letter or a homoglyph.
Context and scope
Use this concept when hardening developer workstations and CI against malicious installs, and when deciding how much name verification a dependency workflow needs.
Common misconceptions
- Lockfiles prevent typosquatting; the first install is exactly when the typo happens
- Only beginners mistype names; copy-paste from untrusted sources is a bigger vector
- Package registries remove malicious packages quickly enough to contain the damage
Anti-patterns
- Installing packages by typing names from memory without checking the publisher
- Allowing install scripts by default across all dependencies
- Approving dependencies by name alone without verifying repository and provenance
Related concepts
Related examples
Authoritative source
A single character is enough
Typosquatting targets the gap between a name a developer intends and the name they type or paste. reqeusts for requests, lodahs for lodash, or a Cyrillic character that renders like Latin script all resolve to a real package controlled by an attacker. The payload often runs at install time, before any test can catch it.
How it works
The attacker registers a name close to a popular package and publishes a version that looks plausible. The package may include a postinstall script that reads environment variables, SSH keys, or CI tokens and sends them out. Some variants wait for a specific hostname or cloud metadata endpoint to avoid sandbox detection. Others add a dependency on the real package so the application still works.
Defenses are mostly procedural: install from a lockfile with npm ci, disable install scripts where possible, verify publisher identity and repository links, and route new dependencies through review. Registries deploy name-similarity detection, but it is advisory and lags new attacks.
When to use it
Apply these checks for every new dependency, in local development and CI. The risk is highest in scripts that run with credentials, such as deployment jobs and developer laptops with cloud sessions. Vendored dependencies and internal mirrors reduce exposure but need curation.
Trade-offs
Disabling install scripts breaks packages that legitimately compile native modules, so teams often allowlist specific ones. Reviewing every dependency slows delivery. Private mirrors add a control point but require maintenance and can lag security updates. Perfect name verification is impossible; defense relies on layers.
Example and misconceptions
A developer follows a tutorial that says npm install crossenv, a typo of cross-env. The malicious package’s postinstall script reads npm_config_* environment variables and posts them to an external server. The app still builds, so nobody notices.
The common misconception is that experienced developers do not fall for this. Copy-paste from blog posts and AI-generated commands makes the typo invisible, regardless of experience.
Related concepts: Dependency Confusion, Supply Chain Security, and Dependency Pinning.