Skip to main content
Application Security Standards
Category: Software Supply Chain

Typosquatting

Also known as: URL hijacking, sting site, cousin domain, fake URL
Simply put

Typosquatting is when someone registers a domain name or package name that is a common misspelling or lookalike version of a legitimate one, hoping to capture traffic or installations intended for the real target. This technique is often used by criminals to deceive users into visiting fraudulent websites or installing malicious software packages. It is a form of cybersquatting that exploits simple typographical errors made by users.

Formal definition

Typosquatting is a deception technique in which an adversary registers domain names, package names, or other identifiers that are visually or typographically similar to legitimate ones, typically through character substitution, omission, transposition, or addition. In the context of application security and software supply chains, typosquatting commonly targets package registries (such as npm, PyPI, or RubyGems) where attackers publish malicious packages with names resembling popular libraries, aiming to exploit developer mistakes during dependency installation. In the domain name context, it involves registering misspelled or lookalike domains to intercept web traffic intended for legitimate organizations. Detection of typosquatting in package ecosystems typically relies on name-similarity analysis and behavioral heuristics, though false negatives may occur when attackers use subtle character variations or target less popular packages with limited monitoring. False positives can arise when legitimate packages have naturally similar names.

Why it matters

Typosquatting poses a significant threat to both end users and software development organizations because it exploits one of the most difficult vulnerabilities to eliminate: human error. A single typographical mistake when entering a URL or specifying a dependency in a project manifest can redirect a user to a fraudulent website or pull a malicious package into a software build. In the domain name context, attackers use typosquatted domains to host phishing pages, distribute malware, or harvest credentials. In the software supply chain context, malicious packages uploaded to public registries such as npm, PyPI, or RubyGems can execute arbitrary code during installation, potentially compromising developer workstations, CI/CD pipelines, and production environments.

The challenge is compounded by the scale of modern software ecosystems. Organizations typically depend on hundreds or thousands of open-source packages, and a single misspelled package name in a configuration file may go unnoticed during code review. Because typosquatting exploits the trust developers place in package registries and the speed at which dependencies are resolved, it can bypass many traditional security controls that focus on known vulnerabilities rather than deceptive naming. Detection mechanisms that rely on name-similarity analysis and behavioral heuristics help, but they face inherent limitations: subtle character variations (such as substituting visually similar Unicode characters) may evade detection, and legitimate packages with naturally similar names can trigger false positives.

Who it's relevant to

Software Developers and DevOps Engineers
Developers who install open-source packages from public registries are directly exposed to typosquatting attacks. A simple typo in a dependency declaration can introduce malicious code into a project. DevOps engineers managing CI/CD pipelines face similar risks, as automated build systems resolve and install dependencies without manual review of each package name.
Application Security Teams
Security teams responsible for securing the software supply chain need to implement controls that detect or prevent typosquatted dependencies from entering codebases. This includes integrating name-similarity analysis tools, maintaining allowlists of approved packages, and monitoring dependency manifests for unexpected changes.
Brand and Domain Owners
Organizations with well-known brand names or popular open-source projects are frequent targets of typosquatting. Proactively registering common misspellings of owned domains, monitoring package registries for lookalike package names, and pursuing takedown actions are important defensive measures for these stakeholders.
End Users and Non-Technical Staff
Individuals who type URLs directly into browsers are susceptible to landing on typosquatted domains that host phishing pages, credential harvesting forms, or malware distribution sites. Security awareness training that highlights this risk can help reduce the likelihood of successful attacks.
Legal and Compliance Professionals
Typosquatting intersects with cybersquatting laws and intellectual property protections. Legal teams may need to pursue domain dispute resolution processes (such as those under the Uniform Domain-Name Dispute-Resolution Policy) or coordinate with package registry operators to take down infringing or malicious registrations.

Inside Typosquatting

Name Similarity Exploitation
The core technique of registering package names that closely resemble legitimate, popular packages by introducing common typographical errors such as character transpositions, omissions, additions, or substitutions (e.g., 'reqeusts' instead of 'requests').
Malicious Payload Delivery
Typosquatted packages typically contain malicious code that may execute during installation (via install hooks) or at runtime, potentially exfiltrating credentials, injecting backdoors, or downloading additional malware.
Package Registry Targeting
Typosquatting attacks target public package registries such as npm, PyPI, RubyGems, and other ecosystem repositories where developers install dependencies by name, often without manual verification of the package source.
Social Engineering Component
The attack relies on human error, exploiting the likelihood that developers will mistype a package name during installation or copy an incorrect name from unofficial documentation, forums, or AI-generated code suggestions.
Dependency Confusion Overlap
Typosquatting is a subset of the broader category of software supply chain attacks and may overlap with dependency confusion techniques, where attackers exploit namespace resolution behavior across public and private registries.

