Credential Stuffing on Cloudflare

Credential stuffing leverages previously breached username and password pairs to gain unauthorized access to accounts protected by Cloudflare-protected origins. When a request passes through Cloudflare, the attack typically targets application login endpoints behind a zone, relying on Cloudflare’s proxy to obscure the origin IP and increase resilience against automated mitigation. Attackers may rotate user agents and IPs via Cloudflare’s own anti-bot challenge bypass techniques, attempting to avoid detection by rate-limiting or bot challenges.

Within Cloudflare configurations, credential stuffing often interacts with specific request paths such as /login, /signin, or custom authentication routes that are proxied through Cloudflare. If the origin application lacks strong rate limiting or adaptive authentication, the requests appear as normal traffic to Cloudflare, which forwards them to the backend. Attack scripts may include Cloudflare-specific headers like CF-Connecting-IP and CF-Ray to mimic legitimate traffic patterns. Without inspecting request semantics beyond IP reputation, Cloudflare’s default settings may not flag these as suspicious, allowing automated login attempts to proceed until account lockout or other controls intervene.

Notably, attackers may exploit Cloudflare Workers or custom serverless functions that handle authentication logic if those endpoints do not enforce strict access controls or anomaly detection. For instance, a Worker that accepts a JSON payload with email and password and returns a session token can be targeted directly. If the Worker does not integrate additional signals such as device fingerprinting or behavioral analysis, credential stuffing scripts can iterate credentials at scale against that endpoint.

Detecting credential stuffing against Cloudflare-protected services requires correlating Cloudflare logs with application-level signals. middleBrick scans the unauthenticated attack surface of a Cloudflare-proxied API or web application, testing authentication flows and analyzing how the endpoint reacts to repeated login attempts without valid credentials. During a scan, middleBrick’s Authentication and Rate Limiting checks simulate credential stuffing patterns by submitting multiple login requests with varying credentials to endpoints behind Cloudflare, looking for responses that indicate successful authentication or insufficient rate limiting.

To identify credential stuffing risks, configure middleBrick to target the login URL behind Cloudflare (e.g., https://example.com/login) and observe whether responses differ based on credential validity. Pay attention to HTTP status codes, response times, and the presence of Cloudflare-specific headers that may indicate challenge bypass or rate limit triggers. middleBrick’s OpenAPI/Swagger spec analysis can further map authentication paths and highlight weak or unauthenticated routes that should be protected. If your API provides an OpenAPI specification under https://example.com/openapi.json, middleBrick resolves all $ref references and cross-references spec definitions with runtime findings to surface risky endpoints.

In addition to automated scans, review Cloudflare dashboards for anomalies such as spikes in requests per IP, repeated challenges, or geographic anomalies. middleBrick’s findings include severity and remediation guidance, helping prioritize fixes such as tightening rate limits or enforcing stronger authentication mechanisms on Cloudflare-accessible endpoints.

Remediation for credential stuffing in Cloudflare environments focuses on hardening authentication endpoints and leveraging Cloudflare’s native features to detect and block abusive patterns. Ensure that login routes enforce strong account lockout policies and require multi-factor authentication where possible. Use Cloudflare Access to define identity-aware policies that restrict access based on user identity rather than IP alone. Implement custom rules in Cloudflare WAF to challenge requests that exhibit credential stuffing characteristics, such as high request rates from a single session or repeated failures for different usernames.

At the application level, integrate Cloudflare’s SDKs and libraries to validate and throttle authentication requests. For example, when using Cloudflare Workers, enforce rate limiting within the Worker code and bind authentication logic to trusted origins. Below is a code example of a Cloudflare Worker that incorporates rate limiting using the Cloudflare Workers KV store to mitigate credential stuffing:

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

async function handleRequest(event) {
  const url = new URL(event.request.url)
  if (url.pathname === '/login' && event.request.method === 'POST') {
    const ip = event.request.headers.get('CF-Connecting-IP')
    const key = `login_attempts:${ip}`
    const current = await LOGIN_ATTEMPTS.get(key, { type: 'json' }) || { count: 0, last: Date.now() }
    if (current.count >= 10) {
      const now = Date.now()
      // Reset after 1 hour
      if (now - current.last < 3600_000) {
        return new Response('Too many attempts', { status: 429 })
      }
      await LOGIN_ATTEMPTS.put(key, JSON.stringify({ count: 0, last: now }))
    }
    const body = await event.request.json()
    // Validate credentials with your auth provider
    const valid = await validateCredentials(body.email, body.password)
    if (!valid) {
      await LOGIN_ATTEMPTS.put(key, JSON.stringify({ count: current.count + 1, last: now }))
      return new Response('Invalid credentials', { status: 401 })
    }
    await LOGIN_ATTEMPTS.put(key, JSON.stringify({ count: 0, last: now }))
    return new Response('OK')
  }
  return fetch(event.request)
}

Additionally, enforce secure password policies and integrate with identity providers that support adaptive authentication. Combine Cloudflare’s bot management capabilities with application-level signals to improve detection accuracy. middleBrick’s Pro plan supports continuous monitoring for such endpoints, enabling scheduled scans and alerts if risk scores degrade, while the GitHub Action can fail builds when changes introduce new authentication weaknesses.