User-editable claims are risky because they let the subject influence the policy signal used to grant access. Authorisation data should be issued by a trusted service and remain immutable from the user’s perspective. If roles are stored in writable metadata, the application may appear federated while still relying on data the user can alter.
Why This Matters for Security Teams
User-editable JWT claims are dangerous because they turn the authorisation signal into attacker-controlled input. If an application trusts roles, scopes, tenant IDs, or privilege flags from a token that the user can influence, the system may grant access based on self-asserted data rather than a server-issued decision. That breaks the core security assumption behind token-based access control and creates a clean path to privilege escalation.
This risk shows up most often when teams use JWTs as a convenience layer without separating authentication from authorisation. A signed token is not automatically safe for authorisation if the claims inside it can be altered upstream, copied from stale state, or populated from writable user profile fields. Current guidance from the NIST Cybersecurity Framework 2.0 still points teams toward least privilege and strong access governance, but the implementation detail matters: the policy source must be trusted, current, and not user-editable. NHIMG research on the Top 10 NHI Issues shows the same failure pattern across machine identities when trust signals become writable. In practice, many security teams discover this only after a low-privilege account has already turned a harmless claim into an access path.
How It Works in Practice
The safe pattern is to treat JWT claims as statements about identity and session context, not as the final source of truth for access. Authentication can still rely on a signed token, but authorisation should be evaluated against server-side policy, directory data, or a dedicated entitlement service at request time. That means claims such as sub, aud, and token expiry can inform trust decisions, while mutable privilege data should come from a trusted control plane.
Practitioners usually tighten this in three ways:
- Issue tokens with immutable claims only, and keep roles or permissions outside user-writable profile fields.
- Use short-lived access tokens so stale privilege does not survive long after a change.
- Re-check entitlement on sensitive actions instead of assuming the JWT remains authoritative for the full session.
For higher assurance, teams can pair JWT validation with policy-as-code and runtime checks, using the token as an input rather than the decision itself. This aligns with the access-control principles in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where account management, least privilege, and separation of duties are in scope. The same principle appears in NHIMG’s OWASP NHI Top 10: do not let the object being controlled influence the control decision. In practice, the most resilient designs treat claims as evidence, then confirm authority from a source the user cannot edit. These controls tend to break down when legacy apps cache claims for long sessions because privilege drift and token staleness become difficult to detect.
Common Variations and Edge Cases
Tighter claim handling often increases implementation overhead, requiring organisations to balance faster development against stronger trust boundaries. That tradeoff is most visible in federated environments, where teams want single sign-on convenience but also need fine-grained access decisions.
One common edge case is a signed token that is technically valid yet operationally unsafe because the claim was populated from a mutable upstream system. Another is tenant isolation, where a tenant ID in the JWT is trusted too broadly and becomes a lateral-movement path if the application never revalidates it against server-side tenancy data. Best practice is evolving here: there is no universal standard for whether every privilege decision must be re-evaluated on each request, but current guidance suggests that high-risk actions should never rely on user-editable claims alone.
NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and the DeepSeek breach both reinforce a practical lesson: when trust data is exposed, stale, or writable, attackers do not need to break cryptography to win. They only need the application to believe the wrong claim at the wrong time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers untrusted or mutable identity signals used for access decisions. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on trustworthy entitlement data. |
| NIST SP 800-63 | Digital identity assurance requires trusted assertion sources and token integrity. | |
| NIST Zero Trust (SP 800-207) | AC-6 | Zero Trust requires continuous verification, not blind trust in token content. |
| NIST AI RMF | GOVERN | AI systems using JWTs need governed identity inputs and accountable policy sources. |
Keep authorisation data server-side and reject user-editable claims for privilege decisions.
Related resources from NHI Mgmt Group
- How should teams enforce least privilege in applications that rely on JWT claims?
- Why are local .env files and config notes risky in Microsoft 365?
- How should teams secure Next.js 13 routes that depend on user sessions?
- What breaks when the identity provider and database use different user ID formats?
