Error 403 Forbidden: Causas y Cómo Resolverlo

El error 403 Forbidden informa que el servidor entendió la solicitud y se negó a ejecutarla. A diferencia del 401, repetir el inicio de sesión no resuelve necesariamente: la identidad puede ser válida, pero sin permiso para ese recurso o acción.

Respuesta directa: cómo resolver el error 403

Descubre qué capa produjo la respuesta. Revisa el cuerpo y los encabezados, compara una solicitud autorizada, valida el rol y el alcance del usuario, las reglas de la aplicación, los permisos de archivo, la configuración del servidor, WAF y CDN. Cambia solo la regla responsable y prueba nuevamente con una cuenta permitida y otra prohibida.

Paso 1: captura la respuesta completa

curl -i https://api.exemplo.com/relatorios \
  -H "Authorization: Bearer TU_TOKEN"

No compartas tokens en llamados o capturas. Anota el estado, mensaje, request-id, servidor y encabezados del proxy. Una página generada por la CDN tiene una apariencia diferente a un JSON creado por la aplicación.

Paso 2: diferencia autenticación y autorización

Un token expirado o ausente normalmente debería causar 401 e incluir WWW-Authenticate. Un token válido sin el rol exigido causa 403. Inspecciona issuer, audience, expiración y scopes sin registrar el secreto completo. En la aplicación, autoriza en el servidor; ocultar un botón en el front-end no protege la operación.

Ejemplo de decisión:

autenticado? no -> 401
autenticado? sí, tiene reports:read? no -> 403
¿tiene permiso? sí -> ejecutar y responder 200

Paso 3: verifica Nginx y sistema de archivos

El proceso del servidor necesita atravesar los directorios y leer los archivos publicados. En Linux, revisa sin aplicar permisos amplios:

namei -l /var/www/site/public/index.html
sudo nginx -T
sudo tail -n 100 /var/log/nginx/error.log

Evita chmod 777. Corrige propietario, grupo y permisos mínimos. Verifica también reglas deny, autenticación básica, ausencia de archivo index y bloques location más específicos.

Paso 4: evalúa WAF, CDN y rate limit

Busca el evento por el identificador de la respuesta. Reglas gestionadas pueden bloquear payload, método, IP, encabezado o patrón interpretado como ataque. Crea una excepción estrecha para ruta y condición comprobadas; no apagues todo el firewall.

Paso 5: revisa CORS solo cuando sea el caso

CORS es una política del navegador y frecuentemente aparece en la consola sin que la respuesta principal sea 403. Prueba la API fuera del navegador. Si el preflight OPTIONS recibe 403, permite el método y los encabezados necesarios para orígenes conocidos. El tutorial de error de CORS profundiza esta investigación.

Respuesta segura de la API

Informa lo suficiente para corrección por el cliente sin revelar reglas internas sensibles:

{
  "error": "forbidden",
  "message": "Tu cuenta no tiene permiso para esta acción",
  "requestId": "req_abc"
}

Registra en el servidor usuario, tenant, acción, regla negada y request ID. No coloques token o dato personal innecesario en el log.

Checklist de corrección

• reproducir con una solicitud mínima;
• identificar la capa que generó 403;
• validar rol, alcance, tenant y propiedad del recurso;
• revisar logs en el mismo horario y request ID;
• probar cuenta permitida y prohibida;
• mantener negación por defecto y menor privilegio;
• documentar el cambio y monitorear reincidencia.

Preguntas frecuentes

¿Limpiar el caché resuelve 403?

Solo si una credencial o respuesta incorrecta está almacenada. En general, el servidor continuará negando mientras la regla permanezca.

¿Cuál es la diferencia entre 401 y 403?

401 pide autenticación válida; 403 indica que la solicitud conocida no tiene derecho a la acción.

Fuentes primarias

• MDN: status 403 Forbidden
• RFC 9110: status 403
• Nginx: módulo de control de acceso