Why `npm audit` Isn't Enough to Secure Your React or Next.js App

If you ship React or Next.js apps, chances are your entire security process is npm audit before a release, maybe a Dependabot badge on the README, and calling it a day.

That covers exactly one category of risk: known CVEs in your dependency tree. It says nothing about the security bugs sitting in your own code — the ones that don't show up in any advisory database because they're specific to how you wrote your app.

What npm audit can't see

A few real examples that npm audit will never flag:

• An API key or private token hardcoded in a component and committed to the repo
• dangerouslySetInnerHTML or eval() used on user-controlled input
• A NEXT_PUBLIC_ environment variable that's quietly leaking a secret meant to stay server-side
• Non-serializable props crossing a Next.js Server/Client Component boundary (a correctness bug that's also a leakage risk)
• window or localStorage accessed outside useEffect, causing hydration mismatches
• .map source map files sitting in public/, exposing your original TypeScript source in production
• A GPL/AGPL-licensed dependency that quietly puts your commercial product's license at risk
• A typosquatted or newly-flagged malicious package that hasn't hit the CVE databases yet

None of this is exotic. Most of it shows up in real production codebases, and none of it is something npm audit was ever designed to catch.

A scanner built for how React/Next.js apps actually break

I built web-secure-verification to cover this gap specifically for React and Next.js projects — not a generic linter, not a CVE database wrapper.

It runs 12 checks in one command:

Check	What it catches
CVE / dependency audit	Known vulnerabilities in installed packages
Outdated / deprecated packages	Packages with safer versions, or ones the maintainer abandoned
Hardcoded secrets	API keys, tokens, private keys, high-entropy strings in source
Code-level security	eval(), innerHTML, dangerouslySetInnerHTML, command injection patterns
Next.js config	Missing security headers, leaked NEXT_PUBLIC_ secrets, insecure image config
License compliance	GPL/AGPL dependencies that can block commercial use
Supply chain	Typosquatted packages, known-malicious packages, shady postinstall scripts
RSC boundary violations	Non-serializable props crossing the server/client boundary
Hydration bugs	window/localStorage in render, new Date() in render
Bundle size	Full lodash/moment imports, heavy components not lazy-loaded
Exposed source maps	.map files leaking original source in public directories

Try it

npm install -D web-secure-verification
npx web-secure-verify scan

You get a color-coded terminal report grouped by severity (Critical → Info), or export it as HTML, JSON, Markdown, or SARIF (for CI/GitHub code scanning):

npx web-secure-verify scan --format sarif --output results.sarif

Where it fits

This isn't a replacement for npm audit, Snyk, or Dependabot — it's meant to run alongside them. Those tools watch your dependency tree; this one watches the code you actually wrote and the Next.js-specific footguns that are easy to miss under deadline pressure.

If you maintain a React or Next.js project, I'd genuinely like feedback — especially on false positives, or checks you think are missing. Repo's here: github.com/pruthvidarji1993/web-secure-verification