Open Redirect in Restify with Dynamodb

An Open Redirect in a Restify service that uses DynamoDB for session or user data can occur when a client-supplied URL or redirect target is stored in a DynamoDB item and later used without validation. For example, an application may store a return_to URL in a DynamoDB table keyed by a user ID after login, and later redirect the user to that value. If the stored URL is attacker-controlled and not validated, the application can redirect the user to a malicious site.

Consider a typical flow: after authentication, the client provides a redirect_uri that is saved into DynamoDB via the SDK, then the server reads the value and performs an HTTP redirect. If the redirect_uri is accepted from query parameters or a request body and persisted directly into DynamoDB without strict validation (e.g., allowlisting domains or enforcing absolute URL restrictions), an attacker can supply a malicious URL such as https://evil.example.com. When the server later retrieves that value from DynamoDB and issues a 302, the user is redirected to the attacker’s site.

DynamoDB itself does not introduce the redirect; it is a persistence mechanism that can inadvertently host malicious data supplied by an attacker. The risk is amplified when combined with features like pre-signed URLs or dynamic endpoint construction, where a stored value is used to build a redirect location. Attack patterns like this map to OWASP API Top 10:2023 – API1:2023 Broken Object Level Authorization when the stored redirect target is tied to user-controlled data, and can facilitate phishing or session fixation.

In a black-box scan, middleBrick checks whether a redirect location is derived from user input stored in back-end services such as DynamoDB. It looks for indications that untrusted data retrieved from DynamoDB is used in Location headers or client-side navigation without proper validation. This detection does not rely on internal architecture but on observable behavior: a redirect to a non-whitelisted domain after data retrieval from DynamoDB.

To remediate Open Redirect when using DynamoDB in Restify, validate and normalize any redirect target before storing it in DynamoDB and before using it in a redirect. Use an allowlist of trusted domains and ensure the URL is absolute, uses HTTPS, and does not contain unexpected ports or credentials. Below are concrete code examples for a secure Restify handler with DynamoDB integration.

import { DynamoDBClient, GetItemCommand, PutItemCommand } from "@aws-sdk/client-dynamodb";
import { marshall, unmarshall } from "@aws-sdk/util-dynamodb";
import { createServer } from "restify";

const client = new DynamoDBClient({});
const TABLE = process.env.TABLE_NAME;

function isSameOrigin(url, base = 'https://app.example.com') {
  try {
    const u = new URL(url, base);
    return u.origin === new URL(base).origin && u.protocol === 'https:';
  } catch {
    return false;
  }
}

async function getRedirectTarget(userId) {
  const cmd = new GetItemCommand({
    TableName: TABLE,
    Key: marshall({ userId: { S: userId } })
  });
  const res = await client.send(cmd);
  return res.Item ? unmarshall(res.Item).redirectUrl?.S : null;
}

async function saveRedirectTarget(userId, redirectUrl) {
  if (!isSameOrigin(redirectUrl)) {
    throw new Error('Invalid redirect URL');
  }
  const cmd = new PutItemCommand({
    TableName: TABLE,
    Item: marshall({ userId: { S: userId }, redirectUrl: { S: redirectUrl } })
  });
  await client.send(cmd);
}

const server = createServer();
server.post('/save-redirect', async (req, res, next) => {
  const { userId, redirectUrl } = req.body;
  try {
    await saveRedirectTarget(userId, redirectUrl);
    res.send(200, { ok: true });
  } catch (err) {
    res.send(400, { error: err.message });
  }
  return next();
});

server.get('/login-complete/:userId', async (req, res, next) => {
  const target = await getRedirectTarget(req.params.userId);
  const safeTarget = target || 'https://app.example.com/dashboard';
  res.setHeader('Location', safeTarget);
  res.send(302);
  return next();
});

server.listen(8080, () => console.log('API listening'));

In this example, isSameOrigin ensures only same-origin HTTPS URLs are stored in DynamoDB, preventing open redirects. The retrieval path reads from DynamoDB and applies the same validation before setting the Location header. For broader coverage, pair this with middleBrick scans that test whether DynamoDB-stored values can lead to open redirects. Plans such as the Pro tier support continuous monitoring so future changes to redirect logic are automatically assessed.

Additional hardening steps include: enforce strict Content-Security-Policy to mitigate malicious redirect impact, use short-lived pre-signed tokens instead of storing redirect URLs where possible, and log suspicious redirect attempts for audit. The GitHub Action can enforce a minimum score threshold on pull requests, and the MCP Server allows AI coding assistants to surface insecure patterns during development.