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.
Why JWTs Leak Sensitive Data When Teams Treat Them Like Containers
A JWT is not a safe place to park rich user records. Its payload is a bearer artifact that may be copied into telemetry, browser storage, support tooling, caches, or downstream systems, so every claim should be assumed broadly visible. The safest pattern is to treat the token as a narrowly scoped transport for what the relying service truly needs.
That design choice matters because JWTs are often decoded by many parties, not just the issuing service. If a team signs full profiles, ORM entities, or convenience fields into the token, they create avoidable disclosure paths and make later redaction much harder.
What Belongs in a JWT, and What Should Stay Out
Only include claims that are necessary for immediate authorization or session handling, such as a stable subject identifier, issuer, audience, expiry, and the minimum context needed by the recipient. If a field is not required for the token’s core purpose, it should remain in the source system or be fetched through a controlled lookup after the token is validated.
That boundary is especially important for attributes that reveal personal data, internal roles, tenant details, entitlements, or operational metadata. A small payload reduces disclosure if the token is logged, inspected in a browser, or forwarded to another service that was never meant to see the underlying attributes.
- Keep the claim set minimal and purpose-built for the relying party.
- Do not serialize complete user objects, session objects, or ORM records into the token.
- Store sensitive attributes in the authoritative system of record and retrieve them only when needed under access control.
- Review custom claims as data elements, not as harmless implementation details.
How to Reduce Leakage Across Logs, Storage, and Integrations
JWT leakage is rarely only a token-design problem. It often appears when developers decode tokens in application logs, pass them through client-side storage, or forward them to services that do not need the full payload. The same token can then show up in multiple places, multiplying exposure even if the signature remains valid.
Practical containment means limiting where tokens are handled and how much of their contents are exposed at each hop. The Token and Session Security Guide is a useful reference for token lifetime, validation, revocation, and replay-resistant handling, while Guide to SPIFFE and SPIRE shows the broader workload-identity pattern of keeping credentials and trust material separate from application data. When teams need an example of what happens after sensitive material is exposed, DeepSeek database exposure 2025 illustrates how plaintext secrets and logs can become immediate disclosure channels.
Why Claim Design Is Really Data Classification
Claim design should follow the same discipline as any other data-classification decision. A claim is not safe just because it is compact or signed, and a signature does not reduce the sensitivity of the contents. If a value would be protected elsewhere as personal data, internal-only data, or secrets-related context, it deserves the same scrutiny before it is embedded in a token.
This is why teams should define an explicit claim schema and a review process for new fields. The decision is not only whether the claim is technically valid, but whether the receiving service genuinely needs it at token time, whether it can be derived elsewhere, and whether its disclosure would create avoidable downstream risk.
Risk and Threat Considerations
JWTs are frequently overexposed because they are easy to decode and easy to reuse. Once sensitive data is placed in the payload, it can leak through client storage, logs, debugging tools, browser extensions, or third-party services that receive the token as part of normal flow.
Failure mechanism: Teams sign rich objects or high-value attributes into JWTs, then those tokens are copied into places with weaker visibility controls or broader access than the issuing application intended.
Impact: Sensitive fields can be disclosed without any token forgery, and the leak can persist until the token expires or every copied instance is removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V14 — Data Protection | JWT payloads can expose sensitive data and need minimization. |
| Recommendation — Limit token claims to the minimum data required for the session. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWTs and related token material require lifecycle and exposure control. |
| Recommendation — Restrict token contents and manage token lifecycle to reduce exposure. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | JWT claims should be classified and handled based on sensitivity. |
| Recommendation — Classify claims before placing them into tokens or logs. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | JWT handling errors can expose bearer tokens and their contents across API flows. |
| Recommendation — Validate token handling so APIs never expose unnecessary claims. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Minimising sensitive data in JWTs supports broader data protection safeguards. |
| Recommendation — Reduce sensitive data placement in tokens and surrounding systems. | ||
Practitioner Guidance
What to prioritise: Start by inventorying every custom claim and deleting anything that is not required by the relying service at validation time. Then compare the token payload against the data model to catch accidental inclusion of whole objects, nested profiles, or ORM serialization output.
What to verify: Confirm that logs, analytics, support tooling, and frontend storage never receive raw JWTs unless there is a documented operational need. Also verify that downstream services consume only the claims they truly require, not the full payload by convenience.
Common mistake: Teams often assume signing equals safety. In practice, a signed JWT can still be a disclosure event if the payload contains more information than the token’s immediate purpose requires.
Practitioner takeaway: Treat JWT design as minimization and disclosure control, not as a place to preserve convenience, because every unnecessary claim expands the blast radius of a token leak.
Related resources from NHI Mgmt Group
- How should security teams prevent sensitive data from leaking through AI prompts and copilots?
- How should security teams prevent LLM memory from leaking sensitive data?
- How should security teams prevent sensitive data from leaking into logs, tickets, and other downstream systems?
- How should organisations reduce the risk of sensitive data leaking from endpoints and user devices?