# Sast Jwt

Detect insecure JWT (JSON Web Token) implementations in a codebase using a two-phase...

- Repository: https://github.com/utkusen/sast-skills (1357 stars)
- Category: Security
- License: MIT
- Last updated: 2026-10-23
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add utkusen/sast-skills --skill sast-jwt -g -a claude-code -y`
Codex: `npx skills add utkusen/sast-skills --skill sast-jwt -g -a codex -y`
Cursor: `npx skills add utkusen/sast-skills --skill sast-jwt -g -a cursor -y`
Gemini CLI: `npx skills add utkusen/sast-skills --skill sast-jwt -g -a gemini-cli -y`

## Description

Detect insecure JWT (JSON Web Token) implementations in a codebase using a two-phase approach: first map all JWT issuance and verification sites to understand the token lifecycle and signing configuration, then check each verification site for exploitable weaknesses such as algorithm confusion, missing signature verification, weak secrets, header injection, and missing claim validation. Requires sast/architecture.md (run sast-analysis first). Outputs findings to sast/jwt-results.md. If no JWT usage is found in Phase 1, Phase 2 is skipped. Use when asked to find JWT, token forgery, or authentication bypass bugs.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# JWT Vulnerability Detection

You are performing a focused security assessment to find insecure JSON Web Token (JWT) implementations. This skill uses a two-phase approach with subagents: **recon** (map the full JWT lifecycle, issuance, verification, and configuration) then **analysis** (identify every exploitable weakness in those verification sites).

**Prerequisites**: `sast/architecture.md` must exist. Run the analysis skill first if it doesn't.

---

## What is an Insecure JWT Implementation

JWTs consist of three Base64URL-encoded parts: `header.payload.signature`. The header declares the signing algorithm (`alg`), the payload carries claims (e.g., `sub`, `role`, `exp`), and the signature is a cryptographic proof of integrity. Vulnerabilities arise when the server trusts the token's own claims about how it was signed, fails to verify the signature at all, uses a guessable secret, or trusts attacker-controlled key material embedded in the token itself.

The core pattern: *the server does not fully verify the JWT's authenticity and integrity before trusting its claims.*

### What JWT Vulnerabilities ARE

**1. Algorithm confusion, `alg: none`**
The server accepts a JWT whose header declares `"alg": "none"`, bypassing signature verification entirely. An attacker crafts an arbitrary payload, sets `alg` to `none`, and omits the signature. If the library processes it, the forged token is accepted.

**2. Algorithm confusion, RS256 → HS256**
A server configured for RS256 (asymmetric: sign with private key, verify with public key) can be tricked into HS256 mode if the library allows the algorithm to be specified by the token. Since the public key is often retrievable, the attacker signs a forged token with HS256 using the server's public key as the HMAC secret. The server verifies the HMAC using the same public key and accepts the token.

The rest: https://github.com/utkusen/sast-skills/blob/HEAD/sast-files/.agents/skills/sast-jwt/SKILL.md