Question 403 Interdit contre 401 Réponses HTTP non autorisées


Pour une page Web existante, mais pour laquelle un utilisateur ne dispose pas de privilèges suffisants (ils ne sont pas connectés ou n'appartiennent pas au groupe d'utilisateurs approprié), quelle est la bonne réponse HTTP à diffuser? 401? 403? Autre chose? Ce que j'ai lu jusqu'à présent n'est pas très clair sur la différence entre les deux. Quels cas d'utilisation sont appropriés pour chaque réponse?


1896
2017-07-21 07:21


origine


Réponses:


Une explication claire de Daniel Irvine:

Il y a un problème avec 401 Non autorisé, le code d'état HTTP pour les erreurs d'authentification. Et c'est tout: c'est pour l'authentification, pas pour l'autorisation.   Réception d'une réponse 401 est le serveur vous disant, "vous n'êtes pas   authentifié - soit pas authentifié du tout ou authentifié   incorrectement, mais s'il vous plaît réauthentifier et réessayer. "Pour vous aider,   il inclura toujours un WWW-Authentifier en-tête qui décrit comment   authentifier.

C'est une réponse généralement renvoyée par votre serveur web, pas votre web   application.

C'est aussi quelque chose de très temporaire. le serveur vous demande d'essayer   encore.

Donc, pour l'autorisation, j'utilise le 403 Interdit réponse. Ses   permanent, c'est lié à ma logique d'application, et c'est plus concret   réponse qu'un 401.

Réception d'une réponse 403 est le serveur vous disant: «Je suis désolé. je connais   qui vous êtes - je crois que vous dites que vous êtes - mais vous n'avez tout simplement pas   permission d'accéder à cette ressource. Peut-être que si vous demandez au système   Administrateur bien, vous obtiendrez la permission. Mais s'il te plait ne t'embête pas   moi encore jusqu'à ce que votre situation change. "

En résumé, un 401 Non autorisé la réponse devrait être utilisée pour manquer   ou une mauvaise authentification, et un 403 Interdit la réponse devrait être utilisée   ensuite, lorsque l'utilisateur est authentifié mais n'est pas autorisé à   effectuer l'opération demandée sur la ressource donnée.

Un autre joli format pictural de la façon dont les codes d'état http devraient être utilisés.


2828
2017-08-04 06:24



Voir RFC2616:

401 Non autorisé:

Si la demande contenait déjà des informations d'identification d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification.

403 Interdit:

Le serveur a compris la requête, mais refuse de l'exécuter.

Mettre à jour

De votre cas d'utilisation, il semble que l'utilisateur n'est pas authentifié. Je reviendrais 401.


Modifier: RFC2616 est obsolète, voir RFC7231 et RFC7235.


336
2017-07-21 07:28



Quelque chose que les autres réponses manquent est qu'il doit être compris que Authentication and Authorization dans le contexte de la RFC 2616 se réfère UNIQUEMENT au protocole d'authentification HTTP de RFC 2617. L'authentification par des schémas en dehors de RFC2617 ne sont pas supportées dans les codes d'état HTTP au moment de décider d'utiliser 401 ou 403 ..

Bref et laconique

Non autorisé indique que le client n'est pas authentifié RFC2617 et que le serveur initie le processus d'authentification. Interdit indique que le client est RFC2617 authentifié et n'a pas d'autorisation ou que le serveur ne prend pas en charge RFC2617 pour la ressource demandée.

Cela signifie que si vous avez votre propre processus de connexion roll-to-own et n'utilisez jamais l'authentification HTTP, 403 est toujours la bonne réponse et 401 ne devrait jamais être utilisé.

Détaillé et approfondi

De RFC2616

10.4.2 401 Non autorisé

La requête nécessite l'authentification de l'utilisateur. La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (section 14.47) contenant un défi applicable à la ressource demandée. Le client PEUT répéter la demande avec un champ d'en-tête Autorisation approprié (section 14.8).

et

10.4.4 403 Interdit   Le serveur a compris la requête, mais refuse de l'exécuter. L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée.

La première chose à garder à l'esprit est que "Authentification" et "Autorisation" dans le contexte de ce document se réfèrent spécifiquement aux protocoles d'authentification HTTP de la RFC 2617. Ils ne se réfèrent à aucun protocole d'authentification que vous avez créé en utilisant les pages de connexion, etc. Je vais utiliser "login" pour faire référence à l'authentification et l'autorisation par des méthodes autres que RFC2617

Donc, la vraie différence n'est pas quel est le problème ou même s'il y a une solution. La différence est ce que le serveur attend du client.

401 indique que la ressource ne peut pas être fournie, mais le serveur DEMANDE que le client se connecte via l'authentification HTTP et envoie des en-têtes de réponse pour lancer le processus. Il y a peut-être des autorisations qui permettront d'accéder à la ressource, peut-être pas, mais essayons de voir ce qui se passe.

