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

At a glance

What this is: Semgrep’s review of 2,000 npm modules found that common JWT misuse in Node.js still centers on hardcoded secrets, weak verification, and exposure of sensitive data inside tokens.

Why it matters: IAM and application security teams need to treat JWTs as governed credentials and untrusted inputs, because token handling failures can turn authentication into token forgery, data leakage, or injection paths.

Context

JWTs are often treated as a lightweight authentication layer, but their security depends entirely on how they are issued, verified, and handled in application code. In Node.js projects, that makes JWT misuse as much an identity and credential-governance problem as it is an application security problem.

This article focuses on recurring implementation mistakes rather than the JWT standard itself. The key issue is that teams often let secrets live in code, relax verification rules, or expose claims before validation, which weakens both application trust and identity assurance.

The pattern is typical of how token-based systems fail in practice: the mechanism is sound, but the surrounding controls are not.

Key questions

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. If the repository or build artefact is exposed, an attacker can forge valid tokens and impersonate trusted users or services. The practical fix is to remove signing material from code, store it separately, and treat the secret as a governed credential with its own rotation and access controls.

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. It lets code accept tokens without a valid signature, which means attacker-controlled claims can enter application logic as if they were authentic identity evidence. Teams should enforce explicit algorithm allowlists and reject any implementation that accepts unsigned tokens in production paths.

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. Once unverified data affects routing, database queries, or authorisation decisions, the application has already trusted attacker input. Verification must happen first, and only then should claims be used as input to downstream logic or access decisions.

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.

Technical breakdown

Hardcoded JWT secrets turn signing keys into source-code exposure

A hardcoded JWT secret collapses the separation between application logic and credential material. If the repository, build artifact, or deployment package is exposed, the attacker gets the signing key and can mint tokens that look legitimate to the application. This is not a JWT flaw, but a lifecycle failure: the secret is no longer governed as a secret. In practice, secrets should be externalised and rotated independently of the code that consumes them, with detection in place before merge and release.

Practical implication: treat JWT signing material as a managed secret, not an application constant.

The none algorithm and weak verification break token trust

JWT verification fails when code accepts unsafe algorithms or trusts decoded claims before validation. The none algorithm removes cryptographic assurance entirely, while decoding without verification lets attacker-controlled payloads influence downstream logic. In Node.js, this often appears as custom wrappers around jwt.decode or partial checks that verify one token but use another token’s data. The control boundary matters: verification must happen before any claim is consumed for authorization, routing, or database lookup.

Practical implication: enforce explicit algorithm allowlists and verify every token before any claim is used.

Sensitive claims in tokens create a data exposure problem

JWTs are readable by design unless the payload is separately encrypted, so putting sensitive fields into the token turns every token copy into a data disclosure event. The risk grows when object models are signed directly, because the payload can include fields that were never intended for clients, logs, or browser storage. In application terms, JWTs should carry only the minimum claims required for the trust decision, and those claims should be validated against context rather than assumed to be safe because they were signed.

Practical implication: minimise token claims and never sign whole user objects or ORM records.

Threat narrative

Attacker objective: The attacker aims to impersonate a trusted user or service, bypass token checks, and extract or manipulate protected application data.

1. Entry begins when an exposed source repository or copied code reveals a hardcoded JWT secret or an unsafe verification rule.
2. Credential abuse follows when the attacker forges a token, enables an unsafe algorithm path, or reuses unverified claims in application logic.
3. Impact occurs when forged or over-shared tokens grant unauthorised access, trigger injection-style behaviour, or disclose sensitive account data.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Hardcoded secrets create a standing-trust failure, not just a leakage issue. A JWT secret embedded in source code is usable wherever the code travels, which means the trust boundary follows the repository, build system, and deployment artefact. That is a classic secret sprawl condition. The named concept here is token trust leakage: when the token-signing control and the application code share the same exposure path, compromise becomes operationally trivial. Teams should remove the secret from code paths entirely.

Verification must be authoritative before any claim is operationalised. The article’s examples show how easy it is to let decoded claims shape application behaviour before the token has been validated. That creates a governance gap where untrusted input is allowed to masquerade as identity evidence. For IAM teams, the lesson is that signed data is not automatically trustworthy data, and verification order is part of the control design. Practitioners should design for validate-first, consume-second.

JWT payload design is a data-classification decision, not just a transport choice. When teams sign whole user objects or ORM records, they often leak fields that were never intended for the receiving party. That turns token handling into a privacy and data-minimisation problem as well as an auth problem. In modern identity programmes, claim design needs the same discipline as entitlement design: only the minimum necessary information should travel in the token. Practitioners should reduce payload scope and classify JWT contents explicitly.

This article reinforces why OWASP-NHI matters even in application-token discussions. JWTs are non-human credentials when they are used to authenticate services, API flows, or delegated application actions. The governance challenge is not the token format alone but the lifecycle of the credential behind it. When secret storage, rotation, and verification are weak, the NHI attack surface expands through ordinary application code. Practitioners should bring machine-credential controls to JWT handling wherever services depend on them.

From our research library:

• 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.
• Read next: Secrets Management Guide

What this signals

Token trust leakage: the real failure mode here is not JWT itself but the collapse of credential governance into source code, verification shortcuts, and overbroad payload design. That pattern is common wherever teams treat tokens as transport objects rather than access credentials, and it deserves the same lifecycle discipline as other machine identities.

The wider lesson for IAM and application security teams is that verification order, secret storage, and claim minimisation have to be designed together. If any one of those controls is weak, a signed token can still become attacker-controlled input instead of trustworthy identity evidence, especially in service-to-service flows.

For practitioners

• 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.
• Add static analysis rules for JWT anti-patterns Scan for hardcoded secrets, none-algorithm acceptance, jwt.decode without verify, and direct object signing in CI before code reaches production.
• Review token handling as part of application IAM Map JWT issuance, validation, and revocation responsibilities to the teams that own authentication and access decisions, not just application delivery.

Key takeaways

• JWT misuse in Node.js is usually caused by governance failures around secrets, verification, and token content, not by the JWT standard itself.
• The article’s examples show how a signing secret, an unsafe algorithm, or an unverified claim can each turn a valid-looking token into an attack path.
• Strong JWT control design keeps signing material out of code, verifies before consuming claims, and limits token content to the minimum necessary.

Key terms

• JWT Secret: A JWT secret is the key used to sign or verify a token when symmetric algorithms are in use. If it is exposed, an attacker can mint tokens that the application will accept as genuine, so it must be treated as a high-value credential with separate storage and rotation.
• 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.
• JWT Claim Minimisation: JWT claim minimisation is the practice of limiting a token to only the fields needed for the current trust decision. It reduces disclosure risk, limits downstream misuse, and keeps sensitive account or profile data out of tokens that may be copied into logs, clients, or other services.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.