Tu equipo de seguridad probablemente cree que Cloudflare es una muralla impenetrable. Que detrás del WAF, el rate limit y el “Verifying you are human” de Turnstile, nadie llega a tu app.
La realidad es más incómoda: hay dos tipos de tráfico que sí pasan. Los bots legítimos autenticados (GoogleBot, GPTBot, ClaudeBot) y los atacantes profesionales con presupuesto.
Si tu WAF está en plan Pro o Business, tu superficie es idéntica a la de cualquier sitio sin Cloudflare desde el punto de vista de un atacante con $50/mes en proxies residenciales. Y este post te lo voy a demostrar — éticamente — con la cascada que ejecutamos cada día.
Por qué necesitas auditar atrás de Cloudflare
Si tu sitio está detrás de Cloudflare, un audit que no pueda llegar al backend te miente. Te dice que estás “seguro” porque lo que ve es la respuesta del WAF, no de tu app.
Casos donde esto explota:
- WordPress/Joomla con plugin vulnerable: Cloudflare bloquea bots conocidos, pero un atacante con browser real explota el RCE.
- Headers de seguridad faltantes en backend: si Cloudflare los añade vía Transform Rules y un día desactivas la regla, todos tus headers desaparecen sin que lo sepas.
- TLS misconfiguration en origen: Cloudflare oculta tu certificado real. Si el cert del origen está expirado o mal configurado, no lo detectas.
- Subdominios sin proxy CF activado: el atacante encuentra
dev.tudominio.comostaging.tudominio.comapuntando directo a la IP de origen, sin Cloudflare delante.
Por eso Pentest C360 implementa bypass cascade ético: para auditar lo que el atacante ve, no lo que el WAF te muestra.
Las 6 capas de la cascada (y por qué cada una existe)
El bypass está documentado públicamente en docs/CASCADAS-2026-05-03.md. Las 6 capas en orden de invocación:
| Tier | Método | Cuándo dispara | Latencia |
|---|---|---|---|
| 1 | httpx-direct |
Sin proxy, primera intención | < 500 ms |
| 2 | scrapling-fetcher |
curl_cffi + Google referer | 1-3 s |
| 3 | httpx-residential |
Proxy residencial 2captcha (50 endpoints US) | 2-5 s |
| 4 | scrapling-stealthy |
StealthyFetcher con solve_cloudflare=True |
17-19 s |
| 5 | turnstile-solver |
2captcha API resuelve Turnstile + reusa cookie | 30-60 s |
| 6 | playwright |
Chromium 129 headless con browser real | 25-40 s |
Tier 1: httpx-direct
Sin trucos. Petición HTTP normal con headers limpios. El 64% de sitios “protegidos por Cloudflare” responden OK porque el WAF no los desafía sin razón.
Tier 2: scrapling-fetcher
Cuando Tier 1 recibe 403 o challenge. Scrapling es una librería Python open-source que usa curl_cffi para emitir TLS fingerprint idéntico a Chrome real. Combinado con Referer: https://www.google.com/search?q=..., supera el WAF estricto que detecta requests automatizados por su TLS handshake.
Tier 3: httpx-residential
Si Tier 2 falla, rotamos a un pool de 50 IPs residenciales (proxies whitelisteados por IP, US). El bypass funciona porque Cloudflare scoring distingue datacenter IPs de residentials. Una IP residencial con TLS fingerprint humano + cookies persistentes pasa.
Tier 4: scrapling-stealthy (PRINCIPAL para Turnstile)
El game-changer de mayo 2026. StealthyFetcher.fetch(solve_cloudflare=True) resolvió Cloudflare Turnstile interactivo + managed challenge real en 17-19 segundos sin pagar API. Antes de esto, había que pagar 2captcha ($0.0029-0.005 por solve). Ahora es gratis con Patchright + Playwright stealth.
Documentación bench oficial: docs/CASCADAS-2026-05-03.md.
Tier 5: turnstile-solver
Si Stealthy falla y detectamos sitekey de Turnstile, lo enviamos a 2captcha API humana real. Cookie cf_clearance válida por 30 minutos. Costo por audit: ~$0.005.
Tier 6: playwright
Browser Chromium 129 real, headless, con anti-detección (navigator.webdriver = false, plugins fake, WebGL canvas spoofing). Última instancia. Tarda 25-40s pero siempre funciona si el sitio realmente carga en un browser real.
Por qué esto es ético (y cuándo no lo es)
La diferencia entre pentest ético y scraping abusivo está en 3 reglas:
-
Autorización explícita del dueño del dominio. Pentest C360 verifica con DNS TXT
_c360-pentest.<host>o file/.well-known/c360-pentest-authorization.txt. Sin esto, el motor se rehúsa. -
Rate limit conservador. Default 1 request/2s, máximo 10 páginas por sesión. Esto no impacta el sitio.
-
Identificación clara. User-Agent:
Pentest-C360/0.13 (+https://pentest.cedula360.tech/audits). Si el dueño quiere bloquearnos, puede en surobots.txto WAF.
Sin las 3 reglas, es ataque, no audit. La diferencia legal:
- En Colombia: Ley 1273 de 2009 (delitos informáticos). Acceso abusivo a sistema informático = pena de 48-96 meses.
- En México: Código Penal Federal Art. 211 bis 1-7. Acceso ilícito = 6 meses a 8 años.
- En EU: GDPR + Computer Misuse Act (UK). Multas de millones.
El pentest ético tiene autorización. El bypass sin autorización es delito en cualquier jurisdicción.
Lo que tu WAF NO te dice
Cloudflare (y AWS WAF, Akamai, Fastly) no son omnipotentes. Estos son los gaps reales que detectamos en cada audit:
1. Subdominios sin proxy
dev.midominio.com → resuelve directo a IP origen. Ningún WAF protege. Pentest C360 enumera con subfinder + httpx + crt.sh y prueba cada uno individualmente.
2. Headers que CF añade vs los que tu app emite
Si CF añade Strict-Transport-Security vía Transform Rule pero tu app no lo emite, el día que cambies de plan o muevas a otro CDN, todo se cae. Audit detecta diferencia.
3. Origen IP exposed
Buscador histórico (crt.sh, securitytrails, viewdns) revela IPs antiguas. Atacante salta CF apuntando a esa IP. Tu app responde con Host: midominio.com y devuelve contenido.
4. Page rules / Workers que filtran demasiado o muy poco
Worker que bloquea /admin solo en path exacto. Atacante prueba /admin/, /admin/index.php, /Admin, /ADMIN, %41dmin. Uno pasa.
5. Rate limit en endpoints sensibles
/api/login tiene rate limit de 10/min. /api/v2/login no. Tu nuevo developer creó la v2 sin notificar al equipo de seguridad.
El test del minuto
Para saber si tu Cloudflare te está protegiendo realmente, pregúntate:
- ¿Tienes lista actualizada de todos los subdominios activos que apuntan a tu app? (Si dudas, gap)
- ¿Tu IP origen aparece en
crt.shpara*.midominio.comcerts históricos? (Probablemente sí, gap) - ¿Tienes los headers de seguridad emitidos por la app, no solo añadidos por CF? (Si solo CF, gap)
- ¿Tu WAF rule “block known bots” bloquea GPTBot, Claude-Web, Perplexity-Bot o solo bots de scraping? (Si bloquea legítimos, gap inverso)
Cualquier “no” es un punto de entrada documentado en cada audit que ejecutamos.
El takeaway honesto
Cloudflare es buena defensa. No es defensa absoluta. La diferencia entre estar tranquilo y estar protegido es medirlo desde la perspectiva del atacante, no desde la del WAF.
Pentest C360 hace eso éticamente con cascada de 6 niveles, todos open-source o documentados. El primer audit es gratis y te da el mapa de:
- Subdominios expuestos sin protección
- IPs origen históricas filtradas
- Headers que solo CF añade
- Rate limits inconsistentes
- Endpoints que el WAF no cubre
El motor que documenta este blog auditó 31 dominios reales con CF y sin CF. Risk score promedio bajó de 47.3 a 0.0. El bypass funcionó en el 100% de casos donde había autorización válida.
Si tu equipo de seguridad cree que Cloudflare es suficiente, dales este post. Si quieres validarlo en tu sitio, ejecuta el audit. Los hallazgos los validas tú con SSL Labs, Mozilla Observatory, y los logs de tu propio Cloudflare. Sin cajas negras.
Audita un sitio protegido por Cloudflare con cascada de 6 niveles
El motor que documenta este blog es el mismo que llevó 31 dominios al 100% saludable en 3 jornadas. Bypass Cloudflare, IA propia, MTTR cuantificado, comparativa con sitio modelo. Resultados verificables.
Audita mi sitio gratis →