How to Fix Server-Side Request Forgery (SSRF) in Remix
Learn how to prevent and fix Server-Side Request Forgery (SSRF) vulnerabilities in Remix 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 Remix
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).
Remix-Specific Advice
- Remix loaders and actions run on the server. Keep secrets in server-only code and never return sensitive data that the client does not need.
- Validate all action form data using Zod or similar. Remix actions are public endpoints that accept form submissions.
- Use Remix's built-in `createCookieSessionStorage` for secure session management with HttpOnly, Secure, and SameSite attributes.
- Implement CSRF protection using Remix's convention of checking the Origin header or using a CSRF token library.
Remix Security Checklist for Server-Side Request Forgery (SSRF)
Remix Security Best Practices
Remix loaders and actions run on the server. Keep secrets in server-only code and never return sensitive data that the client does not need.
Validate all action form data using Zod or similar. Remix actions are public endpoints that accept form submissions.
Use Remix's built-in `createCookieSessionStorage` for secure session management with HttpOnly, Secure, and SameSite attributes.
Implement CSRF protection using Remix's convention of checking the Origin header or using a CSRF token library.
Sanitize data returned from loaders before rendering. While Remix auto-serializes loader data, the rendered output must still be safe.
Use `defer()` and `Await` carefully -- ensure deferred data does not expose sensitive information in error states.
Implement route-level authorization in loaders. Throw `redirect()` or `json({ error }, { status: 403 })` for unauthorized access.
Configure security headers using Remix's `entry.server.tsx` or a reverse proxy. Set CSP, HSTS, and X-Frame-Options.
Scan Your Remix App with SafeVibe
Stop guessing if your Remix app is vulnerable to Server-Side Request Forgery (SSRF). Run an automated penetration test in minutes and get actionable results.
Start Free Scan