How to Fix Server-Side Request Forgery (SSRF) in Express
Learn how to prevent and fix Server-Side Request Forgery (SSRF) vulnerabilities in Express applications. Step-by-step guide with code examples, security checklists, and best practices.
What Is Server-Side Request Forgery (SSRF)?
Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can cause the server-side application to make HTTP requests to an arbitrary URL chosen by the attacker. The server becomes a proxy, making requests from its own network position, which typically has access to internal services, cloud metadata endpoints, and private network resources that are not directly accessible from the internet.
SSRF attacks exploit any server-side functionality that fetches remote resources based on user-supplied URLs. Common attack surfaces include: URL preview/unfurling features (link previews in chat applications); webhook configurations; file import from URL; PDF generation from URLs; image processing that fetches remote images; and API integrations where the target URL is user-controlled.
In cloud environments (AWS, GCP, Azure), SSRF is particularly dangerous because cloud metadata services (e.g., `http://169.254.169.254`) are accessible from the server and can expose temporary credentials, instance configurations, and secrets. The 2019 Capital One breach, which exposed 100 million records, was enabled by SSRF combined with overly permissive IAM roles.
Why It Matters
SSRF effectively gives attackers network access from the server's perspective. This can expose internal services that assume network-level trust (databases, caches, admin panels), cloud metadata endpoints containing credentials and configuration, private APIs and microservices not intended for external access, and resources behind firewalls or VPNs. In serverless environments, SSRF can access the function's IAM role credentials. The attack can be used for port scanning internal networks, accessing internal dashboards, reading local files (using file:// protocol), and pivoting deeper into the infrastructure.
How to Fix It in Express
Validate and sanitize all user-supplied URLs. Implement allowlists of permitted domains and IP ranges. Block requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8) and cloud metadata endpoints (169.254.169.254). Use a DNS resolution step before making requests and validate the resolved IP is not internal. Disable unnecessary URL schemes (only allow http/https). Use network segmentation to limit the server's access to internal resources. Implement IMDSv2 on AWS instances to require token-based metadata access. Run URL-fetching operations in isolated network environments. For webhook features, validate the URL at configuration time and at request time (DNS rebinding prevention).
Express-Specific Advice
- Use `helmet` middleware for setting security headers (CSP, HSTS, X-Frame-Options, etc.) with sensible defaults.
- Use `express-rate-limit` for rate limiting. Apply stricter limits to authentication endpoints and API routes.
- Always use parameterized queries with your database driver. Never concatenate user input into SQL strings.
- Validate request bodies using `express-validator`, Zod, or Joi middleware. Reject requests that do not match expected schemas.
Express Security Checklist for Server-Side Request Forgery (SSRF)
Express Security Best Practices
Use `helmet` middleware for setting security headers (CSP, HSTS, X-Frame-Options, etc.) with sensible defaults.
Use `express-rate-limit` for rate limiting. Apply stricter limits to authentication endpoints and API routes.
Always use parameterized queries with your database driver. Never concatenate user input into SQL strings.
Validate request bodies using `express-validator`, Zod, or Joi middleware. Reject requests that do not match expected schemas.
Use `cors` middleware with explicit origin allowlists. Never use `cors({ origin: '*' })` in production.
Disable the `X-Powered-By` header with `app.disable('x-powered-by')` or by using helmet.
Use `multer` or `busboy` for file uploads with strict file type and size limits. Store files outside the web root.
Implement proper error handling middleware that does not leak stack traces or internal details in production.
Scan Your Express App with SafeVibe
Stop guessing if your Express app is vulnerable to Server-Side Request Forgery (SSRF). Run an automated penetration test in minutes and get actionable results.
Start Free Scan