Topic starter
02/08/2026 12:19 pm
TL;DR: JWT mistakes in Node.js still center on hardcoded secrets, weak verification, and sensitive data exposure, with Semgrep attributing that pattern to governance failures around secrets, verification, and token content. JWT handling needs tighter credential control so signed tokens are not treated as trusted input before they are checked.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Hardcoded secrets, unverified tokens, and other common JWT mistakes”.
Key questions
Q: Why does allowing the none algorithm create token abuse risk?
A: Allowing none removes the cryptographic assurance that makes JWTs trustworthy in the first place.
Q: What do security teams get wrong about JWT verification order?
A: The most common mistake is consuming decoded claims before the token has been verified.
Q: What breaks when JWT secrets are hardcoded in Node.js apps?
A: Hardcoded JWT secrets collapse the boundary between source code and signing authority.
Practitioner guidance
- Remove JWT secrets from source code Move signing and verification secrets into external secret storage or environment-managed injection, and block merges that contain credential literals in application code.
- Enforce strict token verification order Require explicit algorithm allowlists and reject any code path that reads claims before cryptographic verification succeeds.
- Minimise JWT payload content Sign only the claims required for the trust decision and keep sensitive attributes, ORM fields, and internal identifiers out of the token.
Bottom line: JWT misuse in Node.js is usually caused by governance failures around secrets, verification, and token content, not by the JWT standard itself.
Glossary terms: JWT Secret, Token verification, JWT Claim Minimisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:20 pm
JWT problems in Node.js are really identity-governance problems in application code. The article shows that security breaks when secrets, signing rules, and claims handling are treated as implementation details instead of governed trust boundaries. That is the same pattern we see in broader credential misuse: once the secret or token becomes ambient code, the identity control has already failed. Practitioners should treat JWT issuance and verification as part of access governance, not just app logic.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations prevent sensitive data from leaking into JWTs?
A: They should define a minimal claim set and prohibit direct signing of whole user objects or ORM records. JWT payloads are often copied into logs, browser storage, or downstream services, so any unnecessary field becomes a disclosure risk. Classify claims like other identity data, and keep sensitive attributes outside the token unless there is a specific, validated need.
👉 Read our full editorial: JWT misuse in Node.js exposes secrets, validation gaps, and token abuse