Open Redirect in Nestjs with Dynamodb

An open redirect in a NestJS application that uses DynamoDB typically arises when a route accepts a user-supplied URL or hostname and forwards the client without strict validation. If the same route also queries DynamoDB to look up tenant or configuration data (for example, reading redirect rules from a table), an attacker can supply a malicious external URL while relying on the app to use DynamoDB-stored settings to decide whether to proceed. The vulnerability is not in DynamoDB itself, but in the way the application uses data retrieved from DynamoDB to determine redirect behavior.

Consider a scenario where redirect rules are stored in DynamoDB with an allowed list of domains. If the NestJS service retrieves a rule by an identifier (e.g., ruleId) via the AWS SDK and then performs a redirect using a user-provided url parameter without verifying that the target matches the allowed list, the application becomes susceptible to open redirect. An attacker could provide a crafted URL such as https://evil.com while the app references DynamoDB-stored configuration that may incorrectly permit the redirect due to missing or weak domain validation.

Additionally, misconfigured CORS or missing referrer checks can compound the issue. For example, if the NestJS endpoint exposes a public API that both reads from DynamoDB and redirects, and does not validate the Referer or origin, an external site can lure users into making authenticated-seeming requests that ultimately redirect victims to malicious sites. Because DynamoDB stores the policy (e.g., allowed domains), any weakness in how the application interprets that policy directly impacts whether an open redirect is possible.

Remediation centers on strict validation of redirect targets and careful handling of data retrieved from DynamoDB. Never trust user input for the destination URL. Instead, resolve the target against an allowlist stored in DynamoDB or another authoritative source, and ensure the final URL is either relative or matches the allowlist exactly.

Below is a concrete NestJS example using the AWS SDK for JavaScript v3 with DynamoDB. The code retrieves allowed redirect domains from a DynamoDB table and only proceeds if the user-supplied key resolves to a permitted domain.

import { DynamoDBClient, GetItemCommand, GetItemCommandInput } from "@aws-sdk/client-dynamodb";
import { unmarshall } from "@aws-sdk/util-dynamodb";
import { Injectable, BadRequestException } from "@nestjs/common";

@Injectable()
export class RedirectService {
  private readonly client = new DynamoDBClient({});

  async getAllowedDomains(tableName: string): Promise {
    const input: GetItemCommandInput = {
      TableName: tableName,
      Key: {
        id: { S: "redirect_policy" },
      },
    };
    const command = new GetItemCommand(input);
    const response = await this.client.send(command);
    if (!response.Item) {
      return [];
    }
    const item = unmarshall(response.Item);
    return Array.isArray(item.allowedDomains) ? item.allowedDomains : [];
  }

  resolveRedirect(url: string, allowedDomains: string[]): string {
    try {
      const target = new URL(url, "https://myapp.example");
      if (!allowedDomains.includes(target.hostname)) {
        throw new BadRequestException("Redirect target not allowed");
      }
      return target.toString();
    } catch (err) {
      if (err instanceof BadRequestException) {
        throw err;
      }
      throw new BadRequestException("Invalid redirect URL");
    }
  }
}

In this approach, the application loads allowed domains from DynamoDB and resolves the user-provided URL against that allowlist before performing any redirect. The use of the WHATWG URL constructor ensures proper parsing and prevents bypass via malformed inputs. The response returns a safe, absolute URL only when the hostname matches an explicitly permitted domain stored in DynamoDB.

Additional hardening steps include enforcing relative paths for internal redirects, setting Referrer-Policy and Content-Security-Policy headers, and validating that no open redirect vectors exist in downstream services that may be called after the redirect. Regular scans that include checks for open redirect patterns alongside DynamoDB access reviews help ensure that policy changes in the database do not introduce new risks.