Open Redirect in Adonisjs with Dynamodb

An open redirect in an AdonisJS application that uses DynamoDB for user or configuration data occurs when an endpoint accepts a user-controlled URL or host value and performs an HTTP redirect without strict validation. If the target URL is derived from or influenced by data stored in DynamoDB (for example, a redirect URL saved in a configuration record or returned as part of a user profile), an attacker who can write or read that DynamoDB item can control the redirect behavior.

Consider an authenticated settings endpoint that reads a custom redirect URL from a DynamoDB table and then uses it in a 302 response. If the application trusts the stored value and does not enforce an allowlist of safe domains, an attacker who can inject a malicious URL into DynamoDB (for example, via compromised admin UI, an insecure import flow, or a misconfigured item update) can cause the application to redirect any user who visits that endpoint to arbitrary external sites.

In AdonisJS, this typically maps to a controller action that fetches an item from DynamoDB using the AWS SDK and then calls res.redirect(target) with the value from the item. Because the redirect decision is based on data stored in DynamoDB, the vulnerability is a stored/open redirect relative to the application’s data store. If the item also includes a label or name shown to users, the risk can be compounded by social engineering: users see a seemingly trusted label but are sent to an attacker-controlled host.

The DynamoDB-specific aspect matters because the persistence and permission boundaries around the table can amplify impact. Overly permissive IAM policies on the AdonisJS service role may allow an attacker to modify redirect-related items; unencrypted items or items with weak conditional writes may allow tampering. Unlike purely runtime configuration, data in DynamoDB can persist across deployments, so a malicious redirect can survive code changes until explicitly removed.

Remediation focuses on strict validation of redirect targets, scoping DynamoDB permissions, and ensuring stored values conform to expected patterns. Below are concrete examples using the AWS SDK for JavaScript v3 within an AdonisJS controller.

1) Validate against an allowlist of domains and enforce a strict schema for any redirect URL stored in DynamoDB. Do not trust values returned from the table without checking scheme and host.

// controllers/RedirectController.js
const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const { unmarshall } = require('@aws-sdk/util-dynamodb');
const { URL } = require('url');

const ALLOWED_HOSTS = new Set(['app.example.com', 'dashboard.example.com']);

class RedirectController {
  async store({ request, response }) {
    const keyName = request.param('key');
    const client = new DynamoDBClient({ region: 'us-east-1' });
    const cmd = new GetItemCommand({
      TableName: process.env.DYNAMODB_TABLE,
      Key: { pk: { S: `redirect:${keyName}` } }
    });
    const { Item } = await client.send(cmd);
    if (!Item) {
      return response.badRequest({ error: 'Not found' });
    }
    const item = unmarshall(Item);
    let target = item.redirectUrl;
    if (!target) {
      return response.badRequest({ error: 'No redirect URL configured' });
    }
    try {
      const parsed = new URL(target);
      if (!ALLOWED_HOSTS.has(parsed.hostname)) {
        return response.badRequest({ error: 'Redirect target not allowed' });
      }
      return response.redirect(parsed.toString());
    } catch (err) {
      return response.badRequest({ error: 'Invalid redirect URL' });
    }
  }
}

module.exports = RedirectController;

2) Apply least-privilege IAM for the AdonisJS runtime role so it can only read specific items (or item attributes) related to redirects, and enforce encryption and conditional writes to prevent unauthorized updates. This reduces the chance that a compromised component can modify redirect targets.

# Example IAM policy snippet (conceptual; manage via your IaC tool)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/AppRedirects",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["redirect:"]
        }
      }
    }
  ]
}

3) Normalize and sanitize inputs that eventually become redirect targets stored in DynamoDB. If your admin flow allows setting a redirect URL, validate it on write using a strict allowlist and store only canonical values. On read, re-validate as shown above.

// utils/validateRedirect.js
function validateRedirect(input) {
  const parsed = new URL(input);
  if (!['https:'].includes(parsed.protocol)) {
    throw new Error('Only HTTPS URLs are allowed');
  }
  if (!ALLOWED_HOSTS.has(parsed.hostname)) {
    throw new Error('Hostname not permitted');
  }
  // Optionally strip credentials and fragments
  parsed.hash = '';
  parsed.search = '';
  return parsed.toString();
}

// In your controller when storing
const safeTarget = validateRedirect(request.input('redirectUrl'));
// Then store safeTarget in DynamoDB