Error 403 Forbidden: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Un navegador muestra 403 Forbidden, Access Denied o una página de denegación personalizada.
• Un cliente de API recibe HTTP 403 aunque haya proporcionado credenciales.
• El DNS y TLS pueden funcionar con normalidad porque la solicitud llegó a un servidor HTTP o intermediario.
• Solo pueden verse afectados una ruta, archivo, cuenta, dirección IP, método HTTP o red.
• Una respuesta de una CDN o WAF puede incluir headers específicos del proveedor, un identificador de solicitud o una página de desafío o denegación de seguridad.
• El error puede comenzar después de un despliegue, un cambio de permisos, una actualización de reglas de reescritura, un cambio del firewall o una actualización de la política del WAF.

Causas principales, ordenadas por probabilidad

Entre las causas probables, ordenadas de más comunes a menos comunes, se incluyen:

1. Falta de autorización: El recurso requiere un usuario con sesión iniciada, un rol específico, ser el propietario, una suscripción o un scope del token de API determinados.
2. Filtrado de la CDN o el WAF: Una política de seguridad puede bloquear la IP del cliente, el patrón de solicitud, el país, el user agent, la frecuencia o la URL.
3. Reglas de acceso del servidor web: La configuración de Apache o Nginx puede denegar una ruta mediante reglas allow/deny, de ubicación, reescritura, directorio o archivo de índice.
4. Problemas de acceso a archivos o directorios: Una propiedad o unos permisos incorrectos pueden impedir que el proceso del servidor web atraviese directorios o lea un recurso.
5. Lógica de autorización de la aplicación: La aplicación puede devolver deliberadamente un 403 para un usuario, objeto, operación o estado de cuenta.
6. Restricciones de red o hotlinking: Las listas de IP permitidas, las comprobaciones del referer u otras políticas de acceso pueden rechazar una solicitud que, por lo demás, es válida.

Un 403 puede ser intencionado. Confirma que el recurso debería estar disponible para el usuario o cliente afectado antes de cambiar la configuración.

Cómo solucionarlo

Si eres visitante

1. Verifica la dirección exacta. Comprueba el hostname, la ruta, la ortografía, la query string y las mayúsculas y minúsculas. Elimina los cambios accidentales de la URL y vuelve a intentar acceder a la página prevista.
2. Inicia sesión si es necesario. Si el recurso pertenece a una cuenta o suscripción, autentícate y confirma que la cuenta tiene el rol o plan necesarios.
3. Prueba con una red adecuada. Si el sitio puede restringir VPN, proxies, redes corporativas o direcciones IP, vuelve a intentarlo desde una red aprobada. No intentes eludir una política de acceso sin permiso.
4. Evita los reintentos automatizados repetidos. Las solicitudes repetidas pueden activar reglas de frecuencia o seguridad y dificultar el diagnóstico.
5. Contacta con el propietario del sitio cuando el acceso debería ser público. Incluye la URL exacta, la hora aproximada, la cuenta o red afectada y cualquier identificador de solicitud que aparezca en la página de error. No envíes contraseñas, cookies de sesión ni secretos de API.

Si administras el sitio o la API

1. Reproduce y registra la solicitud. Anota la URL exacta, el método HTTP, la zona horaria, la IP del cliente cuando corresponda, el contexto de autenticación, el estado, los headers de respuesta y cualquier request ID o Ray ID. Elimina los secretos antes de compartir los logs.
2. Identifica la capa que responde. Determina si la respuesta procede de la aplicación, el servidor web, el reverse proxy, la CDN o el WAF. Las páginas de denegación personalizadas y los headers específicos del proveedor pueden dar pistas, pero confirma el origen en los logs.
3. Comprueba la autenticación y la autorización. Verifica que la cuenta, el rol, el token de API, el scope de OAuth, la propiedad del recurso y la operación solicitada estén permitidos. Una credencial válida demuestra autenticación, no autorización para todos los recursos.
4. Inspecciona los eventos de la CDN y el WAF. Relaciona la solicitud con el evento y la regla de seguridad pertinentes. Si la solicitud es legítima, prefiere una excepción limitada y autenticada; no desactives la protección globalmente.
5. Revisa las reglas del servidor web. Examina la configuración de virtual hosts, ubicaciones, directorios, allow/deny, reescrituras y archivos de índice de Apache o Nginx. Compárala con la última configuración que funcionaba.
6. Comprueba la propiedad y los permisos. Confirma que el proceso del servidor web puede atravesar los directorios necesarios y leer el archivo de destino. Mantén el principio de mínimo privilegio y no cambies los archivos a permisos de escritura globales.
7. Revisa el comportamiento de la aplicación. Comprueba la autorización por ruta, la propiedad de los objetos, el middleware de control de acceso y los cambios recientes de código o configuración. Corrige un 403 deliberado de la aplicación en la política de autorización, en lugar de debilitar el servidor web.
8. Vuelve a probar de forma limitada. Después de aplicar una corrección mínima y autorizada, prueba la URL y el método exactos desde el contexto afectado. Confirma que las rutas privadas no relacionadas sigan protegidas y supervisa los logs para detectar nuevas denegaciones.

Prevención y cómo verificar la solución

• Documenta qué rutas son públicas, requieren autenticación, están restringidas por rol o se deniegan intencionadamente.
• Aplica roles de aplicación y permisos de archivos basados en el mínimo privilegio; evita archivos y directorios con escritura global.
• Limita las reglas de CDN, WAF, IP, hotlinking y servidor a la ruta o audiencia más pequeña necesaria.
• Prueba los cambios de reglas de seguridad y del servidor web en un entorno controlado antes de desplegarlos ampliamente.
• Supervisa las tasas de 401 y 403 por ruta y correlaciona los picos con versiones, cambios de configuración y eventos de seguridad.
• Mantén la configuración versionada y una ruta de rollback probada para los cambios de control de acceso.
• Registra el propietario esperado de cada capa de denegación para poder dirigir rápidamente los incidentes.

Preguntas frecuentes