Open Redirect in Adonisjs with Jwt Tokens

An Open Redirect occurs when an application redirects a user to an untrusted URL without proper validation. In AdonisJS, this risk can intersect with JWT token handling when redirect logic relies on unvalidated input, potentially allowing an attacker to craft a link that authenticates a victim and redirects them to a malicious site.

Consider an authentication flow that accepts a redirect_to query parameter after a successful JWT-based login. If the parameter is not validated against a strict allowlist, an attacker can supply a malicious URL (e.g., https://evil.com). After the server issues a JWT and redirects using the provided value, the victim is taken to the attacker’s site while still authenticated, enabling phishing or session hijacking scenarios.

Another scenario involves the use of JWT tokens in single-use redirect links, such as password reset or email verification. If the endpoint that consumes these tokens performs a redirect based on data within or linked to the token without validating the target, the combination of JWT-based authorization and unchecked redirection creates an exploitable path.

Because JWT tokens often carry identity and scope information, an attacker who can influence the redirect destination may leverage a trusted domain to host malicious JavaScript or to harvest credentials. Even though JWTs themselves are cryptographically signed, the server must ensure that any redirection triggered by token validation does not simply forward to user-supplied URLs.

middleBrick detects this pattern during black-box scanning by analyzing authentication flows, inspecting response headers that include Location, and correlating findings with input validation checks. The scanner runs checks for Input Validation and Unsafe Consumption in parallel with authentication tests to highlight whether redirects are constrained to safe origins.

To secure AdonisJS applications using JWT tokens, ensure that any redirect behavior is based on hardcoded routes or a strict allowlist, never on raw user input. Validate and sanitize all parameters that influence navigation, and avoid including redirect targets within JWT payloads unless absolutely necessary and properly constrained.

Example of insecure code that should be avoided:

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { schema } from '@ioc:Adonis/Core/Validator'
import { Token } from '@ioc:Adonis/Addons/Auth'

export default class AuthController {
  public async login({ request, response, auth }: HttpContextContract) {
    const payload = request.only(['email', 'password', 'redirect_to'])
    await auth.authenticate()
    const token = await auth.use('api').generate(payload.email)
    // Dangerous: redirect_to is taken directly from user input
    return response.redirect(payload.redirect_to || '/dashboard')
  }
}

In the example above, redirect_to is supplied by the client and used without validation. An attacker can set this to any external URL, causing the application to redirect authenticated users.

Secure implementation with strict allowlisting:

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { schema } from '@ioc:Adonis/Core/Validator'

export default class AuthController {
  public async login({ request, response, auth }: HttpContextContract) {
    const payload = request.only(['email', 'password', 'redirect_to'])
    await auth.authenticate()
    const token = await auth.use('api').generate(payload.email)

    // Define a strict allowlist of safe redirect paths
    const allowedRedirects = ['/dashboard', '/profile', '/settings']
    const redirectTo = allowedRedirects.includes(payload.redirect_to) ? payload.redirect_to : '/dashboard'

    return response.redirect(redirectTo)
  }
}

This approach ensures that even if an attacker supplies a malicious URL, the server only redirects to predefined, trusted paths. For flows that require dynamic redirection (such as deep links after login), encode the intended destination server-side and map it to a token or session value that can be safely resolved on the server without exposing raw URLs to the client.

When using JWT tokens in query strings for password resets or email confirmation, prefer server-side resolution of the target route rather than embedding a full URL in the token or query parameters. Use short-lived tokens and validate the token’s scope and audience to reduce the impact of any leakage.

middleBrick’s LLM/AI Security checks can identify whether prompts or outputs inadvertently expose redirect logic or sensitive navigation instructions. The scanner’s Input Validation and Authentication checks highlight whether redirect parameters are constrained and whether JWT usage follows secure patterns.