Ssrf Server Side on Cloudflare

Server-side request forgery (SSRF) in Cloudflare environments typically emerges when an attacker can influence a Cloudflare Worker or a backend service behind Cloudflare to make outbound requests to internal or restricted endpoints. Common attack patterns include leveraging internal metadata services (e.g., 169.254.169.254 on cloud VMs), internal Kubernetes services, or Cloudflare-specific internal APIs that may be inadvertently exposed. In Cloudflare Workers, this can occur when a Worker fetches a user-supplied URL without strict validation, allowing traversal to internal services not intended for public access.

Within Cloudflare-specific code paths, SSRF often surfaces in Workers that perform URL-based fetches, such as when building a request proxy or integrating with third-party APIs. For example, a Worker that accepts a target URL parameter and forwards requests can be abused if the parameter is not rigorously validated. An attacker might supply an internal IP address or a Cloudflare internal hostname to the Worker, causing the Worker to relay responses from internal endpoints. Another pattern involves Cloudflare Load Balancers or origin configurations where backend origin rules or custom scripts inadvertently allow internal resolution, enabling SSRF through crafted requests that bypass intended routing logic.

Specific Cloudflare code paths include Workers using the fetch API with user-controlled input, where the destination URL is derived from query parameters or headers without enforcing a strict allowlist. For instance, a Worker designed to fetch external resources might directly use request.headers.get('X-Target-URL') to determine the destination, creating a vector for SSRF if the header is controlled by an attacker. Additionally, Cloudflare's integration with origin services can expose internal endpoints when misconfigured health checks or internal APIs are reachable through the Worker runtime, especially if the Worker does not sanitize or restrict outbound destinations.

Detecting SSRF in Cloudflare environments requires analyzing both Worker code and runtime behavior. Key indicators include Workers that perform outbound fetches to internal IP ranges (such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), usage of internal metadata endpoints, or attempts to reach Cloudflare-specific internal hostnames. During scanning, middleBrick tests these scenarios by submitting payloads that probe internal endpoints, metadata services, and SSRF-prone patterns without requiring authentication, aligning with its black-box approach.

Using middleBrick, you can submit a Cloudflare Worker URL to initiate a scan that includes SSRF-specific probes among its 12 parallel checks. The tool tests input validation and outbound request handling by attempting internal endpoints such as http://169.254.169.254/latest/meta-data/ or internal service URLs that may be reachable from the Worker runtime. The scan returns findings with severity ratings and remediation guidance, helping to identify whether user-supplied URLs are improperly allowed to reach internal resources.

In the context of Cloudflare, middleBrick’s detection covers both the runtime behavior of Workers and the configuration of backend origins. By focusing on unauthenticated attack surfaces, it can reveal SSRF vulnerabilities that might be missed in traditional code reviews, especially where dynamic routing or proxy logic exists. The results include specific indicators, such as successful internal fetches or exposure of internal headers, mapped to relevant OWASP API Top 10 categories to prioritize remediation.

Remediation for SSRF in Cloudflare Workers centers on strict input validation and restricting outbound requests. Use allowlists for domains and IPs, avoid forwarding user-supplied URLs directly, and leverage Cloudflare's built-in features to enforce network boundaries. Workers provide access to the Request and Response APIs, which should be used in combination with explicit validation logic to ensure only approved destinations are fetched.

Below is a Cloudflare Worker example that demonstrates secure handling of target URLs using an allowlist and the Cloudflare fetch API with timeout and redirect controls:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

const ALLOWED_DOMAINS = new Set([
  'api.example.com',
  'cdn.example.com'
]);

async function handleRequest(request) {
  const url = new URL(request.url);
  const target = url.searchParams.get('url');
  if (!target) {
    return new Response('Missing target URL', { status: 400 });
  }

  const targetUrl = new URL(target);
  if (!ALLOWED_DOMAINS.has(targetUrl.hostname)) {
    return new Response('Domain not allowed', { status: 403 });
  }

  try {
    const response = await fetch(targetUrl.toString(), {
      method: 'GET',
      redirect: 'manual',
      cf: { timeout: 5000 }
    });
    return new Response(response.body, {
      status: response.status,
      headers: response.headers
    });
  } catch (err) {
    return new Response('Fetch error', { status: 502 });
  }
}

This code ensures that only requests to predefined domains are allowed, mitigating SSRF risks. It uses redirect: 'manual' to prevent automatic following of redirects to internal endpoints and sets a timeout via Cloudflare's cf option to limit request duration. For more complex integrations, combine this approach with environment-based allowlists and runtime checks that validate IP ranges against private address space patterns.

Additionally, review Cloudflare Access and Workers KV configurations to ensure internal endpoints are not inadvertently exposed. Use Cloudflare's dashboard to enforce zone-level restrictions and monitor outbound requests via logs to detect anomalous patterns that might indicate attempted SSRF exploitation.