Un error 403 Forbidden significa que el servidor recibió la petición, la entendió y se negó a responderla. A diferencia de un 401, iniciar sesión no tiene por qué ayudar: el servidor dice que este cliente, desde esta dirección y con estos permisos, no puede acceder a este recurso. La causa casi siempre es una regla, no un fallo: permisos de archivos, un archivo index que falta, una regla deny en la configuración del servidor, un firewall o una protección contra bots, un bloqueo por IP o por país, o una cuenta sin el rol adecuado. Los propietarios del sitio encuentran la regla en el log de errores o en el registro de eventos del firewall; los visitantes, en general, solo pueden cambiar lo que envían.
403 vs 401 vs 404
CódigoQué dice el servidorQué ayuda401 Unauthorized¿Quién eres? Envía tus credenciales.Iniciar sesión, o una clave de API o un token válidos403 ForbiddenSé lo que quieres, y no puedes tenerlo.Otros permisos, otra dirección u otra petición404 Not FoundAquí no hay nada.La dirección correcta
Los servidores no siempre siguen el manual. Algunos responden 404 en lugar de 403 para ocultar que existe una página privada, y otros responden 403 para archivos que no existen: un bucket de almacenamiento privado, por ejemplo, puede responder 403 para un objeto que no está cuando el cliente no tiene permiso para listar el bucket. La referencia de códigos de estado HTTP recoge el resto.
Causas habituales
Permisos de archivos y carpetas. El usuario del servidor web no puede leer el archivo o entrar en la carpeta, a menudo tras una subida o un despliegue que copió los archivos como otro usuario.
Sin archivo index. Una petición a una carpeta sin index.html ni index.php, en un servidor con el listado de directorios desactivado, responde 403. Un despliegue fallido que dejó la carpeta vacía provoca lo mismo.
Reglas deny. Un deny all en nginx, un Require all denied en Apache o una regla en .htaccess que bloquea una ruta, un tipo de archivo o un user agent.
Un firewall o una protección contra bots. Un WAF, la protección contra bots de una CDN o un plugin de seguridad decide que la petición parece automatizada o maliciosa y la bloquea, a veces con una página de verificación.
Bloqueos por IP y por país. La dirección, la red o el país del visitante está en una lista de bloqueo, o la página está limitada a la red de una oficina o a una VPN.
Falta de permisos. El visitante ha iniciado sesión, pero su rol no le da acceso a la página, o una clave de API no tiene el alcance necesario para el endpoint.
Enlaces firmados caducados o incorrectos. Los enlaces de descarga con firma o con fecha de caducidad responden 403 cuando expiran.
Protección contra hotlinking. Se rechazan las imágenes o archivos solicitados desde otro sitio, o sin el Referer esperado.
Qué pueden probar los visitantes
Revisa la dirección. Un enlace que termina en una carpeta en lugar de en una página, o una ruta mal escrita, puede dar con una carpeta que el servidor no lista.
Inicia sesión, o hazlo con la cuenta correcta. Algunos sitios muestran 403 a los visitantes que no han iniciado sesión, o a cuentas sin acceso.
Borra las cookies del sitio y recarga. Una sesión antigua o una cookie de verificación caducada puede hacer que un firewall te siga rechazando.
Cambia de red. Desactiva una VPN o un proxy, o actívalos, o prueba con datos móviles. Las direcciones compartidas y las de centros de datos se bloquean más a menudo que las conexiones domésticas.
Desactiva las extensiones para ese sitio. Algunas extensiones de privacidad modifican las cabeceras de una forma que hace saltar un firewall.
Avisa al propietario del sitio, con la hora y el número de referencia que muestre la página de error. Con ese número puede encontrar la regla exacta.
Cómo lo encuentran y lo solucionan los propietarios del sitio
Primero averigua quién ha respondido. Mira la página de error y las cabeceras de la respuesta: una CDN o un firewall suele identificarse, con una página con su propio estilo, una cabecera Server o un ID de petición. Si ha sido tu servidor web, su log de errores indica el motivo. Si ha sido la CDN o el WAF, lo indica su registro de eventos.
Permisos y archivos index
En servidores Linux, las carpetas suelen necesitar 755 y los archivos 644, con el usuario con el que se ejecutan el servidor web o PHP como propietario. Revísalo antes de cambiar nada, y nunca soluciones un 403 con 777, que permite a cualquier usuario del servidor escribir en tu sitio:
ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +
nginx registra “directory index of … is forbidden” cuando una carpeta no tiene archivo index; Apache registra que no encuentra un index y que el listado de directorios está desactivado. Comprueba que el despliegue haya dejado los archivos donde apunta el document root del servidor.
Reglas del servidor
nginx registra “access forbidden by rule” para un deny, y Apache registra “client denied by server configuration” para una regla Require. Busca la regla que coincide en la configuración y en cada .htaccess de la ruta. En WordPress, al guardar los ajustes de enlaces permanentes se reescribe la parte del núcleo de .htaccess, y los plugins de seguridad añaden ahí sus propios bloques y en sus ajustes.
Firewalls, CDN y plugins de seguridad
Busca la petición bloqueada en el registro de eventos por hora, dirección o ID de petición, mira qué regla ha coincidido y decide si la regla está mal o si la petición era de verdad no deseada. Añade excepciones para direcciones o rutas concretas en lugar de desactivar una regla para todo el sitio. Tras un cambio en el firewall, prueba desde una red ajena a tu oficina, ya que tu propia dirección puede estar en la lista de permitidos.
Por qué un monitor recibe un 403 cuando tu navegador no
Un caso habitual: el sitio te funciona, pero tu monitor de uptime informa de un 403. Normalmente no hay nada roto. Algo delante del sitio trata la comprobación como un bot, porque lo es:
Protección contra bots. Las CDN y los WAF ponen a prueba a los clientes que no ejecutan JavaScript o que parecen automatizados. Un navegador supera la verificación; un monitor no puede, así que recibe un 403 o una página de verificación.
Direcciones de centros de datos. Los monitores comprueban desde servidores, y algunas reglas bloquean por defecto las redes de hosting.
Bloqueos por país. Un sitio que solo admite su propio país bloquea a un monitor que comprueba desde el extranjero.
Reglas de frecuencia. Algunos firewalls responden 403 en lugar de 429 cuando un cliente hace demasiadas peticiones.
La solución es añadir el monitor a la lista de permitidos, preferiblemente por sus direcciones IP, ya que cualquiera puede copiar un user agent. No lo resuelvas aceptando el 403 como “activo” para todo el sitio: entonces un bloqueo real a tus visitantes pasaría desapercibido. Si una página tiene que quedarse de verdad detrás de la protección, monitoriza un endpoint de health check fuera de ella. La guía para reducir las falsas alertas trata otras causas de alertas que no son caídas.
Los errores 403 y Uptimecheck
Un monitor HTTP(S) de la monitorización de uptime de Uptimecheck considera activos por defecto los estados de 200 a 399, así que un 403 cuenta como caída. Una segunda comprobación lo confirma antes de avisarte, y la incidencia explica quién ha respondido: cuando el 403 o una página de verificación viene de Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence o AWS WAF, indica ese servicio y qué debes permitir en él. Las comprobaciones de sitios web se hacen desde Estocolmo (Suecia), con un user agent que contiene “Uptimecheck”. Cómo permitir Uptimecheck en un firewall enumera nuestras direcciones con reglas listas para usar en Cloudflare, plugins de seguridad de WordPress y nginx, y por qué un monitor puede estar caído cuando el sitio funciona explica los demás motivos.
¿Quieres saber si un sitio responde siquiera? El comprobador Is it down? gratuito considera activa cualquier respuesta por debajo de 500, incluido un 403: el servidor ha respondido, aunque haya rechazado la petición.
Distingue una comprobación bloqueada de una caída real. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.