Common questions

Answers to the questions practitioners most commonly ask about Typosquatting.

Does typosquatting only affect careless or inexperienced developers?
No. Typosquatting attacks are designed to exploit normal human error, and even experienced developers can fall victim, particularly when working under time pressure, copying package names from unofficial sources, or dealing with ecosystems containing hundreds of thousands of similarly named packages. The attack succeeds because it targets predictable patterns of typographical mistakes, not developer skill level.
Can package managers and registries fully prevent typosquatting through naming rules?
Package registries can reduce the attack surface through measures such as name similarity checks and reserved namespaces, but they cannot fully eliminate typosquatting. Attackers continuously adapt by finding names that pass automated checks while remaining plausible to human readers. Registry-level defenses are one layer, but organizations still need additional controls such as dependency allow-lists and lockfile verification.
How can development teams detect typosquatted packages in their existing dependency trees?
Teams can use software composition analysis (SCA) tools that include typosquatting detection heuristics, compare installed dependencies against curated allow-lists, and review lockfiles for unexpected package name changes. Some tools specifically analyze package names for edit-distance similarity to popular packages. However, detection is typically heuristic-based and may produce false positives for legitimately similar names or false negatives for packages that use creative misspellings outside the tool's pattern set.
What policies should organizations implement to reduce the risk of typosquatting in their software supply chain?
Effective policies include maintaining a curated allow-list of approved packages, requiring lockfile review as part of code review processes, using private registries or registry proxies that restrict which packages can be pulled, enforcing hash verification of dependencies, and mandating SCA scanning in CI/CD pipelines. Organizations should also consider scoping policies by ecosystem, since some registries (such as npm and PyPI) are more commonly targeted than others.
How should a team respond if they discover a typosquatted package has been installed in a project?
The team should immediately remove the package and pin the correct dependency in the lockfile. They should then assess the scope of exposure by reviewing what the malicious package could have accessed, including environment variables, credentials, and network endpoints. Build artifacts produced while the package was present should be treated as potentially compromised. The incident should be reported to the relevant package registry so the typosquatted package can be removed, and any exposed secrets should be rotated.
Are there differences in typosquatting risk across package ecosystems like npm, PyPI, and RubyGems?
Yes. Ecosystems with larger package counts, permissive naming policies, and minimal publication barriers typically present higher typosquatting risk. npm and PyPI are frequently cited as common targets due to their size and open registration models. Some ecosystems have introduced mitigations such as name normalization or similarity checks, but the effectiveness of these measures varies. Teams should evaluate the specific registry controls available in each ecosystem they depend on and adjust their defensive measures accordingly.

Common misconceptions

Typosquatting only affects careless or inexperienced developers.
Even experienced developers are susceptible, particularly when working quickly, using copy-paste from untrusted sources, or when AI code assistants suggest incorrect package names. The attack exploits normal human error rates rather than a lack of expertise.
Package registries effectively prevent typosquatting by blocking similar names.
While some registries have implemented detection heuristics or naming rules, these measures are not comprehensive. Attackers continuously adapt naming strategies, and registries typically cannot block all plausible misspellings without also restricting legitimate package creation. Detection is reactive in most cases.
Static analysis or SCA tools reliably catch all typosquatted packages before they cause harm.
Software Composition Analysis tools can flag known malicious packages from curated databases, but they may produce false negatives for newly published typosquatted packages that have not yet been reported. Detection depends on threat intelligence freshness, and novel typosquatting variants may evade heuristic-based checks.

Best practices

Use lockfiles (e.g., package-lock.json, Pipfile.lock, yarn.lock) and verify their integrity in CI/CD pipelines to ensure that only explicitly approved package versions and names are installed.
Integrate Software Composition Analysis tools with regularly updated vulnerability and malicious package databases into your development workflow, recognizing that newly published typosquatted packages may not be immediately detected.
Configure private or curated package registries that act as proxies, allowing only vetted packages to be resolved, which reduces direct exposure to public registry typosquatting attacks.
Verify package names, publishers, download counts, and repository links before adding new dependencies, particularly when sourcing package names from forums, AI-generated suggestions, or unofficial documentation.
Enable namespace or scope restrictions where supported by the registry (e.g., npm scoped packages) to reduce ambiguity and limit the attack surface for name impersonation.
Conduct periodic audits of project dependency manifests to identify unexpected or recently added packages that do not match known, trusted libraries.