Open Redirect in Loopback with Dynamodb

An open redirect in a Loopback application that uses DynamoDB for user or configuration data can occur when an endpoint accepts a user-supplied URL or hostname and then uses DynamoDB-stored values to construct a redirect without strict validation. For example, a consent or settings endpoint might retrieve a redirect_uri from a DynamoDB table keyed by client_id and then perform a server-side or client-side redirect. If the stored URI is attacker-controlled (e.g., set via compromised credentials or a misconfigured admin workflow) or the endpoint reflects an untrusted parameter directly into the redirect, an attacker can supply a malicious redirect URL that bypasses intended allowlists.

DynamoDB itself does not execute logic, so the vulnerability arises from application logic that reads items (e.g., GetItem or Query) and uses attribute values in Location headers or frontend redirects without canonicalization and allowlisting. In Loopback, a common pattern is to fetch a client configuration record containing redirect URIs; if an attacker can poison that record (through compromised API keys, SSRF to DynamoDB metadata, or weak IAM policies), they can cause the application to redirect users to phishing sites. Even unauthenticated endpoints that expose redirect_uri as a query parameter can be abused if the application does not validate the parameter against a strict pattern or a server-side allowlist stored in DynamoDB.

Consider an OAuth callback route that reads a client record from DynamoDB and redirects to the stored redirect_uri. If the stored value is not validated against a whitelist of origins, an attacker who can modify the DynamoDB item (e.g., via leaked credentials or a misconfigured IAM role) can redirect users to arbitrary sites. Additionally, if the route reflects a user-controlled redirect parameter without normalization, an attacker can provide a URL like http://localhost:8080/evil that the server treats as an external redirect due to missing hostname resolution checks. This becomes more impactful when combined with confused deputy patterns, where a trusted internal service uses DynamoDB-stored URIs to perform redirects on behalf of less trusted contexts.

Remediation centers on strict validation of redirect targets and isolating DynamoDB-derived values from open redirects. Always validate resolved hostnames against a strict allowlist and prefer storing canonical redirect URIs in DynamoDB rather than reflecting user input. Use server-side resolution to ensure that values like hostnames are compared to known safe origins rather than trusting raw input.

Example: secure OAuth callback in Loopback with DynamoDB-stored client config.

const {DynamoDBClient, GetItemCommand} = require('@aws-sdk/client-dynamodb');
const {marshall, unmarshall} = require('@aws-sdk/util-dynamodb');

const client = new DynamoDBClient({region: 'us-east-1'});

async function getClientConfig(clientId) {
  const cmd = new GetItemCommand({
    TableName: process.env.CLIENT_CONFIG_TABLE,
    Key: marshall({client_id: {S: clientId}})
  });
  const resp = await client.send(cmd);
  return resp.Item ? unmarshall(resp.Item) : null;
}

app.get('/oauth/callback', async (req, res) => {
  const {client_id, redirect_uri} = req.query;
  const config = await getClientConfig(client_id);
  if (!config) {
    return res.status(400).send('invalid_client');
  }

  // canonicalize and validate redirect_uri against stored config, not raw user input
  const allowedOrigins = new Set(config.allowed_redirect_uris || []);
  const target = new URL(redirect_uri || config.default_redirect_uri);
  if (!allowedOrigins.has(target.origin)) {
    return res.status(400).send('invalid_redirect');
  }

  // server-side safe redirect: ensure target is absolute and origin matches allowlist
  res.redirect(302, target.toString());
});

Key points: resolve the hostname via URL parsing, compare against a set of allowed origins stored in DynamoDB, and avoid directly using user-supplied redirect_uri in the Location header without validation. For Loopback routes that use DynamoDB, prefer storing only origins (not full mutable URLs) and enforce strict Content Security Policy and Referrer-Policy headers to reduce impact if a bypass occurs.