Ssrf Server Side in Adonisjs with Dynamodb
Ssrf Server Side in Adonisjs with Dynamodb — how this specific combination creates or exposes the vulnerability
Server-side request forgery (SSRF) in an AdonisJS application that interacts with Amazon DynamoDB can occur when the application constructs HTTP requests to external services using data supplied by the user. If an attacker can influence the URL or host used during an HTTP call—such as when fetching a remote schema, webhook URL, or metadata endpoint—AdonisJS may inadvertently make requests to internal AWS metadata services or to DynamoDB endpoints that should not be reachable from the public internet.
AdonisJS does not provide built-in SSRF protection; developers must validate and sanitize any user-controlled inputs that affect network destinations. When such inputs are used to configure an HTTP client (for example, to call a DynamoDB-compatible service or to introspect a schema), an attacker may supply internal IPs or AWS metadata endpoints (169.254.169.254). Because DynamoDB traffic typically occurs over HTTPS, developers may mistakenly assume that any request using HTTPS is safe, but SSRF is about the destination, not the protocol.
In a typical AdonisJS app, you might use an HTTP client to call DynamoDB’s Data Plane or a wrapper around AWS SDK behaviors. If the endpoint or region is derived from user input without strict allowlisting, an SSRF vector is introduced. For example, an attacker might provide a URL that points to the EC2 instance metadata service to obtain temporary credentials, or to an internal service that exposes DynamoDB-compatible APIs. Even when using the AWS SDK for JavaScript, if the SDK configuration (such as the endpoint or custom agent) is influenced by user data, SSRF can occur.
Because middleBrick scans the unauthenticated attack surface, an SSRF issue may appear in findings such as Server Side Request Forgery if the scanner detects that an endpoint allows user-supplied URLs in a way that can lead to internal network interaction. The scan does not exploit or modify anything; it detects that a path exists for an attacker to direct server-side requests to unintended hosts, including AWS metadata or internal DynamoDB proxy endpoints.
Remediation guidance centers on input validation and network segregation: never use raw user input to construct request URLs, endpoints, or hosts; prefer allowlists for protocols and hosts; and avoid making outbound requests to internal AWS metadata from application code. When integrating with DynamoDB, ensure that any client configuration is static or strictly controlled, and that outbound requests are limited to known AWS endpoints via VPC endpoints or restrictive egress rules.
Dynamodb-Specific Remediation in Adonisjs — concrete code fixes
To prevent SSRF when your AdonisJS app interacts with DynamoDB, control the configuration of the AWS SDK and avoid dynamic endpoint or host construction. Use environment variables for region and endpoint, and validate any user input against strict allowlists before it influences network behavior.
Example: safe DynamoDB client setup in AdonisJS using the AWS SDK for JavaScript (v3):
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { fromEnv } from "@aws-sdk/credential-providers";
const region = process.env.AWS_REGION || "us-east-1";
// Do NOT derive region or endpoint from user input
const client = new DynamoDBClient({
region,
credentials: fromEnv(),
// Avoid custom endpoint overrides from user data
});
export { client };
Example: validating a table name input before use (allowlist approach):
const ALLOWED_TABLES = ["users", "products", "orders"];
function getTableConfig(tableName) {
if (!ALLOWED_TABLES.includes(tableName)) {
throw new Error("Invalid table name");
}
return {
TableName: tableName,
};
}
// In a controller
async show({ request }) {
const { tableName, key } = request.only(["tableName", "key"]);
const params = getTableConfig(tableName);
const command = new GetCommand({ ...params, Key: { id: { S: key } } });
return await client.send(command);
}
Example: rejecting user-supplied URLs for external calls (e.g., webhooks or schema fetches):
const allowedHosts = ["https://api.yourservice.com"];
function validateUrl(input) {
const parsed = new URL(input);
if (!allowedHosts.includes(parsed.origin)) {
throw new Error("Host not allowed");
}
return parsed.toString();
}
// Usage
const target = validateUrl(request.input("webhookUrl"));
// Proceed only if validation passes
By combining these patterns—static SDK configuration, strict allowlists for table names, and whitelisted hosts—you reduce the attack surface for SSRF in an AdonisJS/DynamoDB stack. middleBrick can verify these controls by scanning the API endpoints and confirming that no user input directly influences network destinations.