El autor descubrió que su sitio estático estaba sirviendo un documento de entrega interna de ingeniería a cualquiera que lo solicitara. El archivo de 150 KB, que contenía un parámetro de consulta de cadena que bypassaba el pago durante el onboarding, una descripción de un agujero de esquema conocido que permite marcar cuentas como pagadas sin pagar, identificadores de base de datos y configuraciones de herramientas como .claude/launch.json y archivos de flujo de trabajo de GitHub, estaba accesible públicamente en el dominio de producción. Esto ocurrió porque el directorio de salida de la construcción del host estático estaba configurado como la raíz del repositorio, provocando que cada archivo confirmado—incluidos los directorios con punto y la documentación—se publicara como una URL pública.

Los intentos iniciales de eliminar la exposición borrando los archivos y redployendo, seguidos de dos purgas de caché, resultaron inútiles. Al examinar los encabezados de respuesta se encontró un `cf-cache-status: DYNAMIC` cuya edad aumentaba constantemente (de 4 396 a 67 735 segundos), indicando que la caché de zona nunca había retenido el archivo; en su lugar, la capa de activos/periférica del propio host estático servía la copia obsoleta. Esto se confirmó al observar que el dominio predeterminado del proveedor (pages.dev) servía la versión limpia mientras el dominio personalizado continuaba sirviendo el archivo desactualizado, demostrando que la herramienta de purga y la capa que retenía la copia obsoleta eran dos sistemas diferentes.

La fuga se cerró definitivamente agregando una regla de firewall perimetral que bloquea las solicitudes que coinciden con tokens de ruta específicos (la ruta del documento filtrado, .claude/ y .github/), la cual se ejecuta antes de consultar la caché y tiene efecto inmediato. Rotar el parámetro de admin revelado en el documento proporcionó poca protección porque el valor ya estaba integrado en el código fuente del lado cliente y permanecía visible después de la rotación. El autor enfatiza que la verdadera solución fue cerrar el agujero de esquema del lado servidor descrito en el documento filtrado, lo que anulaba la efectividad del parámetro de admin independientemente de quién lo conociera.