JWT misuse in Node.js exposes secrets, validation gaps, and token abuse

At a glance

What this is: This is a static-analysis review of JWT usage in Node.js that found recurring security mistakes in 2,000 npm modules, with hardcoded secrets, weak verification, and token data exposure among the most common issues.

Why it matters: It matters because JWTs often sit inside authentication and session flows, so misusing them can undermine both human IAM controls and NHI-style credential governance where tokens, secrets, and verification boundaries overlap.

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.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Semgrep's analysis of common JWT security mistakes in Node.js

Context

JWT security in Node.js is less about the token format itself and more about the governance decisions around secret storage, verification, and what data is allowed into the token. The article’s primary point is that even a standard designed for secure information exchange becomes risky when developers hardcode signing keys, accept weak algorithms, or move unvalidated token data into downstream logic.

For identity teams, the relevance extends beyond application security. JWTs often act as the bridge between authentication, session state, and downstream authorisation, which means weak handling can weaken IAM assurance and create NHI-like credential exposure when tokens, keys, or automation identities are mishandled. That makes this a practical control problem, not just a code-quality issue.

The examples are typical of how token mistakes appear in real codebases: developers optimise for convenience during development and leave risky assumptions in production. That is a common pattern, not an edge case.

Key questions

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. Verification must happen before the token is trusted by business logic, routing, or database queries. Pair that with secret storage outside source code so the signing key is not exposed through repositories or build artifacts.

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. Once a secret is copied into multiple systems, revocation becomes slow and incomplete, and the attack window stays open far longer than most teams expect. That is why hardcoded credentials are a governance failure, not just a code smell.

Q: What do security teams get wrong about JWT headers?

A: They often treat JWT headers as trusted instructions instead of attacker-controlled data. Fields such as alg, jku, x5u, and kid can be abused if verification logic uses them without strict allowlists and sanitisation. The safer model is to pin verification behaviour in code and only accept headers that match that predeclared policy.

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.

Technical breakdown

Hardcoded JWT secrets and the credential exposure problem

A JWT signing secret or private key is the trust anchor for the entire token lifecycle. If it is embedded in source code, anyone who gains access to the repository, build artifact, or leaked snippet can mint valid tokens and bypass authentication controls. The issue is not JWT itself, but secret placement and blast radius. When the same secret is reused across environments or services, compromise in one place becomes compromise everywhere. In NHI terms, this is the same failure pattern as overexposed service credentials: a static secret becomes a portable identity primitive.

Practical implication: move JWT secrets out of code and enforce scanning for hardcoded credentials before merge.

The none algorithm and broken token verification

JWT verification must explicitly restrict accepted algorithms and validate the token with the correct library function. Allowing the none algorithm or decoding claims without verification turns a signed assertion into attacker-controlled input. Developers sometimes inspect token contents before verifying them, then pass those values into application logic or database lookups, which creates injection and trust-boundary problems. The security boundary is not the JWT string alone, but the sequence of validation steps around it. In practice, verification failures often come from convenience shortcuts in middleware and helper functions.

Practical implication: enforce allowlists for JWT algorithms and block any path that uses claims before verification.

Sensitive claims exposure and token content governance

A JWT is often treated like a transport container, but it is still readable by any party that can inspect the token. If developers place full user objects, credentials, or other sensitive fields into the payload, the token becomes a data exposure mechanism as well as an authentication artifact. This is especially common when ORM objects are passed directly into signing functions without claim minimisation. The safer model is to treat JWT payloads as minimal, non-sensitive assertions and to validate every claim as untrusted input, even after signature verification.

Practical implication: minimise claims, exclude secrets and passwords, and review every signing path for accidental data leakage.

Threat narrative

Attacker objective: The attacker wants to mint trusted tokens or manipulate token-driven logic to bypass authentication and reach protected data or privileged actions.

1. Entry begins when attackers gain access to exposed code, a leaked repository, or a build artifact containing a hardcoded JWT secret.
2. Credential access follows when the attacker uses the secret to forge tokens or exploits weak verification paths that accept the none algorithm or unverified claims.
3. Impact occurs when forged or overbroad tokens bypass authentication and expose application data or administrative functionality.

NHI Mgmt Group analysis

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.

