JSON Web Token

ID

jwt

Severity

high

Vendor

-

Family

API Token

Description

JSON Web Tokens (JWT) represent claims securely between two parties. They follow the open standard RFC 7519.

JWT are JSON objects containing the claims and signed using HMAC or public key/private keypair. It contains three parts: a header, a payload and a signature. header and payload are base-64 encoded JSON objects.

JWT claims can typically be used to pass the identity of authenticated users between an identity provider and a service provider.

Security

Any hardcoded JWT is a potential secret reported by this detector.

The payload may contain sensitive information, like passwords or access-control tokens. It is protected against modification by the signature, but typically it is not encrypted.

In addition, any secret (for example, a shared key) hardcoded in source code or committed configuration files used in code for JWT generation / verification is an obvious security flaw, as this allows an attacker to forge the token if the file containing the secret is leaked.

Once issued, access tokens and ID tokens cannot be revoked in the same way as cookies with session IDs for server-side sessions. As a result, tokens should be issued for relatively short periods, and then refreshed periodically if the user remains active. For this reason, long-lived tokens are troublesome.

Needless to say, sensitive data should not be kept in JWT token intentionally, unless the token is appropriately encrypted.

Examples

The detector validates the structure of a candidate hardcoded JWT:

// Hardcoded JWT (abbreviated for clarity)
const jwt = 'eyJhxxx.eyJsyyy.VzjKzzz'; // FLAW

In addition, any secret (shared key for HMAC, or password protecting a private key used for signing the JWT) is detected by the detector:

// Hardcoded secret for generating JWT with jsonwebtoken
const jwt = require("jsonwebtoken");
const secret = "secret-here"; // FLAW

class JwtSigner {
  static generateToken(payload) {
    return jwt.sign(payload, secret);
  }
}

Mitigation / Fix

  1. Remove the hardcoded JWT, or secret used for signing, from the source code or committed configuration file.

  2. Follow your policy for handling leaked secrets, which typically require revoking the secret in the target system(s).

  3. If under a git repository, you may remove unwanted files from the repository history using tools like git filter-repo or BFG Repo-Cleaner. You may follow the procedure listed here.

You should consider any sensitive data in commits with secrets as compromised.

Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

  1. Check access logs to ensure that the secret was not used by unintended actors during the compromised period.

Reference

https://tools.ietf.org/html/rfc7519