Protección DDoS en portales: caché sin filtrar datos

La protección DDoS de un portal público empieza por separar la información que cualquiera puede leer de las acciones y los registros que pertenecen a una persona. Reduce el coste de servir las respuestas que hayas comprobado que son públicas mediante una red de distribución de contenidos, o CDN. Excluye del almacenamiento compartido las respuestas privadas y las que contienen credenciales. Después, comprueba que los candidatos y los investigadores de seguridad puedan completar sus envíos con los controles de tráfico activos.

Que una página de empleo cargue es solo una parte del proceso de selección. El candidato aún tiene que abrir un enlace privado, subir un archivo y recibir una confirmación que refleje lo ocurrido. Un investigador de seguridad necesita encontrar las instrucciones y enviar un informe confidencial. Proteger la primera página y bloquear los pasos posteriores deja fuera a las personas a las que querías atender.

Lo que sigue es una propuesta de revisión técnica para un equipo pequeño. Combina las lecciones de un incidente reciente con un ejercicio práctico que puedes adaptar a tu aplicación. No certifica la resistencia frente a ataques ni garantiza que una configuración de alojamiento concreta vaya a mantenerse disponible.

¿Qué aprendió Read the Docs de las peticiones sin caché?

Las peticiones que parecen triviales también pueden consumir recursos limitados de la aplicación. Empieza por las rutas que llegan al servidor de origen, donde se ejecuta tu aplicación. No des por hecho que las páginas más visitadas concentran todo el trabajo.

Read the Docs publicó su análisis del incidente el 8 de septiembre de 2026. El ataque ocurrió entre mediados y finales de junio y duró casi diez días. El proveedor describió un pico superior a 5,5 millones de peticiones por minuto, cambios en las firmas de las peticiones y tráfico dirigido a respuestas sin caché. Al principio, las redirecciones temporales llegaban al backend de Python; el equipo las trasladó a la infraestructura de borde. Las peticiones a rutas inexistentes y distintas entre sí también provocaban consultas costosas al origen. La respuesta incluyó verificaciones selectivas, porque aplicarlas a todos los lectores habría interrumpido las integraciones.

Esas observaciones describen Read the Docs, no Kit ni tu empresa. La pregunta útil para tu equipo es más concreta: ¿qué peticiones aparentemente baratas siguen obligando a trabajar a la aplicación?

Parte de un portal ficticio

Para este ejercicio, imagina una pequeña empresa de software con un portal público de empleo y un programa de divulgación de vulnerabilidades. Cualquiera puede leer la descripción de un puesto sin identificarse. Un candidato puede consultar su candidatura mediante un enlace privado. Un investigador puede leer la política de seguridad y enviar después información que debe mantenerse confidencial.

Pide a la persona responsable de selección, a la de seguridad y a un ingeniero que dibujen el recorrido desde la entrada hasta la confirmación de recepción. Incluye las direcciones antiguas guardadas en favoritos y los enlaces de correos ya enviados. Es una propuesta de sesión de trabajo, no el relato de un incidente sufrido por un cliente.

Ahora señala qué pasos necesitan el servidor de la aplicación. Una redirección puede consultar la base de datos. Una página de error puede mostrar contenido personalizado. Un formulario puede incluir un token. El objetivo es detectar esas dependencias antes de que una emergencia lleve a alguien a cambiar la caché de forma generalizada.

Si necesitas aclarar quién se ocupa del servicio, la guía sobre alojamiento propio y responsabilidades del equipo ayuda a plantear esa conversación. En esta revisión, céntrate en el tráfico entrante y en el contenido de cada respuesta.

¿Cómo decides qué respuestas del portal son públicas?

Clasifica la respuesta completa, incluidas sus cabeceras y variantes. Que una dirección parezca pública no demuestra que todos reciban el mismo contenido ni que una caché compartida pueda reutilizarlo sin riesgo.

El estándar de caché HTTP, RFC 9111, distingue tres directivas que suelen confundirse. no-store indica a las cachés que no almacenen la respuesta. private impide que la almacene una caché compartida. no-cache permite almacenarla, pero exige validarla antes de reutilizarla. La cabecera de petición Authorization tampoco es una barrera absoluta: ciertas directivas explícitas de la respuesta pueden permitir su reutilización compartida. Por eso no basta con copiar el nombre de una cabecera conocida.

