Two supply-chain attacks target the moment you add a dependency, and both can slip malicious code into a mobile app's build. Typosquatting relies on a mistyped or look-alike package name, so you install the attacker's package instead of the one you meant. Dependency confusion exploits how build tools resolve names, tricking them into pulling a malicious public package in place of your private one. Neither requires breaking into your systems; they exploit the package-management step you do routinely. Here is how each attack works, how it reaches mobile apps, and how to defend against them.
Short answer
Dependency confusion and typosquatting are supply-chain attacks on the packages your app depends on. Per OWASP, typosquatting is when an attacker publishes a malicious package with a name similar to a popular one, hoping you install it by mistake, and dependency confusion is when an attacker publishes a public package with the same name as your private internal one, so the build tool fetches the malicious public version instead. Both can inject malicious code into your mobile build through your package manager. Defend by verifying package names, using lockfiles to pin versions and integrity, scoping or namespacing internal packages, configuring registries so private names are not resolved publicly, and reviewing new dependencies.
What you should know
- Typosquatting uses look-alike names: a mistyped package is the attacker's.
- Dependency confusion abuses name resolution: a public package shadows your private one.
- Both inject code into your build: through the package manager.
- Lockfiles and verification help: pin versions and integrity.
- Scope internal packages: so private names cannot be confused publicly.
How do dependency confusion and typosquatting differ?
They exploit different weaknesses in dependency resolution. The table contrasts them.
| Attack | How it works |
|---|---|
| Typosquatting | A malicious package is named like a popular one, installed by a typo or look-alike |
| Dependency confusion | A public package matches your private package's name and is fetched instead |
| Shared outcome | Malicious code runs in your build and ships in your app |
| Shared cause | The package manager resolves to the attacker's package |
Typosquatting targets human error: an attacker registers a package whose name closely resembles a widely used one, betting that someone mistypes it or copies a wrong reference, and installs the malicious package. Dependency confusion targets tooling behavior: if your build uses a private package name that also exists publicly, some package managers will prefer the public one, especially a higher version, so an attacker who publishes a public package with your internal name can get it pulled into your build. Different mechanisms, but the same result, attacker code in your dependencies, and the same root, the package manager resolving to something you did not intend.
How do these attacks reach mobile apps?
Through the package managers mobile development relies on. Mobile apps pull dependencies through tools like npm for React Native, CocoaPods or Swift Package Manager for iOS, and Gradle or Maven for Android, and each of these resolves names and versions from registries. Typosquatting reaches you when a package is added with a wrong or look-alike name, directly or as a transitive dependency, and dependency confusion reaches you when a build resolves a private name to a malicious public package. In both cases, the malicious package can run code during the build or ship inside your app, gaining whatever access your build or app has. Because these attacks operate at the dependency layer, they bypass your own code entirely, which is why they are a supply-chain risk rather than a flaw you would find by reviewing what you wrote.
How do you defend against them?
Control how dependencies are named, resolved, and verified. Verify the exact name of any package before adding it, since a look-alike is easy to miss, and prefer well-established packages from sources you trust. Use lockfiles to pin exact versions and verify integrity, so a dependency cannot silently change to a malicious one, and review changes to your dependency set. For internal packages, scope or namespace them and configure your package manager and registry so private names are resolved only from your private source, never silently from a public registry, which is the specific defense against dependency confusion. Minimize the number of dependencies you take on, since each is a trust decision, and monitor for unexpected packages. The throughline is to make dependency resolution deterministic and verified, so the package manager cannot be tricked into pulling the attacker's package.
What to watch out for
The first trap is adding a package without checking its exact name, which is how a typosquatted look-alike gets in. The second is using internal package names that could exist publicly without configuring your tooling to resolve them privately, which is the dependency-confusion opening. The third is not pinning versions and integrity, so a dependency can change under you. These attacks ship in the build, so a pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and inventories the components actually present, which helps you spot an unexpected or unfamiliar package that ended up in your app. The resolution and verification controls you set in your build configuration.
What to take away
- Typosquatting installs a malicious package with a look-alike name, and dependency confusion fetches a malicious public package in place of your private one.
- Both inject attacker code into your mobile build through the package manager, bypassing your own code, which makes them supply-chain risks.
- Defend by verifying package names, pinning versions and integrity with lockfiles, scoping internal packages, configuring private resolution, and reviewing dependencies.
- Use a pre-submission scan such as PTKD.com to inventory the components actually in your build and spot an unexpected package before you ship.
