Vídeo en inglés con subtítulos en español.
403 no es 401, ni 404
401 Unauthorized significa que el servidor quiere credenciales, o que las que enviaste no fueron aceptadas. Enviar credenciales válidas cambia la respuesta.
403 Forbidden significa que las credenciales no son el problema. La petición fue comprendida y rechazada. Iniciar sesión puede no ayudar, porque lo que sea que te rechazó puede no importarle quién eres.
A veces se usa 404 deliberadamente en lugar de 403 para evitar confirmar que una ruta existe. Si estás persiguiendo un 403 en un entorno y un 404 en otro para la misma URL, esa diferencia es una decisión de configuración, no un error.
Capa 1 — tu origen lo rechazó
El caso más sencillo. El archivo existe pero el servidor web no lo sirve: permisos de directorio que excluyen al usuario web, un directorio sin archivo índice y con el listado desactivado, una regla deny de .htaccess o de nginx, o una aplicación que comprueba un rol y devuelve 403 ella misma.
Cómo reconocerlo. La página de error se parece a tu stack: una página por defecto de Apache o nginx, o la pantalla con estilo propio de tu aplicación que dice "no tienes acceso". El registro de acceso de tu origen tiene la petición con estado 403 — y esa es la pista, porque la petición llegó al origen.
Capa 2 — una regla del WAF coincidió
Un firewall de aplicaciones web inspecciona la petición y la bloquea cuando coincide con una firma de ataque. Esta es la capa que produce los 403 más confusos, porque la petición le parece perfectamente inocente a quien la hizo.
Los falsos positivos habituales no son nada exótico: un editor de CMS que guarda un artículo con la palabra SELECT en un ejemplo de código, un campo de formulario con un fragmento de HTML, una descripción de producto con un apóstrofo en un lugar concreto. Los conjuntos de reglas que trae un WAF están escritos para detectar intentos de inyección, y el texto humano a veces se parece a uno.
En cdn.com.tr el WAF es ModSecurity con el OWASP Core Rule Set, y una petición bloqueada recibe una página 403 de marca propia con un ID de referencia. Ese ID es la clave: es el identificador de la petición escrito en el registro de auditoría, así que puedes buscar exactamente qué regla coincidió y en qué campo, en lugar de adivinar. La página de registros del WAF en el panel lista los eventos bloqueados con la categoría del ataque, el país, la IP y la regla que se activó.
La solución que te mantiene protegido. Excluye el campo específico en la ruta específica — por ejemplo el cuerpo del artículo en la URL del editor — en lugar de desactivar toda una familia de reglas en todas partes o apagar el WAF para el sitio entero. Una exclusión estrecha no te cuesta nada; una amplia retira la protección de todas las demás páginas sin que te des cuenta.
Capa 3 — un bloqueo por país o red
Los bloqueos geográficos y de red se aplican antes de que la petición llegue a tu aplicación, y también producen 403. Si tienes una lista negra de países, todos los visitantes de ese país ven el rechazo. Si bloqueas por ASN —un número de sistema autónomo, que cubre toda la red de un proveedor—, se rechaza a todos los visitantes de ese proveedor, lo cual es una red mucho más amplia de lo que suena.
La trampa que conviene conocer. Los operadores móviles ponen a millones de abonados normales detrás de un puñado de ASN, y las IP móviles rotan. Un visitante que iba bien por wifi puede ser rechazado en datos móviles y describirlo como "la web no funciona en mi móvil". Si tus informes de 403 se concentran en redes móviles, mira tus bloqueos antes de mirar tu aplicación.
Bloqueos como estos merecen una auditoría periódica. Una regla añadida durante un incidente tiende a sobrevivir al incidente.
Capa 4 — protección hotlink y listas de IP
La protección hotlink rechaza las peticiones de tus imágenes y archivos cuando la cabecera Referer es otro sitio. Hace su trabajo, pero también rechaza tráfico legítimo que olvidaste: tu propio dominio de staging, un cliente de correo renderizando una imagen, una app que no envía referer en absoluto. El síntoma es concreto y reconocible — las páginas cargan, las imágenes no.
Las listas de IP permitidas y denegadas son la capa más contundente. Una lista de permitidos en una ruta de administración es un control excelente hasta el día en que cambia la IP de tu oficina y nadie recuerda que esa lista existe. Cuando un 403 afecta exactamente a una persona y a nadie más, esta suele ser la razón.
Cómo encontrar la causa, en orden
Trabaja de fuera hacia dentro. Lleva minutos y es mejor que adivinar.
1. Lee la página de error. Una página de marca propia con un ID de referencia indica una decisión en el edge — una regla del WAF, un bloqueo geográfico o por ASN. Una página por defecto del servidor o el estilo de tu propia aplicación indica que decidió el origen.
2. Si hay un ID de referencia, búscalo. El registro del WAF te da el ID de la regla, el campo que coincidió y el valor que lo disparó. Es el camino más rápido del síntoma a la causa, y convierte la conversación de "la web me bloquea a veces" en "la regla 942100 coincidió con el cuerpo del artículo".
3. Comprueba si te pasa solo a ti. Pruébalo desde otra red o una conexión móvil. Si te pasa solo a ti, mira las listas de IP. Si le pasa a todo el mundo desde un país, mira tus bloqueos geográficos.
4. Comprueba si es solo una ruta. Una URL que rechaza mientras el resto del sitio funciona apunta a las propias reglas del origen o a una regla del WAF vinculada a esa ruta.
5. Solo entonces, mira el origen. Si la petición nunca aparece en el registro de acceso de tu origen, fue rechazada antes de llegar, y nada de lo que cambies en el origen ayudará.
Solucionarlo sin perder la protección
El instinto cuando un WAF bloquea una petición legítima es apagar el WAF para ese sitio. Funciona, en el sentido de que el síntoma desaparece, y retira la protección de todas las demás peticiones en las que no estabas pensando.
Una secuencia mejor: reproduce el bloqueo, lee el ID de la regla en el registro, escribe una exclusión para esa regla en ese campo y esa ruta, y luego reprodúcelo de nuevo para confirmar que la petición pasa y que la regla sigue activándose en cualquier otro sitio. En cdn.com.tr para esto están las reglas de entrega y los presets de seguridad — la exclusión vive en la configuración, se despliega en todos los edges, y queda visible en el historial de actividad junto con quién la hizo y los valores antes y después.
Si no puedes reproducir el bloqueo, no empieces a escribir exclusiones. Una exclusión para una regla que no era la causa es protección retirada para nada.
Cómo configurarlo
Guías paso a paso en el centro de ayuda:
Preguntas frecuentes sobre 403 Forbidden
¿Por qué la misma URL funciona en un navegador y en otro no?
La petición no es idéntica. Distintos user agents, distintas cookies y, en particular, distintas redes — un navegador por wifi y otro con datos móviles salen desde direcciones IP diferentes. Si el rechazo sigue a la red y no al navegador, mira los bloqueos de IP, país o ASN en lugar de tu aplicación.
Mi WAF bloquea mi propio editor cuando guardo un artículo. ¿Qué cambio?
Encuentra el ID de la regla en el evento bloqueado y luego exime esa regla para el campo que envía el editor en la URL del editor. No eximas toda la ruta ni desactives la familia de reglas para el sitio: esas mismas reglas protegen el resto de tus formularios, y los intentos de inyección llegan por los mismos campos que el texto legítimo.
¿Se puede cachear un 403?
Se puede, y un 403 cacheado es una sorpresa desagradable porque la causa desaparece mientras el síntoma se queda. Las respuestas de error deberían servirse en general con un TTL corto o sin caché en absoluto. Si arreglaste la causa y los visitantes siguen viendo el rechazo, purga la ruta antes de seguir depurando.
El ID de referencia en la página de error, ¿para qué sirve?
Es el identificador de esa petición exacta en el registro de auditoría. Un visitante puede enviártelo y tú puedes buscar qué regla se activó, en qué campo, con qué valor. Sin él, un reporte de "403 a veces" es casi imposible de investigar.
¿Un 403 perjudica mi SEO?
Un 403 en una página que quieres indexada sí, porque el rastreador es rechazado como cualquier otro cliente y con el tiempo abandonará la URL. El caso a vigilar es un bloqueo demasiado amplio que también atrapa a los rastreadores de los buscadores — comprueba que las páginas que te importan responden 200 a un rastreador, no solo a tu navegador.