Static secrets create standing trust in places that should be ephemeral. Hardcoded signing keys turn every environment that can read the code into a credential-bearing system. That is the same structural weakness seen in NHI sprawl, where one leaked secret can unlock multiple applications or services. Standing token trust: when a JWT secret persists across environments or is left in code, the organisation creates a reusable identity primitive that is too easy to copy and too hard to contain. The practical conclusion is to reduce the lifetime and reuse of any signing material.

Token verification shortcuts create a false sense of authentication assurance. The none algorithm example is not just a bad configuration, it is a broken trust boundary. If a system can accept claims before verification or rely on partial checks, then the application is trusting attacker-supplied data. That failure mode mirrors broader identity problems where authentication and authorisation are assumed rather than enforced. Practitioners should assume that any downstream consumer of JWT claims needs its own validation boundary.

Claim minimisation is the control that keeps JWTs from becoming data leaks. Passing entire user objects into a signed token widens exposure far beyond what authentication actually needs. That is especially risky when tokens traverse logs, browsers, or third-party integrations. The right governance model is to define a minimal claim set, review it as part of application design, and treat payload content as regulated data rather than a convenience object. Teams that ignore this create avoidable data exposure inside the identity layer.

Security scanning must be embedded where developers create trust, not only where they ship code. The article’s use of static analysis is a reminder that token misuse is detectable early if the right rules exist. That matters for both human IAM and NHI controls because the same pattern appears whenever credentials are embedded in code or automation. The practitioner takeaway is to make token verification, secret placement, and claim-content rules part of CI policy, not post-incident cleanup.

What this signals

JWT governance will increasingly be judged by how little trust a token carries by default. As applications move faster and identities fragment across services, the practical control question is whether claims are minimised, verified, and bounded tightly enough to survive real-world code reuse. For identity programmes, this is a reminder that authentication policy has to extend into developer workflow, not stop at the identity provider.

Token misuse is one of the clearest examples of secret sprawl meeting authorisation sprawl. The same organisation that allows a signing secret to live in code often allows claims to flow into downstream logic without validation. That combination expands blast radius in exactly the way NHI governance tries to prevent, and it is a strong signal that secret handling and authorisation review need to be governed together.

Practitioners should treat JWT review as a control verification exercise, not a one-time audit. Code changes, library updates, and new service integrations can silently reintroduce the same failure modes. If your programme already tracks secret exposure and access boundaries, this is where those controls should meet in CI, in review, and in runtime policy.

For practitioners

• 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. Scan both application code and infrastructure definitions so build-time and runtime exposures are caught together.
• 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. Review middleware, helper libraries, and custom wrappers so algorithm checks are not bypassed in one module while enforced in another.
• 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. Add code review checks for claim minimisation in every authentication flow.
• Scan for unverified-claim usage in application logic Look for code that decodes JWTs before verification, then passes those claims into database lookups, routing decisions, or privilege checks. Treat that pattern as a trust-boundary violation and fix it before the token reaches downstream business logic.

Key takeaways

• The article shows that JWT failures usually come from governance gaps around secrets, verification, and payload design, not from the token standard itself.
• The scale of the problem is amplified when hardcoded secrets, weak algorithms, and unverified claims create reusable trust across services.
• Teams reduce risk by externalising signing material, enforcing verification policy in code, and minimising claim content before tokens are issued.

Key terms

• JWT signing secret: A JWT signing secret is the cryptographic value used to sign or verify tokens so the recipient can trust the issuer. If exposed, it allows attackers to mint valid tokens or tamper with trust decisions, making its storage and rotation a core access-control concern.
• Token verification: Token verification is the process of checking that a JWT was issued by a trusted party, has not been altered, and meets expected policy before it is used. It should occur before any claim influences authorisation, routing, or database logic, otherwise attacker-controlled data can enter trusted workflows.
• Claim Minimisation: The practice of including only the identity attributes required for a specific access decision. In API security, claim minimisation reduces unnecessary data exposure, simplifies token review, and lowers the risk that broad identity context becomes a hidden authorisation dependency.

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

👉 The full Semgrep post includes code examples, detection rules, and remediation guidance for JWT misuse

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps practitioners connect identity controls to the operational risks created by tokens, keys, and automation.