Securing URLs: SSRF, Open Redirects, and Validation

Securing URLs: SSRF, Open Redirects, and Validation

URLs in user-supplied input are a recurring attack vector. Server-side request forgery (SSRF) occurs when a server makes an HTTP request to a URL controlled by an attacker, potentially reaching internal services on the server's network. Open redirect vulnerabilities allow attackers to craft URLs on your domain that forward users to malicious sites. Both attacks rely on insufficient URL validation because they accept URLs that look legitimate but resolve to unintended destinations.

Defending against URL-based attacks requires validating scheme, host, and resolved IP address rather than just the surface-level string. Percent-encoding, IPv6 addressing, DNS rebinding¹, and redirect chains are all used to bypass naive validation checks.

Preventing server-side request forgery (SSRF)

SSRF occurs when user-controlled URL input reaches a server-side HTTP client. Validate that the URL's scheme is http or https, then resolve the hostname to an IP address and check that the IP is not in a private range: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, ::1, and cloud metadata IPs like 169.254.169.254¹.

Why request-time validation matters more than validation-time checks

Consequently, perform the IP check at request time, not at validation time, because DNS rebinding can change what an IP resolves to between checks. Building on this, avoid following redirects automatically for user-supplied URLs; validate the Location header at each hop using the same IP-range checks. This defense-in-depth approach ensures that even if one layer is bypassed, the next layer catches the attack before any outbound request is made.

Your validation layer should treat every DNS resolution as a fresh security decision. Even if the IP was safe milliseconds ago, the next resolution could point to an internal metadata endpoint. Treat each request as a new validation event. DNS rebinding attacks exploit the gap between validation and request execution by swapping the resolved address to an internal IP after your initial check passes. Caching the validation result defeats the entire purpose of request-time IP verification because the attacker controls the TTL and can force a fresh resolution at the moment of attack.

Preventing open redirect vulnerabilities

An open redirect allows an attacker to craft a URL like https://example.com/redirect?url=https://evil.com that your server forwards users to. The fix is to validate the redirect target against an allowlist of trusted domains or to use a relative path instead of an absolute URL². Building on this, check the parsed URL, not the raw string, because percent-encoding and Unicode lookalike characters can bypass string-level checks. Verify that the URL's hostname exactly matches an allowed domain after parsing with a standards-compliant URL library. Consequently, do not pass user input through a redirect parameter at all if you can use session state or path-based routing instead.

Encoding attacks and parser differentials

URL parsing inconsistencies between different components of your stack can create security gaps. A web application firewall may parse a URL differently than the backend application, allowing an attacker to slip through a malicious path using double-encoding (%252F for /) or unusual normalization. Consequently, normalize all URLs before validation: decode percent-encoding once, resolve dot-segments, and canonicalize the host. Spot a URL that hides its real host after @ before you trust the domain shown in a link: some URL parsers treat @ in the path as a userinfo separator, so https://[email protected]/ may parse as a URL to evil.com with safe.com as userinfo². Always check the parsed hostname, not the raw string, because the hostname is the security boundary that determines which server the request reaches.

URL parsing differentials between application layers

A URL that passes validation in one layer of your stack may be interpreted differently in another. A web application firewall that parses URLs with a custom regex sees https://example.com%2F..%2Fadmin as a request to /admin. Your application framework, using the WHATWG URL Standard, sees it as a path containing literal %2F characters pointing to /..%2Fadmin³. This parsing differential lets attackers bypass WAF rules. Normalize all URLs at the WAF layer before comparison: decode percent-encoding once, resolve dot-segments, and then compare the canonical form against your blocklist.

URL-based denial of service via parser edge cases

Specially crafted URLs can cause excessive CPU consumption in URL parsers. A path containing thousands of dot-segments (/a/b/c/../../../../...) forces the parser to iterate through every segment during normalization. Attackers exploit this by sending URLs with thousands of nested dot-segments, causing CPU spikes on the server. Set a maximum URL length (most frameworks default to 8 KB) and a maximum number of path segments in your web server or reverse proxy configuration. Nginx's large_client_header_buffers directive controls the maximum request URI length; set it to reject URLs longer than 8 KB before they reach your application code⁴.

Secure URL handling in server-side rendering frameworks

Server-side rendering frameworks (Next.js, Nuxt, SvelteKit) that accept URLs from user input must sanitize before rendering into HTML. A meta tag like <meta property="og:url" content="{{ userUrl }}"> is vulnerable to XSS if userUrl contains javascript: or an unescaped ". Sanitize user-supplied URLs by parsing with new URL(), validating the protocol is http: or https:, and then HTML-escaping the serialized URL before embedding it in markup. Next.js's built-in URL handling does not automatically sanitize; you must add explicit validation in getServerSideProps or API routes.

Subresource integrity for external URL references

When your page loads scripts, stylesheets, or images from external URLs, Subresource Integrity (SRI) ensures the resource has not changed since the hash was generated. Add the integrity attribute to script and link tags: <script src="https://cdn.example.com/lib.js" integrity="sha384-abc123..." crossorigin="anonymous"></script>. The browser fetches the resource, computes its SHA-384 hash, and compares against the declared value⁵. A compromised CDN serving modified JavaScript will fail the integrity check and the browser will refuse to execute the script. Generate integrity hashes at build time using tools like sri-hash or webpack-subintegrity, and update them whenever the external resource changes because serving a new script with an old hash will cause the browser to block execution.

When to use this

Apply URL security checks whenever your application accepts URLs from users, configuration files, webhooks, or third-party APIs and uses them in HTTP requests, redirects, link href attributes, or server-rendered markup.

Examples

// Wrong: string check bypassed by https://[email protected]
function safeRedirect(url) {
  if (url.includes("example.com")) window.location = url;
}

// Correct: parse and check the hostname
function safeRedirect(url) {
  try {
    const parsed = new URL(url);
    const ALLOWED = ["example.com", "www.example.com"];
    if (ALLOWED.includes(parsed.hostname)) window.location = url;
  } catch { /* invalid URL — reject silently */ }
}