403 indique que la ressource ne peut pas être fournie et il n'y a, pour l'utilisateur actuel, aucun moyen de résoudre ce problème via RFC2617 et aucun point d'essai. Cela peut être dû au fait qu'il est connu qu'aucun niveau d'authentification n'est suffisant (par exemple à cause d'une liste noire IP), mais cela peut être dû au fait que l'utilisateur est déjà authentifié et n'a pas d'autorité. Le modèle RFC2617 est un-utilisateur, un-credentials de sorte que le cas où l'utilisateur peut avoir un deuxième ensemble d'informations d'identification qui pourrait être autorisé peut être ignoré. Il ne suggère ni n'implique qu'une sorte de page de connexion ou un autre protocole d'authentification autre que RFC2617 peut ou non aider - c'est en dehors des normes et de la définition du RFC2616.


Modifier: RFC2616 est obsolète, voir RFC7231 et RFC7235.


254
2018-02-05 17:14



Selon RFC 2616 (HTTP / 1.1) 403 est envoyé lorsque:

Le serveur a compris la requête, mais refuse de l'exécuter. L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée. Si la méthode de requête n'était pas HEAD et que le serveur souhaite rendre public pourquoi la requête n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas mettre cette information à la disposition du client, le code d'état 404 (Not Found) peut être utilisé à la place.

En d'autres termes, si le client peut avoir accès à la ressource en s'authentifiant, 401 doit être envoyé.


94
2017-07-21 07:26



TL; DR version

    GET ressource, existe?
    | |
    | |
    v v
NO: 404 OUI: Est-il authentifié?
             | |
             | |
             v v
           NON: 401 OUI: Peut accéder à la ressource?
           (ou: 404) | |
           ou 301 | |
           rediriger v v
           se connecter NO: 403 OK 200, 301, ...

Les chèques sont généralement effectués dans cet ordre:

  • 401 si non connecté ou session expirée
  • 403 si l'utilisateur n'a pas l'autorisation d'accéder à la ressource
  • 404 si la ressource n'existe pas

NON AUTORISÉ: Code d'état (401) indiquant que la demande nécessite authentification. Utilisateur / agent inconnu du serveur. Peut répéter avec d'autres informations d'identification. NOTE: Ceci est déroutant car cela aurait dû être nommé «non authentifié» au lieu de «non autorisé».

INTERDIT: Code d'état (403) indiquant que le serveur a compris la demande mais a refusé de la remplir. Utilisateur / agent connu du serveur mais ayant références insuffisantes. La demande répétée ne fonctionnera pas.

PAS TROUVÉ: Code d'état (404) indiquant que la ressource demandée n'est pas disponible. Utilisateur / agent connu mais le serveur ne révélera rien sur la ressource, fait comme s'il n'existait pas. Répéter ne fonctionnera pas. C'est une utilisation spéciale de 404 (github le fait par exemple).


46
2018-02-23 11:00



Si l'authentification comme un autre utilisateur accorderait l'accès à la ressource demandée, alors 401 Non autorisé devrait être retourné. 403 Interdit est principalement utilisé lorsque l'accès à la ressource est interdit à tout le monde ou restreint à un réseau donné ou autorisé uniquement via SSL, aussi longtemps que cela n'est pas lié à l'authentification.

De la RFC 7235 (protocole de transfert hypertexte (HTTP / 1.1): authentification):

3.1. 401 Non autorisé

Le code d'état 401 (Non autorisé) indique que la demande a   pas été appliqué car il manque d'informations d'authentification valides   pour la ressource cible. Le serveur d'origine DOIT envoyer un   WWW-Authentifier le champ d'en-tête (section 4.4) contenant au moins un   défi applicable à la ressource cible. Si la demande   inclus les informations d'authentification, puis la réponse 401   indique que l'autorisation a été refusée pour les   lettres de créance. Le client PEUT répéter la demande avec un nouveau ou   remplacée Champ d'en-tête Autorisation (Section 4.1). Si le 401   réponse contient le même défi que la réponse antérieure, et le   l'agent utilisateur a déjà tenté l'authentification au moins une fois, puis   l'agent utilisateur DEVRAIT présenter la représentation ci-jointe à   utilisateur, car il contient généralement des informations de diagnostic pertinentes.

Et c'est de la RFC 2616:

10.4.4 403 Interdit

Le serveur a compris la requête, mais refuse de l'exécuter.
L'autorisation n'aidera pas et la demande NE DEVRAIT PAS être répétée.
  Si la méthode de requête n'était pas HEAD et que le serveur souhaite effectuer
  public pourquoi la demande n'a pas été remplie, il DEVRAIT décrire le   raison du refus dans l'entité. Si le serveur ne souhaite pas   mettre cette information à la disposition du client, le code d'état 404
  (Non trouvé) peut être utilisé à la place.

Edit: RFC 7231 (protocole de transfert hypertexte (HTTP / 1.1): sémantique et contenu) modifie la signification de 403:

6.5.3. 403 Interdit