Prepara un inventario de respuestas

Usa esta tabla como hoja de trabajo para la revisión. Ayuda a tomar decisiones técnicas; no es una norma de cumplimiento. Asigna a una persona la recopilación de pruebas de cada fila y a otra la revisión de las conclusiones.

Revisa ejemplos reales con cuentas de prueba y datos ficticios. Compara dos cuentas de cliente, dos idiomas, una visita con sesión iniciada y otra anónima, cuando esos estados existan. Añade los que admita tu producto: esta lista no pretende cubrirlos todos.

Fíjate también en los detalles pequeños de la página. Junto a una descripción genérica del puesto puede aparecer el nombre de un candidato o un token de formulario. Que el texto principal sea público no permite compartir toda la respuesta. Valora separar los datos públicos de la interfaz privada en lugar de intentar declarar inocua la página entera.

Conserva las diferencias que cambian el significado

La clave de caché determina qué peticiones se consideran equivalentes. La documentación de Cloudflare sobre claves de caché explica que ignorar la cadena de consulta puede agrupar peticiones con parámetros distintos. Es una opción que conviene evaluar, no un atajo que activar en todo el portal.

Durante el ejercicio, anota qué significa cada componente de la clave. El host puede identificar al cliente. El idioma puede cambiar las instrucciones. Un filtro puede seleccionar otro puesto. Una credencial puede determinar quién tiene permiso para ver la respuesta. Si no puedes explicar por qué es seguro eliminar una diferencia, consérvala mientras investigas.

Guarda pruebas de la comparación sin datos sensibles. Anota qué rutas y estados has revisado y qué queda por comprobar. Una captura de pantalla no demuestra por sí sola la política de caché. No incluyas enlaces reales de candidatos ni contenido confidencial de informes en el documento de revisión.

¿Cómo proteges las redirecciones y las páginas inexistentes?

Revisa las redirecciones y las respuestas de error como recursos independientes, con sus propias reglas de privacidad y vigencia. El código de estado explica qué ha ocurrido; no determina si es seguro compartir la respuesta.

En la empresa ficticia, empieza por una URL antigua del portal de empleo. Si el destino es fijo y público, estudia si la redirección puede resolverse antes de llegar al servidor de la aplicación. Después, prueba un enlace antiguo de candidato. Su destino podría depender de la autenticación o del estado de la candidatura, así que exige otra decisión aunque ambas respuestas utilicen el mismo código de redirección.

Trata las páginas inexistentes con el mismo cuidado. Guardar brevemente en caché una respuesta 404 pública puede evitar trabajo repetido para el mismo recurso ausente. No resuelve una sucesión ilimitada de rutas inexistentes nuevas, porque cada ruta puede provocar otro fallo de caché. Una respuesta que oculta un recurso privado a alguien sin permiso requiere una política distinta de la de una página pública inexistente.

Asigna la responsabilidad de la información desactualizada

La caché plantea una decisión de producto: ¿cuánto tiempo puede seguir mostrándose la respuesta de ayer? Define esa tolerancia para cada recurso público en lugar de elegir un plazo cómodo para toda la web.

Para una oferta de empleo, pide a la persona responsable de selección que explique las consecuencias de mostrar como abierta una vacante cerrada. Para una política de seguridad, pide al responsable que identifique qué cambios requieren publicación urgente. Una dirección de contacto nueva y una corrección de estilo pueden merecer tratamientos distintos. Son decisiones para esta revisión, no recomendaciones universales sobre plazos de caducidad.

La documentación de Cloudflare sobre control de caché explica las interacciones entre las cabeceras del origen, las reglas que las modifican, las cookies y la entrega de contenido desactualizado. Comprueba la respuesta efectiva en la CDN desplegada. No des por hecho que una cabecera declarada en el código establece lo que reciben los visitantes.

