403 Forbidden: causas, soluciones y bloqueos de bots que engañan a los monitores

403 frente a 401

El RFC 9110 marca la línea con claridad. Un 401 Unauthorized significa que hace falta autenticarse o que las credenciales enviadas no se aceptaron, y la respuesta debe llevar una cabecera WWW-Authenticate que describa cómo autenticarse. Un 403 Forbidden significa que el servidor se niega a autorizar la petición, y volver a autenticarse no ayudará.

La especificación también permite que un servidor responda 404 en lugar de 403 cuando no quiere revelar siquiera que el recurso existe. Por eso una URL que sabes que está ahí puede volver como "no encontrada" desde un servidor endurecido. Si estás clasificando un 403, recuerda que el caso contrario también existe.

Qué produce un 403

• Permisos del sistema de archivos. El proceso del servidor web no puede leer el archivo o atravesar el directorio. Un clásico después de copiar archivos a mano o de una restauración que cambió la propiedad.
• Listado de directorios desactivado. Una petición a una carpeta sin archivo de índice devuelve 403 en servidores configurados para rechazar listados. Comportamiento correcto, error confuso.
• Reglas de autorización de la aplicación. El usuario ha iniciado sesión pero le falta el rol, el plan o la pertenencia al espacio que ese recurso exige.
• Listas de IP permitidas y denegadas. Una ruta de administración restringida a las direcciones de la oficina devuelve 403 a todos los demás, incluido quien pruebe desde casa o desde una red móvil.
• Reglas del cortafuegos de aplicaciones web. Un WAF bloquea una petición cuya URL, cabeceras o cuerpo coincidieron con una firma. A menudo la petición te parece del todo inocente.
• Bloqueo geográfico. El tráfico de algunos países o regiones se rechaza en el borde, así que el sitio va bien desde un continente y está prohibido desde otro.
• Protección contra enlaces directos. Una regla que rechaza las peticiones de imágenes o multimedia cuya cabecera Referer falta o apunta a otro dominio. Las peticiones sin referente caen por accidente muy a menudo.
• Filtrado de bots y de user agent. La petición se bloquea por quién dice ser el cliente, no por lo que pidió. Este es el caso que pilla al monitoreo.

El caso de "403 para los monitores, 200 para las personas"

Es la falsa alarma más habitual en el monitoreo de disponibilidad, y no es un fallo del monitoreo. El sitio devuelve un 403 de verdad, solo que no a los navegadores.

La gestión de bots de una CDN o un WAF puntúa cada petición por su user agent, su huella TLS, el orden de las cabeceras, la reputación de la IP y si resuelve un desafío de JavaScript o interactivo. Una verificación HTTP automatizada es, por diseño, un cliente automatizado: no ejecuta desafíos de JavaScript y se identifica con honestidad. Así que recibe un desafío o un bloqueo mientras tu navegador pasa sin problema, y el resultado es un sitio que alerta como caído mientras cada persona confirma que está en pie.

Dos señales lo identifican rápido: el 403 llega al instante en vez de tras una espera, lo que descarta la sobrecarga, y es constante para el cliente automatizado mientras nunca se reproduce en un navegador de la misma red.

Cómo poner un servicio de monitoreo en la lista de permitidos

1. Confirma que el bloqueo se basa en la identidad. Repite la petición como cliente HTTP simple y luego con una cadena de user agent de navegador, y compara:

   curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
   curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://example.com/

   Si los códigos difieren, lo está haciendo una regla de user agent.
2. Encuentra la regla que saltó. Los paneles de WAF y de CDN registran las peticiones bloqueadas con el identificador de la regla que coincidió. Eso es más rápido y más seguro que adivinar qué regla relajar.
3. Permite por dirección IP donde puedas. Los proveedores de monitoreo publican las direcciones que usan sus puntos de verificación. Añadirlas como regla de exclusión es preciso y no debilita la protección para nadie más.
4. O permite por user agent. Configura la comprobación para que envíe un user agent distintivo y añade una regla que lo exima. Es más fácil de mantener que una lista de IP, pero trátalo como una comodidad y no como una frontera de seguridad, porque cualquiera puede copiar un user agent.
5. Prefiere una regla de exclusión a desactivar la protección. Exime del reglamento concreto a la ruta o al cliente de monitoreo, y deja el resto en vigor.
6. Vuelve a probar desde varias regiones. Una regla puede aplicarse de forma desigual entre ubicaciones de borde, así que verifica la solución desde más de un sitio antes de cerrar el ticket.

Solucionar un 403 que no va de bots

1. Comprueba si la URL debería ser pública siquiera. La mitad de las investigaciones de un 403 terminan con la respuesta de que el bloqueo es correcto.
2. Verifica la propiedad y los permisos de la ruta y de cada directorio superior. El proceso del servidor necesita permiso de ejecución en los directorios, no solo permiso de lectura sobre el archivo.
3. Busca un archivo de índice si la URL es un directorio, o activa el listado a propósito si es lo que quieres.
4. Lee la configuración del servidor en busca de reglas de denegación, restricciones por IP y comprobaciones de referente en esa ruta, y después la capa de autorización de la aplicación.
5. Comprueba el borde antes que el origen. Pide el origen directamente. Un 403 que desaparece al saltarse la CDN es una regla del borde, no un problema de la aplicación.

Ver el bloqueo desde fuera de tu propia red

Un 403 introducido por una actualización del WAF o un cambio de permisos no parece una caída desde dentro: tu sesión está autenticada, tu dirección está permitida y las páginas que revisas son las que funcionan. Una verificación HTTP programada comprueba el código que esperas en las URL que importan, desde fuera de tu red, así que una página recién prohibida levanta una alerta de inmediato. Los bloqueos geográficos y las reglas de borde varían por región, así que el número de puntos de vista cuenta: HostTracker verifica desde más de 300 puntos de verificación en 158 ciudades, lo que convierte un "prohibido en algunos países" en una diferencia visible entre ubicaciones. Si la negativa es temporal y va ligada al volumen de peticiones y no a la identidad, el código será normalmente un 429, tratado en la guía del 429 Too Many Requests, y la familia más amplia está en el resumen de los 4xx.