Ssrf on Cloudflare

Server-Side Request Forgery (SSRF) in Cloudflare contexts typically arises when an internal or edge-facing service within Cloudflare’s infrastructure makes outbound HTTP requests to user-supplied URLs without adequate validation. For example, a Cloudflare Worker that accepts a target URL to fetch resources on behalf of a user can be abused if the URL is not strictly sanitized. Attack patterns include using metadata services (e.g., 169.254.169.254) to obtain instance credentials, SSRF-to-SSRF pivoting through internal Cloudflare services, or leveraging SSRF to bypass IP-based ACLs that assume loopback or RFC1918 addresses are safe. In Cloudflare-specific code paths, such Workers or Durable Objects may call fetch() or similar HTTP clients with unchecked input, enabling an attacker to probe internal Cloudflare administrative endpoints or third-party services reachable only from within Cloudflare’s network. This can lead to information disclosure or, in some configurations, lateral movement within Cloudflare’s segmented environments.

Detecting SSRF in Cloudflare environments requires validating that outbound requests from Workers or other serverless components do not reach sensitive internal endpoints. Indicators of misconfiguration include Workers that accept raw URLs and perform HTTP requests without URI parsing and allowlist checks, or logs showing requests to 169.254.169.254, metadata services, or internal Cloudflare IP ranges. To detect this with middleBrick, submit the Worker’s public endpoint URL to the scanner; the tool runs unauthenticated black-box tests including SSRF probes among its 12 parallel security checks. middleBrick’s OpenAPI/Swagger spec analysis (supporting 2.0, 3.0, and 3.1 with full $ref resolution) cross-references runtime behavior with declared schemas to highlight endpoints that accept arbitrary URLs and lack input validation constraints. The findings include severity ratings and remediation guidance, helping you confirm whether SSRF risks exist in your Cloudflare-hosted APIs without requiring credentials or agent installation.

Remediation focuses on strict input validation and leveraging Cloudflare Workers’ built-in capabilities. Always parse and validate user-supplied URLs using the Cloudflare Workers URL API, enforce an allowlist of permitted hosts, and avoid forwarding raw user input to fetch(). For example, use the URL constructor to validate and extract hostname, then compare against a strict set of allowed domains. Additionally, disable protocols that are unnecessary (e.g., file://) and prefer fetch options that limit redirects and set timeouts. Below are concrete code examples for a Cloudflare Worker that safely proxies requests only to allowed hosts.

Example 1: Validate URL hostname against an allowlist in a Cloudflare Worker

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

async function handleRequest(request) {
  const url = new URL(request.url)
  const allowedHosts = new Set(['api.example.com', 'cdn.example.com'])

  if (!allowedHosts.has(url.hostname)) {
    return new Response('Forbidden: Host not allowed', { status: 403 })
  }

  // Optionally rewrite path or headers before fetching
  const target = new URL(url.pathname + url.search, 'https://' + url.hostname)
  const response = await fetch(target, {
    method: 'GET',
    redirect: 'manual',
    cf: { cacheTtl: 3600 }
  })
  return response
}

Example 2: Reject dangerous protocols and enforce path sanitization

async function safeFetch(userUrl) {
  const parsed = new URL(userUrl, 'https://fallback.example.com')
  const blockedProtocols = ['file:', 'ftp:']
  if (blockedProtocols.includes(parsed.protocol)) {
    throw new Error('Blocked protocol')
  }
  // Ensure path does not traverse
  const safePath = parsed.pathname.split('/').filter(Boolean).join('/')
  const target = new URL('/' + safePath, parsed.origin)
  return fetch(target, { method: 'POST', body: parsed.searchParams.toString() })
}

addEventListener('fetch', event => {
  event.respondWith(
    (async () => {
      try {
        return await safeFetch(event.request.url)
      } catch (e) {
        return new Response(e.message, { status: 400 })
      }
    })()
  )
})

These patterns ensure that only intended destinations are reachable, mitigating SSRF risks within Cloudflare Workers. For broader protection across APIs, the middleBrick Pro plan includes continuous monitoring and CI/CD integration to detect regressions; you can add API security checks to your pipeline using the GitHub Action to fail builds if risk scores exceed your threshold, while the MCP Server enables scanning APIs directly from your AI coding assistant within the IDE.