Respuestas HTTP 403 prohibidas frente a 401 no autorizadas
https://stackoverflow.com/questions/3297048
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Para una página web que existe, pero para la cual un usuario no tiene privilegios suficientes (no ha iniciado sesión o no pertenece al grupo de usuarios adecuado), ¿cuál es la respuesta HTTP adecuada para servir?
401 Unauthorized?
403 Forbidden?
¿Algo más?
Lo que he leído sobre cada uno hasta ahora no es muy claro sobre la diferencia entre los dos.¿Qué casos de uso son apropiados para cada respuesta?
Solución
Una explicación clara de Daniel Irvin:
Hay un problema con 401 No autorizado, el código de estado HTTP para errores de autenticación.Y eso es todo:es para autenticación, no para autorización.Recibir una respuesta 401 es el servidor que le dice: "No está autenticado, ni se autenticó en absoluto o se autenticó incorrectamente, pero por favor reanude e intente nuevamente". Para ayudarlo, siempre incluirá un WWW-autenticar Encabezado que describe cómo autenticarse.
Esta es una respuesta generalmente devuelta por su servidor web, no su aplicación web.
También es algo muy temporal;El servidor le pide que vuelva a intentarlo.
Entonces, para la autorización utilizo el 403 Prohibido respuesta.Es permanente, está vinculado a la lógica de mi aplicación, y es una respuesta más concreta que un 401.
Al recibir una respuesta 403, el servidor le dice: “Lo siento.Sé quién eres, creo quién dices que eres, pero simplemente no tienes permiso para acceder a este recurso.Tal vez si le pregunta al administrador del sistema muy bien, obtendrá permiso.Pero no me vuelvas a molestar hasta que cambie su situación ".
En resumen, un 401 No autorizado la respuesta debe usarse para la falta de autenticación faltante o mala, y un 403 Prohibido La respuesta debe usarse después, cuando el usuario se autentica, pero no está autorizado para realizar la operación solicitada en el recurso dado.
Otro buen formato pictórico de cómo se deben utilizar los códigos de estado http.
Otros consejos
ver rfc2616 :
401 no autorizado:
Si la solicitud ya incluía credenciales de autorización, entonces la respuesta 401 indica que la autorización ha sido rechazada para esas credenciales.
403 prohibido:
El servidor entendió la solicitud, pero se niega a cumplirlo.
actualización
Desde su caso de uso, parece que el usuario no está autenticado.Volvería 401.
Algo que faltan las otras respuestas es que debe entenderse que la autenticación y la autorización en el contexto de RFC 2616 se refiere solo al protocolo de autenticación HTTP de RFC 2617. La autenticación por esquemas fuera de RFC2617 no es compatible con códigos de estado HTTP y No se consideran al decidir si usar 401 o 403.
BREVE Y TERSE
No autorizado Indica que el cliente no es autenticado RFC2617 y el servidor está iniciando el proceso de autenticación. Prohibido indica que el cliente es autenticado RFC2617 y no tiene autorización ni que el servidor no es compatible con RFC2617 para el recurso solicitado.
Significado Si tiene su propio proceso de inicio de sesión de su propio rollo y nunca use la autenticación HTTP, 403 es siempre la respuesta adecuada y 401 nunca debe usarse.
detallado y en profundidad
de RFC2616
10.4.2 401 no autorizado
La solicitud requiere autenticación del usuario. La respuesta debe incluir un campo de encabezado de autenticación WWW (SECCIÓN 14.47) que contiene un desafío aplicable al recurso solicitado. El cliente puede repetir la solicitud con un campo de encabezado de autorización adecuado (Sección 14.8).
y
10.4.4 403 Prohibido El servidor entendió la solicitud, pero se niega a cumplirlo. La autorización no ayudará y la solicitud no debe repetirse.
Lo primero que debe tener en cuenta es que la "autenticación" y la "autorización" en el contexto de este documento se refieren específicamente a los protocolos de autenticación HTTP de RFC 2617. No se refieren a ningún protocolso de autenticación de su propio rollo. puede haber creado usando páginas de inicio de sesión, etc. Usaré "Iniciar sesión" para referirse a la autenticación y la autorización por parte de los métodos que no sean RFC2617
Por lo tanto, la diferencia real no es cuál es el problema o incluso si hay una solución. La diferencia es lo que el servidor espera que el cliente haga a continuación.
401 Indica que el recurso no se puede proporcionar, pero el servidor solicita que el cliente inicie sesión a través de la autenticación HTTP y haya enviado los encabezados de la respuesta para iniciar el proceso. Posiblemente haya autorizaciones que permitan el acceso al recurso, posiblemente no lo existan, pero le vamos a intentar ver qué sucede.
403 indica que el recurso no se puede proporcionar y que existe, para el usuario actual, de ninguna manera para resolver esto a través de RFC2617 y no tiene sentido intentarlo. Esto puede deberse a que se sabe que ningún nivel de autenticación es suficiente (por ejemplo, debido a una lista negra de IP), pero puede ser porque el usuario ya está autenticado y no tiene autoridad. El modelo RFC2617 es un usuario, una sola credencial, por lo que el caso en el que el usuario puede tener un segundo conjunto de credenciales que podrían ser autorizadas puede ser ignorado. Tampoco sugiere ni implica que algún tipo de página de inicio de sesión u otro protocolo de autenticación no RFC2617 puede o no puede ayudar, que está fuera de los estándares y la definición de RFC2616.
+-----------------------
| RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
+-----------------------
| |
NO | v YES
v +-----------------------
404 | IS LOGGED-IN ? (authenticated, aka has session or JWT cookie)
or +-----------------------
401 | |
403 NO | | YES
3xx v v
401 +-----------------------
(404 no reveal) | CAN ACCESS RESOURCE ? (permission, authorized, ...)
or +-----------------------
redirect | |
to login NO | | YES
| |
v v
403 OK 200, redirect, ...
(or 404: no reveal)
(or 404: resource does not exist if private)
(or 3xx: redirection)
Las verificaciones generalmente se realizan en este orden:
- 404 Si el recurso es público y no existe o redirección 3xx
- de lo contrario:
- 401 Si no se ha iniciado sesión o la sesión caducó
- 403 Si el usuario no tiene permiso para acceder a Recurso (archivo, JSON, ...)
- 404 Si el recurso no existe o no está dispuesto a revelar nada, o redirección 3xx
no autorizado : Código de estado (401) que indica que la solicitud requiere autenticación , generalmente esto significa que el usuario debe iniciar sesión (sesión). Usuario / Agente desconocido por el servidor. Puede repetir con otras credenciales. NOTA: Esto es confuso, ya que esto debería haber sido nombrado 'no autenticado' en lugar de "no autorizado". Esto también puede suceder después de iniciar sesión si la sesión caducó. CASO ESPECIAL: se puede utilizar en lugar de 404 para evitar revelar la presencia o la no presencia de recursos (créditos @gingerconeninija)
Prohibido : Código de estado (403) que indica que el servidor entendió la solicitud, pero se negó a cumplirla. Usuario / agente conocido por el servidor pero tiene credenciales insuficientes . La solicitud de repetición no funcionará, a menos que cambien las credenciales, lo que es muy poco probable en un período de tiempo corto. CASO ESPECIAL: se puede utilizar en lugar de 404 para evitar revelar la presencia o la no presencia de recursos (créditos @gingerconeninija)
no encontrado : Código de estado (404) que indica que el recurso solicitado no está disponible. El usuario / agente conocido, pero el servidor no revelará nada sobre el recurso, lo hace como si no existe. La repetición no funcionará. Este es un uso especial de 404 (GitHub lo hace, por ejemplo).
Como se mencionó en @chrish, hay algunas opciones para redirección 3xx (301, 302, 303, 307 o no redirigiendo en absoluto y usando un 401):
Según rfc 2616 (http / 1.1) 403 se envía cuando:
El servidor entendió la solicitud, pero se niega a cumplirlo.La autorización no ayudará y la solicitud no debe repetirse.Si el método de solicitud no fue la cabeza y el servidor desea hacer público por qué la solicitud no se ha cumplido, debe describir la razón de la negativa en la entidad.Si el servidor no desea que esta información esté disponible para el cliente, el código de estado 404 (no encontrado) se puede usar en su lugar
En otras palabras, si el cliente puede obtener acceso al recurso al autenticar, se debe enviar 401.
asumiendo la autenticación HTTP ( www-autenticate y encabezados) encabezados) está en uso , si se autenticando como otro El usuario otorgaría acceso al recurso solicitado, luego se debe devolver 401 no autorizados.
403 Prohibido se usa cuando se le prohíbe el acceso al recurso a todos o restringidos a una red dada o se permite solo sobre SSL, lo que sea, siempre que esté relacionado con la autenticación HTTP.
Si la autenticación HTTP no está en uso y el servicio Un esquema de autenticación basado en cookies como la norma hoy en día, entonces se debe devolver un 403 o un 404.
Con respecto a 401, esto es de RFC 7235 (Protocolo de transferencia de hipertexto (HTTP / 1.1): Autenticación):
3.1. 401 no autorizado
El código de estado 401 (no autorizado) indica que la solicitud tiene no se ha aplicado porque carece de credenciales de autenticación válidas para el recurso de destino. El servidor de origen debe enviar un Www-autenticar el campo de encabezado (sección 4.4) que contiene al menos uno Desafío aplicable al recurso de destino. si la solicitud Incluye credenciales de autenticación, luego la respuesta 401 indica que la autorización ha sido rechazada para aquellos credenciales . El cliente puede repetir la solicitud con un nuevo o Campo de encabezado de autorización reemplazado (sección 4.1). Si el 401 La respuesta contiene el mismo desafío que la respuesta anterior, y la El agente de usuario ya ha intentado la autenticación al menos una vez, entonces El agente de usuario debe presentar la representación adjunta a la El usuario, ya que generalmente contiene información de diagnóstico relevante.
La semántica de 403 (y 404) ha cambiado con el tiempo. Esto es de 1999 (RFC 2616):
10.4.4 403 Prohibido
El servidor entendió la solicitud, pero se niega a cumplirla.
La autorización no ayudará y la solicitud no debe repetirse.
Si el método de solicitud no era la cabeza y el servidor desea hacer
Público por qué la solicitud no se ha cumplido, debe describir el Motivo de la negativa en la entidad. Si el servidor no desea Haga que esta información esté disponible para el cliente, el código de estado 404
(No encontrado) se puede utilizar en su lugar.
en 2014 RFC 7231 (Protocolo de transferencia de hipertexto (HTTP / 1.1): semántica y contenido) cambió el significado de 403:
6.5.3. 403 prohibido
El código de estado 403 (prohibido) indica que el servidor entendió la solicitud, pero se niega a autorizarlo. Un servidor que Desea hacer público por qué la solicitud ha sido prohibida puede Describa esa razón en la carga útil de respuesta (si corresponde).
Si se proporcionaron credenciales de autenticación en la solicitud, el
El servidor los considera insuficientes para otorgar acceso. El cliente de
No debe repetir automáticamente la solicitud con el mismo
cartas credenciales. El cliente puede repetir la solicitud con nuevos o diferentes. cartas credenciales. Sin embargo, una solicitud podría estar prohibida por razones de
no relacionado con las credenciales.Un servidor de origen que desea "ocultar" la existencia actual de un
El recurso objetivo prohibido puede responder con un código de estado de
404 (no encontrado).
Por lo tanto, un 403 (o un 404) ahora podría significar sobre cualquier cosa. Proporcionar nuevas credenciales podría ayudar ... o podría no.
Creo que la razón por la cual esto ha cambiado es RFC 2616 Asumido que la autenticación HTTP se utilizará cuando se encuentren en la práctica, las aplicaciones web de hoy crezcan esquemas de autenticación personalizados usando, por ejemplo, formularios y cookies.
- 401 no autorizado : No sé quién eres. este error de autenticación.
- 403 Prohibido : Sé quién eres, pero no tienes permiso para acceder a este recurso. Este es un error de autorización.
Esta es una pregunta más antigua, pero una opción que nunca se mencionó realmente fue devolver un 404. Desde una perspectiva de seguridad, la respuesta votada más alta sufre de un potencial vulnerabilidad de fugas de información .Diga, por ejemplo, que la página web segura en cuestión sea una página de administración del sistema, o quizás más comúnmente, es un registro en un sistema en el que el usuario no tiene acceso.Idealmente, no querría que un usuario malicioso sepa que sepa que hay una página / registro allí, y mucho menos que no tienen acceso.Cuando estoy construyendo algo como esto, intentaré registrar solicitudes de un autenticado / no autorizado en un registro interno, pero devolverá un 404.
OWASP tiene un poco Más información sobre cómo un atacante podría usar este tipode información como parte de un ataque.
Se hizo esta pregunta hace algún tiempo, pero el pensamiento de la gente se mueve.
Sección 6.5.3 en este borrador (autorizado por Fielding y Reschoke) proporciona un código de estado 403 un significado ligeramente diferente a uno documentado en rfc 2616 .
Refleja lo que sucede en los esquemas de autenticación y autorización empleados por una serie de servidores web y marcos populares.
He enfatizado el bit, creo que es más destacado.
6.5.3. 403 prohibido
El código de estado 403 (prohibido) indica que el servidor entendió la solicitud, pero se niega a autorizarlo. Un servidor que desea hacer público por qué la solicitud ha sido prohibida puede describir esa razón en la carga útil de respuesta (si corresponde).
Si se proporcionaron credenciales de autenticación en la solicitud, el servidor los considera insuficientes para otorgar acceso. El cliente no debe repetir la solicitud con las mismas credenciales. El cliente puede repetir la solicitud con credenciales nuevas o diferentes. Sin embargo, una solicitud podría estar prohibida por razones no relacionadas con las credenciales.
Un servidor de origen que desea "ocultar" la existencia actual de un recurso objetivo prohibido puede responder con un código de estado de 404 (no encontrado).
Cualquier convención que utilice, lo importante es proporcionar una uniformidad en su sitio / API.
TL; DR
- 401: una negativa que tiene que ver con la autenticación
- 403: una negativa que no tiene nada que ver con la autenticación
Ejemplos prácticos
Si apache requiere autenticación (a través de .htaccess), y usted llega a Cancel, responderá con un 401 Authorization Required
Si nginx encuentra un archivo, pero no tiene los derechos de acceso (usuario / grupo) para leerlo / acceder, responderá con 403 Forbidden
RFC (2616 SECCIÓN 10)
401 no autorizado (10.4.2)
Significado 1: necesita autenticar
La solicitud requiere autenticación del usuario. ...
Significado 2: Autenticación insuficiente
... Si la solicitud ya incluía credenciales de autorización, entonces la respuesta 401 indica que la autorización ha sido rechazada para esas credenciales. ...
403 Prohibido (10.4.4)
Significado: no relacionado con la autenticación
... La autorización no ayudará a ...
Más detalles:
-
El servidor entendió la solicitud, pero se niega a cumplirlo.
-
Debe describir la razón de la negativa en la entidad
-
El código de estado 404 (no encontrado) se puede usar en su lugar
(Si el servidor quiere mantener esta información del cliente)
no están conectados o no pertenecen al grupo de usuarios adecuado
Usted ha declarado dos casos diferentes; Cada caso debe tener una respuesta diferente:
- Si no han iniciado sesión en absoluto, debe devolver 401 no autorizado
- Si están iniciando sesión, pero no pertenecen al grupo de usuarios adecuado, debe devolver 403 prohibido
Nota sobre el RFC basado en comentarios recibidos a esta respuesta:
Si el usuario no está registrado, no están autenticados, cuyo equivalente HTTP es 401 y se llama incorrectamente no autorizado en el RFC. Como Sección 10.4.2 Estados para 401 no autorizado :
"La solicitud requiere la autenticación
".
Si no está autorizado, 401 es la respuesta correcta. Sin embargo, si no está autorizado, en el sentido semánticamente correcto, 403 es la respuesta correcta.
en inglés:
401
Posiblemente se le permite el acceso, pero por alguna razón en esta solicitud fue negado.Como una mala contraseña?Inténtalo de nuevo, con la solicitud correcta. obtendrá una respuesta de éxito en su lugar.
403
No lo estás, nunca, permitido.Tu nombre no está en la lista, no lo hará alguna vez ingrese, desaparezca, no envíe una solicitud de nuevo intento, será rechazado, siempre.Desaparecer.
Estos son los significados:
401 : usuario no (correctamente) autenticado, el recurso / página requiere autenticación
403 : el usuario autenticado, pero su función o permisos no permite acceder a un recurso solicitado, por ejemplo, el usuario no es un administrador y la página solicitada es para los administradores
Esto es más sencillo en mi cabeza que en cualquier lugar aquí, así que:
401: Necesita autenticación HTTP básica para ver esto.
403: No puede ver esto, y HTTP Basic Auth no lo ayudará.
Si el usuario solo necesita iniciar sesión con el formulario de inicio de sesión HTML estándar de su sitio, 401 no sería apropiado porque es específico para la autenticación básica HTTP.
No recomiendo usar 403 para negar el acceso a las cosas como /includes, porque en lo que respecta a la web, esos recursos no existen en absoluto y, por lo tanto, deben 404.
Esto deja 403 como "Necesitas estar conectado".
En otras palabras, 403 significa "Este recurso requiere algún tipo de autenticación que no sea HTTP Basic Auth".
https://www.w3.org/protocols/RFC2616/RFC2616-SEC10.HTML#SEC10.4.2
Creo que es importante considerar que, a un navegador, 401 inicia un diálogo de autenticación para que el usuario ingrese a nuevas credenciales, mientras que 403 no lo hace. Los navegadores piensan que, si se devuelve un 401, entonces el usuario debe volver a autenticarse. Entonces, 401 significa autenticación no válida, mientras que 403 representa una falta de permiso.
Aquí hay algunos casos en la lógica donde se devolverá un error de la autenticación o la autorización, con frases importantes en negrita.
- Un recurso requiere autenticación pero sin credenciales fueron especificados .
401 : el cliente debe especificar las credenciales.
- Las credenciales especificadas están en un formato no válido .
400 : Eso no es 401 ni 403, ya que los errores de sintaxis siempre deben devolver 400.
- Las credenciales especificadas hacen referencia a usuario que no existe .
401 : el cliente debe especificar credenciales válidas.
- Las credenciales especificadas son inválidas , pero especifiquen un usuario válido (o no especifique un usuario si no se requiere un usuario específico).
401 : nuevamente, el cliente debe especificar credenciales válidas.
- Las credenciales especificadas tienen caducado .
401 : esto es prácticamente lo mismo que tener credenciales inválidas en general, por lo que el cliente debe especificar las credenciales válidas.
- Las credenciales especificadas son completamente válidas, pero no son suficiente el recurso particular , aunque es posible que las credenciales con más permiso puedan.
403 : la especificación de credenciales válidas no otorgaría el acceso al recurso, ya que las credenciales actuales ya son válidas, pero solo no tienen permiso.
- el recurso es inaccesible independientemente de las credenciales.
403 : esto es independientemente de las credenciales, por lo que la especificación de las credenciales válidas no puede ayudar.
- Las credenciales especificadas son completamente válidas, pero el client es bloqueado de usarlos.
403 : Si el cliente está bloqueado, la especificación de nuevas credenciales no hará nada.
Given the latest RFC's on the matter (7231 and 7235) the use-case seems quite clear (italics added):
- 401 is for unauthenticated ("lacks valid authentication"); i.e. 'I don't know who you are, or I don't trust you are who you say you are.'
401 Unauthorized
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
- 403 is for unauthorized ("refuses to authorize"); i.e. 'I know who you are, but you don't have permission to access this resource.'
403 Forbidden
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
In the case of 401 vs 403, this has been answered many times. This is essentially a 'HTTP request environment' debate, not an 'application' debate.
There seems to be a question on the roll-your-own-login issue (application).
In this case, simply not being logged in is not sufficient to send a 401 or a 403, unless you use HTTP Auth vs a login page (not tied to setting HTTP Auth). It sounds like you may be looking for a "201 Created", with a roll-your-own-login screen present (instead of the requested resource) for the application-level access to a file. This says:
"I heard you, it's here, but try this instead (you are not allowed to see it)"
