How to fix JWT alg:none

What an attacker can do

The concrete impact of leaving JWT alg:none unpatched.

How to fix JWT alg:none

6 ordered steps. Apply them in order — each builds on the previous.

1. 1

   Lock the algorithm in Node.js (jsonwebtoken)

   Pass the algorithms array explicitly to jwt.verify. Without it, the library accepts ANY algorithm including 'none'.

   jsonwebtoken (the most-used Node JWT library) deprecated implicit-algorithm verification but kept backward compatibility. If you don't pass algorithms, you get a deprecation warning in dev — but it still works in prod. Always pass the explicit array. Also reject 'none' even if you somehow allow it via a library bug, by checking the decoded header before verification.

   Node.js / jsonwebtokenStep 1

   import jwt from 'jsonwebtoken';
   
   // VULNERABLE — accepts whatever the header says
   const decoded = jwt.verify(token, secret);
   
   // SECURE — explicit algorithms list
   const decoded = jwt.verify(token, secret, {
     algorithms: ['HS256'],     // exactly the algorithm(s) you use
     issuer: 'your-app',         // belt and suspenders
     audience: 'your-app',
   });
   
   // EXTRA — reject 'none' before verification (defense in depth)
   const header = JSON.parse(
     Buffer.from(token.split('.')[0], 'base64url').toString()
   );
   if (!header.alg || header.alg.toLowerCase() === 'none') {
     throw new Error('Algorithm not allowed');
   }

2. 2

   Lock the algorithm in Python (PyJWT)

   Always pass algorithms parameter to jwt.decode. PyJWT 2.0+ requires it, but older code often calls without it.

   PyJWT changed its default in 2.0 — older versions would accept any algorithm by default; 2.0+ raises if you don't pass algorithms. If you're on 2.0+ this is mostly fixed. If you're on an older PyJWT (some legacy apps still are), you MUST pass algorithms. Audit every jwt.decode call.

   Python / PyJWTStep 2

   import jwt
   
   # VULNERABLE on PyJWT < 2.0 — algorithm taken from header
   decoded = jwt.decode(token, secret)
   
   # SECURE — explicit algorithms (also required on PyJWT 2.0+)
   decoded = jwt.decode(
       token,
       secret,
       algorithms=["HS256"],  # exactly the algorithm(s) you use
       issuer="your-app",
       audience="your-app",
       options={"require": ["exp", "iat", "iss"]},  # require standard claims
   )

3. 3

   Lock the algorithm in Java (jjwt / Auth0 java-jwt)

   Use parserBuilder().setSigningKey(...) which forces HS256/RS256 inference, OR explicitly state expected algorithm via JwtParser.

   jjwt 0.11+ is mostly safe — the parserBuilder API infers algorithm from key type. But code paths using SigningKeyResolver (where the resolver returns different keys based on header data) can be tricked into using attacker-chosen algorithms. Pin the algorithm explicitly when using a resolver.

   Java / jjwt 0.11+Step 3

   import io.jsonwebtoken.*;
   
   // SECURE — algorithm inferred from key type, locked
   JwtParser parser = Jwts.parserBuilder()
       .setSigningKey(hmacKey)        // HS256 inferred from key
       .requireIssuer("your-app")
       .requireAudience("your-app")
       .build();
   
   Jws<Claims> jws = parser.parseClaimsJws(token);
   
   // If using a resolver, pin algorithm explicitly:
   SigningKeyResolver resolver = new SigningKeyResolverAdapter() {
     @Override public Key resolveSigningKey(JwsHeader header, Claims claims) {
       // CRITICAL: validate alg, then return key
       if (!"RS256".equals(header.getAlgorithm())) {
         throw new JwtException("Algorithm not allowed");
       }
       return loadPublicKey(header.getKeyId());
     }
   };

4. 4

   Lock the algorithm in Go (golang-jwt/jwt)

   In jwt.Parse, the keyFunc receives the parsed token — VALIDATE token.Method before returning the key.

   golang-jwt's pattern: Parse() calls keyFunc with the parsed token, expecting it to return the verification key. The classic alg-confusion bug: keyFunc returns the public key without checking token.Method, attacker sends an HS256-signed token, library uses the public key as HMAC secret, signature 'verifies'. Fix: check token.Method type explicitly inside keyFunc.

   Go / golang-jwtStep 4

   import "github.com/golang-jwt/jwt/v5"
   
   // SECURE — explicit method check inside keyFunc
   token, err := jwt.Parse(tokenString, func(t *jwt.Token) (any, error) {
       // CRITICAL: enforce the expected algorithm family
       if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
           return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
       }
       // Reject alg=none as well (some versions return SigningMethodNone here)
       if t.Method.Alg() == "none" {
           return nil, fmt.Errorf("alg none not allowed")
       }
       return secretBytes, nil
   })

5. 5

   Use the jose library (multi-lang) with explicit algorithms

   If you're picking a JWT library fresh, prefer 'jose' (Node/Browser/Python). Its API requires algorithms upfront — harder to misuse.

   The 'jose' library family (panva/jose for Node, python-jose for Python) is designed around the JWS Validation Profile that requires algorithms upfront. The verifier object encapsulates the algorithm list — there's no way to call it without specifying. If migrating from jsonwebtoken or PyJWT, jose is a safer default for new code.

   Node.js / joseStep 5

   import * as jose from 'jose';
   
   const secret = new TextEncoder().encode(process.env.JWT_SECRET!);
   
   // SECURE by design — algorithms required by the API
   const { payload } = await jose.jwtVerify(token, secret, {
     algorithms: ['HS256'],     // mandatory parameter
     issuer: 'your-app',
     audience: 'your-app',
     requiredClaims: ['sub', 'exp', 'iat'],
   });

6. 6

   Add unit tests that submit alg=none and alg-confusion tokens

   Every JWT-protected endpoint needs a test sending a forged alg=none token. Assert the response is 401 — never the protected resource.

   Test pattern: take a valid token, modify it to alg=none with no signature, send to a protected endpoint, assert 401. Repeat with HS256 token signed using the public key (alg-confusion test). Run on every PR. Catches regressions when someone refactors auth or upgrades a library and the new defaults differ.

   JestStep 6

   function forgeAlgNone(payload: object): string {
     const header = Buffer.from(JSON.stringify({ alg: 'none', typ: 'JWT' })).toString('base64url');
     const body = Buffer.from(JSON.stringify(payload)).toString('base64url');
     return `${header}.${body}.`;  // empty signature
   }
   
   describe('JWT alg:none rejection', () => {
     it('rejects alg=none forged token on /api/me', async () => {
       const forged = forgeAlgNone({ sub: 'admin', role: 'admin', exp: Date.now()/1000+3600 });
       const res = await api.get('/api/me')
         .set('Authorization', `Bearer ${forged}`);
       expect(res.status).toBe(401);
       expect(res.body.email).toBeUndefined();
     });
   
     // Test case variations (None, NONE, nOne) — some libraries differ
     it.each(['none','None','NONE','nOne'])('rejects alg=%s', async (alg) => {
       const header = Buffer.from(JSON.stringify({ alg, typ: 'JWT' })).toString('base64url');
       const body = Buffer.from(JSON.stringify({ sub: 'admin' })).toString('base64url');
       const res = await api.get('/api/me')
         .set('Authorization', `Bearer ${header}.${body}.`);
       expect(res.status).toBe(401);
     });
   });