Le code d'état 403 (Interdit) indique que le serveur   compris la demande mais refuse de l'autoriser. Un serveur qui   souhaite rendre public pourquoi la demande a été interdite peut   décrire cette raison dans la charge utile de la réponse (le cas échéant).

Si les informations d'authentification étaient fournies dans la requête, le
  le serveur les considère insuffisantes pour accorder l'accès. Le client
  NE DEVRAIT PAS répéter automatiquement la demande avec le même
  lettres de créance. Le client PEUT répéter la demande avec nouveau ou différent   lettres de créance. Cependant, une demande peut être interdite pour des raisons
  sans rapport avec les informations d'identification.

Un serveur d'origine qui souhaite "cacher" l'existence actuelle d'un
  ressource cible interdite PEUT répondre à la place avec un code d'état de
  404 (non trouvé).

Ainsi, un 403 pourrait maintenant signifier n'importe quoi. Fournir de nouvelles informations d'identification peut aider ... ou peut-être pas.


37
2018-02-27 09:44



Ceci est une question plus ancienne, mais une option qui n'a jamais été vraiment soulevée était de retourner un 404. D'un point de vue de sécurité, la réponse la plus votée souffre d'un potentiel fuite d'informations vulnérabilité. Supposons, par exemple, que la page Web sécurisée en question soit une page d'administration système, ou plus communément, soit un enregistrement dans un système auquel l'utilisateur n'a pas accès. Idéalement, vous ne voudriez pas qu'un utilisateur malveillant sache qu'il y a une page / un enregistrement là-bas, et encore moins qu'il n'y a pas accès. Quand je construis quelque chose comme ça, je vais essayer d'enregistrer des requêtes non authentifiées / non autorisées dans un journal interne, mais retourner un 404.

OWASP a quelques Plus d'information sur la façon dont un attaquant pourrait utiliser ce type d'information dans le cadre d'une attaque.


20
2017-12-25 09:09



Cette question a été posée il y a quelque temps, mais la réflexion des gens continue.

Section 6.5.3 Dans ce projet (rédigé par Fielding et Reschke), le code d'état 403 a une signification légèrement différente de celle RFC 2616.

Il reflète ce qui se passe dans les schémas d'authentification et d'autorisation employés par un certain nombre de serveurs Web et de frameworks populaires.

J'ai mis l'accent sur le bit qui me semble le plus saillant.

6.5.3. 403 Interdit

Le code d'état 403 (Interdit) indique que le serveur a compris la requête mais refuse de l'autoriser. Un serveur qui souhaite rendre public pourquoi la requête a été interdite peut décrire cette raison dans la charge utile de réponse (le cas échéant).

Si les informations d'authentification ont été fournies dans la requête, le serveur les considère comme insuffisantes pour accorder l'accès. Le client NE DEVRAIT PAS répéter la demande avec les mêmes informations d'identification. Le client PEUT répéter la demande avec des informations d'identification nouvelles ou différentes.  Cependant, une requête peut être interdite pour des raisons indépendantes des informations d'identification.

Un serveur d'origine qui souhaite "cacher" l'existence actuelle d'une ressource cible interdite PEUT répondre à la place avec un code d'état de 404 (non trouvé).

Quelle que soit la convention que vous utilisez, l'important est de fournir une uniformité sur votre site / API.


19
2018-05-22 10:54



TL; DR

  • 401: Un refus lié à l'authentification
  • 403: Un refus qui n'a RIEN à voir avec l'authentification

Exemples pratiques

Si apache  nécessite une authentification (via .htaccess), et vous frappez Cancel, il répondra avec un 401 Authorization Required

Si nginx trouve un fichier, mais n'a pas des droits d'accès (utilisateur / groupe) pour lire / accéder, il répondra avec 403 Forbidden

RFC (2616 Section 10)

401 Non autorisé (10.4.2)

Signification 1: Besoin d'authentifier

La requête nécessite l'authentification de l'utilisateur. ...

Signification 2: Authentification insuffisante

... Si la demande contenait déjà des informations d'identification d'autorisation, la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification. ...

403 Interdit (10.4.4)

Sens: Sans rapport avec l'authentification

... L'autorisation n'aidera pas ...

Plus de détails:

  • Le serveur a compris la requête, mais refuse de l'exécuter.

  • Il DEVRAIT décrire la raison du refus dans l'entité

  • Le code d'état 404 (Non trouvé) peut être utilisé à la place

    (Si le serveur veut conserver cette information du client)


9
2018-02-25 09:03



ils ne sont pas connectés ou n'appartiennent pas au groupe d'utilisateurs approprié

Vous avez déclaré deux cas différents; chaque cas devrait avoir une réponse différente:

  1. S'ils ne sont pas connectés du tout, vous devriez retourner 401 Non autorisé
  2. S'ils sont connectés mais n'appartiennent pas au groupe d'utilisateurs approprié, vous devez retourner 403 Interdit

7
2017-10-01 14:34