Jwt None Algorithm in Adonisjs

The JWT 'none' algorithm attack occurs when an attacker modifies a JWT header to set alg:none and removes the signature, tricking a vulnerable implementation into accepting the token as valid. In Adonisjs applications, this typically surfaces in routes that rely on the @adonisjs/auth package for JWT-based authentication, especially when the authentication guard is misconfigured to accept tokens without proper algorithm validation.

Consider an Adonisjs 5.x application using JWT authentication via the auth provider. If the guard configuration does not explicitly restrict allowed algorithms, an attacker can forge a token with alg:none and an empty signature. For example, a route protected by middleware.auth() using a JWT guard might accept such a token if the underlying library (like php-jwt or jsonwebtoken via Adonisjs) does not enforce algorithm checks.

A specific code path where this risk appears is in custom authentication handlers or when overriding the default JWT validation logic. For instance, if a developer manually decodes a token using jwt.verify(token, secret, { algorithms: ['HS256'] }) but omits the algorithms option, the jsonwebtoken library may accept none by default in older versions. In Adonisjs, this could happen in a custom AuthProvider or a route controller that processes tokens outside the standard guard flow.

Real-world impact includes bypassing authentication to access protected endpoints like /api/user/profile or /api/admin/settings. This aligns with OWASP API Security Top 10:2023, API1:2023 Broken Object Level Authorization, where weak authentication mechanisms allow attackers to assume unauthorized identities.

Detecting the JWT none algorithm vulnerability in an Adonisjs application requires testing the unauthenticated attack surface of API endpoints that process JWT tokens. middleBrick identifies this flaw by sending modified tokens with alg:none and an empty signature to protected routes and observing whether the server grants access.

For example, if an Adonisjs API has a route like Route.get('/user', 'UserController.show').middleware('auth'), middleBrick will:

• Capture a legitimate JWT token from a login response or public endpoint.
• Strip the signature and alter the header to { "alg": "none", "typ": "JWT" }.
• Base64URL-encode the modified header and payload, then concatenate with an empty signature (i.e., header.payload.).
• Submit this token in the Authorization: Bearer header to the target endpoint.
• If the API returns a 200 OK or sensitive data instead of 401 Unauthorized, the vulnerability is confirmed.

This detection works without agents, credentials, or configuration — only the base URL is needed. middleBrick’s parallel security checks include this test under the "Authentication" category, specifically targeting weak JWT validation logic. The finding includes severity (Critical), remediation guidance, and mapping to OWASP API1:2023.

Developers can also detect this locally by reviewing Adonisjs guard configuration in config/auth.js. A misconfiguration might look like:

// config/auth.js
jwt: {
  secret: Env.get('APP_KEY'),
  // Missing: allowedAlgs: ['HS256']
  // If absent, some JWT libraries may accept 'none'
}

Or in a custom provider where jwt.verify() is called without algorithm constraints.

Fixing the JWT none algorithm vulnerability in Adonisjs involves enforcing strict algorithm validation during token verification. The @adonisjs/auth package relies on the jsonwebtoken library, which must be configured to reject tokens with alg:none. Remediation requires updating the JWT guard configuration to explicitly define allowed algorithms and ensuring all token validation paths adhere to this constraint.

The primary fix is to set the allowedAlgs option in the JWT guard configuration within config/auth.js. This option is passed directly to the jsonwebtoken.verify() function and prevents acceptance of unsupported algorithms.

// config/auth.js
jwt: {
  secret: Env.get('APP_KEY'),
  allowedAlgs: ['HS256'] // Explicitly restrict to HS256 only
}

This configuration ensures that any token with alg:none or an unsupported algorithm (e.g., RS256 when only HS256 is expected) is rejected during verification.

If your Adonisjs application uses a custom authentication provider or manually verifies tokens in a controller, you must explicitly specify the algorithm in the verification call. For example, in a custom middleware:

// app/Middleware/Authenticate.js
const jwt = require('jsonwebtoken');

async handle({ request, response, auth }, next) {
  const token = request.header('authorization')?.replace('Bearer ', '');
  if (!token) {
    return response.unauthorized({ error: 'Missing token' });
  }

  try {
    // Explicitly specify algorithm to prevent 'none' acceptance
    const payload = jwt.verify(token, Env.get('APP_KEY'), { algorithms: ['HS256'] });
    request.user = payload;
    await next();
  } catch (error) {
    return response.unauthorized({ error: 'Invalid token' });
  }
}

Additionally, ensure that the jsonwebtoken package is updated to a version that treats missing or invalid algorithms as errors by default (v8.5.0+ includes stricter defaults, but explicit configuration is still recommended). Never rely on library defaults for security-critical validation.

After applying these changes, rescan the API with middleBrick to confirm the Authentication check now passes and the risk score improves. The fix aligns with OWASP API Security Top 10:2023 API2:2023 Broken Authentication, which includes mitigating token tampering attacks.