Notifications
Clear all
Topic starter
02/08/2026 12:19 pm
TL;DR: A security review of 2,000 npm modules found recurring JWT mistakes in Node.js, including hardcoded secrets, acceptance of the none algorithm, weak token verification, and sensitive data exposure, according to Semgrep research. The pattern shows that JWTs fail when teams treat signed tokens as trusted data instead of tightly governed credentials and inputs.
NHIMG editorial — based on content published by Semgrep: JWT security mistakes in Node.js projects
By the numbers:
- Using static analysis tooling, I examined 2,000 npm modules for security weaknesses and vulnerabilities.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should teams implement JWT verification safely in Node.js applications?
A: Teams should require library-based verification with explicit algorithm allowlists, then block any path that reads claims before verification completes.
Q: Why do hardcoded secrets create such a large security risk?
A: Hardcoded secrets turn source code, build output, and configuration files into credential repositories, which makes exposure easy to repeat and difficult to contain.
Q: What do security teams get wrong about JWT headers?
A: They often treat JWT headers as trusted instructions instead of attacker-controlled data.
Practitioner guidance
- Enforce secret externalisation for JWT signing material Store signing keys in dedicated secret management systems or environment-scoped configuration, and block any repository commit that contains literal JWT secrets or private keys.
- Restrict accepted JWT algorithms by policy Require explicit allowlists for each token verifier and reject any code path that accepts the none algorithm or skips built-in verification functions.
- Minimise JWT claims to non-sensitive assertions Issue tokens with only the fields required for authentication or session correlation, and never pass full ORM objects, passwords, or other sensitive attributes into signing functions.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- Open source Semgrep rules for detecting hardcoded JWT secrets in Node.js code
- Detection patterns for the none algorithm and other unsafe verification shortcuts
- Code examples showing how unverified claims can flow into downstream database and application logic
- Claim-minimisation patterns for avoiding accidental exposure of sensitive data in JWT payloads
👉 Read Semgrep's analysis of common JWT security mistakes in Node.js →
JWT validation and secret handling in Node.js: where teams still fail?
Explore further
02/08/2026 1:20 pm
JWT misuse is fundamentally a governance problem, not a library problem. The article shows that developers still confuse token formatting with trust. A signed JWT only works when secrets are protected, algorithms are constrained, and claims are treated as untrusted input. That maps directly to identity governance: the security outcome depends on lifecycle controls around the credential, not the syntax of the token. Practitioners should treat JWT handling as an access-control design decision, not an implementation detail.
A question worth separating out:
Q: Who is accountable when JWT misuse leads to authentication bypass or data exposure?
A: Accountability usually sits with the application owner, the platform security team, and the engineering team that defines the token policy. JWT controls should be mapped to secure development standards, authentication governance, and secrets management policy. If verification rules are inconsistent across services, ownership needs to be centralised and made auditable.
👉 Read our full editorial: JWT misuse in Node.js exposes secrets, validation gaps, and token abuse