Ensaya un cambio de estado con una oferta ficticia. Consúltala por la ruta pública, ciérrala y comprueba cuándo cambia su representación pública. Después, intenta realizar la acción correspondiente desde la página anterior. La aplicación debe decidir si acepta esa acción según el estado actual, no interpretar una descripción en caché como permiso para continuar.

Mantén actualizadas las instrucciones de contacto

La política de recepción de informes necesita su propia comprobación de vigencia. RFC 9116 define security.txt, incluido el campo Expires y los contactos para comunicar vulnerabilidades. La información caducada no debe utilizarse. Los contactos pueden incluir alternativas por web, correo o teléfono, pero el archivo está pensado para comunicar vulnerabilidades, no como línea general de respuesta a incidentes.

En el ejercicio, recorre cada vía publicada con contenido de prueba inocuo y mediante un procedimiento autorizado. Comprueba quién lo recibe y cómo se informa al remitente del resultado. Que la política cargue rápido solo sirve si sus instrucciones llevan a un canal atendido.

Si aún estás definiendo ese proceso, empieza por la guía del programa de divulgación de vulnerabilidades. Separa las instrucciones públicas del informe privado que ayudan a enviar.

¿Cómo evitas que las verificaciones de tráfico bloqueen los envíos?

Adapta las reglas de protección a los clientes y las acciones a los que afectan. Un navegador que muestra una página y una integración que envía una petición estructurada pueden reaccionar de formas muy distintas ante la misma verificación.

La documentación de Cloudflare sobre páginas de verificación explica que estas devuelven HTML. Por tanto, un cliente que espera JSON puede recibir una respuesta que no sabe gestionar. La verificación previa del navegador puede ayudar en determinados recorridos, pero no resuelve de forma general el acceso de las API o los webhooks.

Para la prueba, enumera las peticiones posteriores a la apertura de la página. Incluye el envío, la subida de archivos, la autenticación y cualquier callback que utilice la integración. Anota el formato de respuesta esperado junto a cada petición. Después, prueba el recorrido con la regla de protección real activada en un entorno adecuado.

No termines la comprobación cuando el navegador supere la primera verificación. Envía el formulario, sigue el enlace posterior y comprueba el registro guardado. Si falla la subida de un archivo, revisa el formato de la respuesta antes de atribuir el problema al archivo. Si falla un callback, analízalo como un cliente independiente: que el navegador haya completado el recorrido no lo cubre.

Revisa los falsos positivos con las personas afectadas

Pregunta a los responsables de selección y seguridad qué vería un usuario legítimo bloqueado. ¿Puede saber si se ha recibido algo? ¿Se entiende qué debe hacer después? ¿Un reintento podría generar dudas sobre si el envío ya existe?

Usa envíos ficticios para revisar esos estados sin llenar inesperadamente las colas de producción. Acuerda con tu equipo una vía de contacto alternativa adecuada para la organización y mantén los detalles confidenciales fuera de las páginas públicas de estado. No presentes una página alternativa como confirmación de envío si la acción no se ha aceptado.

Los límites de peticiones merecen el mismo examen. Cloudflare documenta opciones de limitación adaptadas a NAT, con matices relacionados con las cookies; las funciones también dependen del plan. Su guía sobre frecuencia de peticiones explica que los contadores no se comparten globalmente entre todos los centros de datos. Por eso una regla de la CDN no equivale a una cuota transaccional global estricta.

En esta revisión, evita elegir un límite numérico solo porque otra empresa lo use. Observa el recorrido legítimo e identifica qué significa repetir cada acción. Una ráfaga de lecturas, la subida de un archivo grande y varios envíos de formulario tienen consecuencias distintas. Anota para qué sirve la regla y qué resultados te llevarían a cambiarla.

¿Cómo pruebas el recorrido completo de candidatos e investigadores?

Prueba los casos de éxito, rechazo y recuperación a través de la protección desplegada. La disponibilidad significa que una persona autorizada puede completar su tarea y entender el resultado, no solo que un monitor recibe una respuesta correcta de la página de inicio.

Usa este ejercicio antes de aplicar un cambio amplio en la caché o en las reglas de tráfico. Realízalo con datos sintéticos, responsables designados y un criterio claro para revertir el cambio. Es una revisión funcional, no un sustituto de una prueba de carga planificada por separado.

1. Lee la información pública. Abre la oferta o la política por su vía de entrada real. Comprueba el cliente, el idioma, el estado actual y los datos de contacto. Repite el recorrido desde un enlace público antiguo, si existe.
2. Accede al recorrido privado. Usa identidades de prueba distintas. Comprueba que cada persona solo ve su información y que una petición anónima no recibe la respuesta de un visitante anterior.
3. Completa la acción. Envía la candidatura o el informe ficticios y sube un archivo inocuo si se admite. Verifica el registro aceptado en la interfaz interna correspondiente.
4. Provoca un error habitual. Escribe un valor no válido en un campo o usa un enlace de prueba caducado. Comprueba que la explicación sea útil y no revele información de otra persona.
5. Cambia el estado público. Cierra la vacante ficticia o modifica la política de prueba. Revisa la actualización y repite la acción correspondiente desde una página anterior.
6. Examina cada cliente. Comprueba por separado las peticiones del navegador y las integraciones. Anota los tipos de contenido, el comportamiento de las verificaciones y si el cliente puede recuperarse.

Haz que el ejercicio también sirva para quienes navegan sin ratón. Nuestra lista de comprobación de accesibilidad por teclado del portal del candidato cubre esa parte del recorrido. Una pantalla de verificación o recuperación añadida durante un incidente merece la misma atención que el formulario original.

Define qué permite publicar el cambio

Antes de probar, acuerda con tu equipo qué resultados hacen falta para continuar. Para el equipo ficticio, un criterio razonable sería que la información pública siga siendo correcta, las respuestas privadas permanezcan separadas, los envíos previstos funcionen y las acciones rechazadas generen mensajes fieles a lo ocurrido. Asigna cada fallo a una persona en lugar de resumirlo todo en un porcentaje de disponibilidad.

Conserva un registro breve de la regla modificada, los estados probados, los resultados y los pasos para revertirla. Compara el comportamiento de la CDN con el de la aplicación cuando puedas observar ambos. Si queda algo sin comprobar, descríbelo con precisión: un callback sin probar no es lo mismo que una candidatura cuyo envío ha fallado.

Repite las comprobaciones afectadas cuando cambies la regla o el recorrido. Sirve de poco volver a probar una página de inicio intacta mientras una nueva ruta de subida de archivos queda sin revisar. El alcance del cambio debe determinar el de la revisión.

¿Dónde separa Kit la información pública del trabajo privado?

Un mismo producto puede reunir información pública y procesos confidenciales que requieren tratamientos distintos. Examina la respuesta real antes de decidir su política de caché, incluso si el controlador o la ruta llevan «public» en el nombre.

En el código de Kit revisado el 10 de septiembre, la respuesta JSON de una oferta que admite candidaturas declara una duración de caché pública de cinco minutos. La respuesta security.txt de un programa de seguridad activo declara una hora. Son declaraciones concretas de la aplicación, no mediciones del comportamiento de la CDN desplegada ni de la disponibilidad de los envíos.

El recorrido del candidato es distinto. El token de un enlace mágico permite localizar al candidato y consultar sus candidaturas, entrevistas, ofertas y demás información relacionada. La ruta HTML de la oferta pública también puede recuperar de la sesión una autorización para un candidato. Eso impide tratar todas las páginas accesibles sin identificación como contenido público intercambiable.

Kit también incluye límites de envíos en el middleware de la aplicación. Es una capa de la ruta de petición, no una prueba de que el tráfico entrante no pueda agotar recursos antes de llegar a ella. Este artículo no incluye una auditoría de respuestas de producción, una prueba de carga ni una garantía frente a DDoS. Las protecciones de la información de procedencia y de la indexación tampoco demuestran que una respuesta envíe Cache-Control: no-store.

Aplica el mismo inventario de respuestas a tu portal. Reduce el coste de servir la información que hayas verificado que es pública, define una política distinta para los recorridos privados y comprueba la confirmación que necesita quien realiza el envío.