403 Forbidden vs 401 non autorisé des réponses HTTP

https://stackoverflow.com/questions/3297048

18-09-2020
|

Question

Pour une page web qui existe, mais pour lequel un utilisateur ne dispose pas des privilèges suffisants (ils ne sont pas connecté ou n'appartiennent pas à l'utilisateur de groupe), quelle est la bonne réponse HTTP servir?

401 Unauthorized?
403 Forbidden?
Quelque chose d'autre?

Ce que j'ai lu sur chaque mesure n'est pas très clair sur la différence entre les deux.Ce cas d'utilisation appropriées pour chaque réponse?

La solution

Une explication claire de Daniel Irvine:

Il y a un problème avec 401 non autorisé, le code de statut HTTP pour les erreurs d'authentification.Et c'est tout:c'est à des fins d'authentification, pas d'autorisation.La réception d'une réponse 401 est le serveur vous dit, “vous n'êtes pas authentifié–pas authentifiée ou authentifié à tort–mais veuillez vous authentifier et essayez à nouveau.” Pour vous aider, il sera toujours inclure un WWW-Authenticate l'en-tête qui décrit comment pour s'authentifier.

C'est une réponse généralement retournés par votre serveur web, pas votre site web application.

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

Donc, pour obtenir l'autorisation-je utiliser l' 403 Forbidden réponse.C'est permanent, c'est lié à ma demande de la logique, et c'est plus concret réponse qu'un 401.

La réception d'une réponse 403 est le serveur vous dit, “je suis désolé.Je sais qui vous êtes, je crois, qui vous disent que vous êtes, mais vous n'avez tout simplement pas la permission d'accéder à cette ressource.Peut-être que si vous demandez au système de administrateur de bien, vous aurez la permission.Mais s'il vous plaît ne prenez pas la peine moi de nouveau jusqu'à ce que votre situation change.”

En résumé, un 401 non autorisé la réponse devrait être utilisé pour les disparus ou mauvaise authentification, et un 403 Forbidden la réponse devrait être utilisé par la suite, lorsque l'utilisateur est authentifié, mais n'est pas autorisé à effectuer l'opération demandée sur la ressource donnée.

Un autre nice picturale format de la façon dont les codes de statut http doit être utilisé.

Autres conseils

Voir RFC2616:

401 non autorisé:

Si la demande déjà inclus Autorisation des informations d'identification, puis 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 la satisfaire.

Mise à jour

À partir de votre cas d'utilisation, il apparaît que l'utilisateur n'est pas authentifié.Je serait de retour 401.

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

Quelque chose que les autres réponses sont manquantes, c'est qu'il doit être entendu que l'Authentification et l'Autorisation dans le cadre de la RFC 2616 se réfère UNIQUEMENT à l'Authentification HTTP de protocole RFC 2617.L'authentification par les régimes en dehors de RFC2617 n'est pas pris en charge dans les codes d'état HTTP et ne sont pas considérés au moment de décider si l'utilisation de 401 ou 403.

Bref et Laconique

Non autorisée indique que le client n'est pas RFC2617 authentifié, le serveur est en train d'initier le processus d'authentification.Interdit indique que le client est RFC2617 authentifié et ne dispose pas de l'autorisation ou que le serveur ne prend pas en charge RFC2617 de la ressource demandée.

De sens que si vous avez votre propre rouleau de-votre-propre processus de connexion et de ne jamais utiliser l'Authentification HTTP, 403 est toujours la bonne réponse et 401 ne doit jamais être utilisé.

Détaillée et En Profondeur

À partir de la RFC2616

10.4.2 401 non autorisé

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

10.4.4 403 Forbidden Le serveur a compris la requête, mais refuse de l'exécuter.L'autorisation ne sera pas l'aide et de la demande ne DOIT PAS être répété.

La première chose à garder à l'esprit est que "Authentification" et "Autorisation" dans le contexte de ce document, se référer spécifiquement à la HTTP protocoles d'Authentification à partir de la RFC 2617.Ils ne se réfèrent pas à n'importe quel rouleau-votre-propre protocoles d'authentification que vous avez créés à l'aide de pages de connexion, etc.Je vais utiliser "login" pour se référer à l'authentification et l'autorisation, par des méthodes autres que RFC2617

Donc, la différence n'est pas ce qui est le problème, ou même si il y a une solution.La différence est que le serveur attend le client à faire.

401 indique que la ressource ne peut pas être fournie, mais le serveur demande au client de se connecter en utilisant l'Authentification HTTP et a envoyé des en-têtes de réponse pour lancer le processus.Éventuellement il y a des autorisations qui vous permettra d'avoir accès à la ressource, éventuellement, il n'y a pas, mais nous allons lui donner un essai et voir ce qui se passe.

403 indique que la ressource ne peut pas être fourni et il n'est, pour l'utilisateur actuel, aucun moyen de résoudre ce par le biais de RFC2617 et pas la peine d'essayer.Ce peut être parce qu'il est connu qu'aucun niveau d'authentification est suffisant (par exemple à cause d'une IP en liste noire), mais il est peut-être parce que l'utilisateur est déjà authentifié et n'a pas de pouvoir.Le RFC2617 modèle est un utilisateur, l'une des informations d'identification pour le cas où l'utilisateur peut avoir un deuxième ensemble d'informations qui pourraient être autorisés peuvent être ignorés.Il ne suggère ni implique qu'une certaine sorte de page de connexion ou d'autres non-RFC2617 protocole d'authentification peut ou ne peut pas aider - qui est à l'extérieur de la RFC2616 des normes et de la définition.

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

  +-----------------------
  | 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)

Les contrôles sont généralement fait dans cet ordre:

404 si la ressource est public et n'existe pas ou 3xx redirection
SINON:
401 si n'est pas connecté ou session a expiré
403 si l'utilisateur n'est pas autorisé à accéder à la ressource (fichier, json, ...)
404 si la ressource n'existe pas ou ne veulent pas révéler quoi que ce soit, ou 3xx redirection

Non autorisé:Le code d'état (401), indiquant que la demande l'exige l'authentification, habituellement, cela signifie que l'utilisateur doit être connecté (session).L'utilisateur/agent inconnu par le serveur.Pouvez répéter avec d'autres informations d'identification.NOTE:Ceci est source de confusion, comme cela aurait dû être nommé "authentifié" au lieu de "non autorisé".Cela peut également se produire après la connexion si la session a expiré.Cas particulier:Peut être utilisé au lieu de 404 pour éviter de révéler la présence ou non-présence de ressources (crédits @gingerCodeNinja)

INTERDIT:Le code d'état (403) indiquant que le serveur a compris la requête, mais refuse de la satisfaire.L'utilisateur/agent connues par le serveur mais a l'insuffisance des informations d'identification.Répéter la demande ne fonctionnera pas, à moins que les informations d'identification changé, ce qui est très rare dans un court laps de temps.Cas particulier:Peut être utilisé au lieu de 404 pour éviter de révéler la présence ou non-présence de ressources (crédits @gingerCodeNinja)

PAS TROUVÉ:Le code d'état (404) indiquant que la ressource demandée n'est pas disponible.L'utilisateur/agent connu, mais le serveur ne révèle rien sur la ressource, fait comme si elle n'existe pas.Répéter ne fonctionnera pas.C'est une utilisation particulière de 404 (github t-il, par exemple).

Comme mentionné par @ChrisH, il ya quelques options pour la redirection 3xx (301, 302, 303, 307 ou non la redirection à tous et à l'aide d'un 401):

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

Le serveur a compris la requête, mais refuse de la satisfaire.L'autorisation ne sera pas l'aide et de la demande ne DOIT PAS être répété.Si la méthode de la requête n'a pas été la TÊTE et le serveur souhaite rendre public pourquoi la demande n'a pas été remplies, il DOIT décrire la raison du refus, dans l'entité.Si le serveur ne souhaite pas rendre cette information disponible pour le client, le code d'état 404 (Non Trouvé) peut être utilisé à la place

En d'autres termes, si le client PEUT avoir accès à la ressource par l'authentification, 401 doit être envoyée.

En supposant que l'authentification HTTP (WWW-Authenticate et Autorisation les en-têtes) est en cours d'utilisation, si l'authentification en tant qu'autre utilisateur d'accorder l'accès à la ressource demandée, puis 401 non autorisé doit être retourné.

403 Forbidden est utilisé lors de l'accès à la ressource est interdit à toute personne, ou limité à un réseau donné ou autorisé uniquement sur SSL, peu importe pourvu qu'il n'est pas lié à l'authentification HTTP.

Si l'authentification HTTP n'est pas en cours d'utilisation et le service d'un cookie d'authentification basée sur le schéma, qui est la norme de nos jours, puis une 403 ou 404 doit être retourné.

Concernant 401, c'est de la RFC 7235 (Protocole de Transfert Hypertexte (HTTP/1.1):Authentification):

3.1.401 non autorisé

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

La sémantique de 403 (et 404) ont changé au fil du temps.C'est à partir de 1999 (RFC 2616):

10.4.4 403 Forbidden

Le serveur a compris la requête, mais refuse de la satisfaire.
L'autorisation ne va pas aider et la demande ne DOIT PAS être répété.
Si la méthode de la requête n'a pas été la TÊTE et le serveur souhaite faire
public pourquoi la demande n'a pas été remplies, il DOIT décrire le la raison pour le refus de l'entité.Si le serveur ne souhaite pas rendre cette information disponible pour le client, le code d'état 404
(Pas Trouvé) peut être utilisé à la place.

En 2014 RFC 7231 (Protocole de Transfert Hypertexte (HTTP/1.1):La sémantique et le Contenu) a changé le sens de 403:

6.5.3.403 Forbidden

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

Si les informations d'authentification ont été fournis dans la demande, le
serveur les juge insuffisantes pour accorder l'accès.Le client
Ne DOIT PAS répéter automatiquement la demande avec la même
les informations d'identification.Le client PEUT répéter la demande avec de nouveau ou de différent les informations d'identification.Toutefois, une demande peut être interdit pour des raisons
sans rapport avec les informations d'identification.

Un serveur d'origine, qui se veut "cacher" de l'existence actuelle d'un
interdit cible de la ressource au lieu de répondre avec un code d'état de
404 (Non Trouvé).

Ainsi, un 403 (ou un 404) peut maintenant dire à propos de quoi que ce soit.En fournissant de nouvelles informations d'identification peuvent aider...ou il ne pourrait pas.

Je crois que la raison pour laquelle ce qui a changé, c'est la RFC 2616 suppose l'authentification HTTP peut être utilisé lorsque, dans la pratique, aujourd'hui, des applications Web construire des schémas d'authentification personnalisés en utilisant par exemple les formulaires et les cookies.

401 non autorisé:Je ne sais pas qui vous êtes. Ce une erreur d'authentification.
403 Forbidden:Je sais qui vous êtes, mais vous n'avez pas la permission d'accéder à cette ressource. C'est une autorisation d'erreur.

C'est une vieille question, mais une option qui n'a jamais vraiment était de retourner une erreur 404.À partir d'un point de vue sécurité, le plus voté réponse souffre d'un potentiel la fuite d'informations de la vulnérabilité.Dire, par exemple, que la page web sécurisée en question est un système d'admin de la page, ou peut-être, le plus souvent, est un enregistrement dans un système que l'utilisateur n'a pas accès.Idéalement, vous ne voulez pas qu'un utilisateur malveillant de même savoir qu'il y a une page / dossier il y, a fortiori, qu'ils n'ont pas accès.Quand je suis en train de construire quelque chose comme cela, je vais essayer de l'enregistrer unauthenticate / requêtes non autorisées à l'intérieur du journal, mais de renvoyer une 404.

OWASP a certains plus d'informations comment un attaquant pourrait utiliser ce type d'informations dans le cadre d'une attaque.

Cette question a été posée il y a quelques temps, mais la pensée se déplace sur.

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

Il reflète ce qui se passe dans d'authentification et d'autorisation des régimes employé par un certain nombre de populaire de serveurs web et de cadres.

J'ai souligné le peu que je pense est le plus saillant.

6.5.3.403 Forbidden

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

Si les informations d'authentification ont été fournis dans la demande, le serveur considère comme insuffisante pour accorder l'accès. Le client ne DOIT PAS répéter la demande avec les mêmes informations d'identification.Le client PEUT répéter la demande avec des nouvelles ou des informations d'identification différentes. Toutefois, une demande peut être interdit pour des raisons sans rapport avec les informations d'identification.

Un serveur d'origine, qui se veut "cacher" de l'existence actuelle d'un interdit de la cible de la ressource au lieu de répondre avec un code d'état 404 (Non Trouvé).

Quelle que soit la convention que vous utilisez, la chose importante est d'assurer l'uniformité dans l'ensemble de votre site / API.

TL;DR

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

Des Exemples Pratiques

Si apache requiert 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 les droits d'accès (utilisateur/groupe) pour lire/y accéder, il vous répondra 403 Forbidden

RFC 2616 Section 10)

401 non autorisé (10.4.2)

Sens 1: Besoin de s'authentifier

La demande nécessite une authentification de l'utilisateur....

Sens 2: L'authentification de l'insuffisance de

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

403 Forbidden (10.4.4)

Sens: Sans rapport avec l'authentification

...L'autorisation ne va pas aider ...

Plus de détails:

Le serveur a compris la requête, mais refuse de la satisfaire.
Elle DOIT 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 garder cette information de client)

ils ne sont pas connecté ou n'appartiennent pas à l'utilisateur de groupe

Vous avez dit deux cas différents;chaque cas doit avoir une réponse différente:

Si ils ne sont pas connectés à tout ce que vous devriez retourner 401 non autorisé
Si ils sont connectés, mais n'appartiennent pas à la bonne de l'utilisateur groupe, vous devez retourner 403 Forbidden

Note sur la RFC sur la base des commentaires reçus à cette réponse:

Si l'utilisateur n'est pas connecté ils sont non-authentifié, le HTTP équivalent de ce qui est de 401 et est faussement appelé non autorisée dans la RFC.Comme section 10.4.2 les états de 401 non autorisé:

"La demande requiert que l'utilisateur l'authentification."

Si vous êtes authentifié, 401 est la bonne réponse.Toutefois, si vous êtes non autorisée, dans le sémantiquement correct sens, 403 est la bonne réponse.

En Anglais:

401

Vous êtes potentiellement autorisés à accéder, mais pour une raison sur cette demande, vous avez été refusé.Comme un mauvais mot de passe?Essayez à nouveau, avec la bonne demande vous obtiendrez une réponse de réussite à la place.

403

Vous n'êtes pas, jamais, permis.Votre nom n'est pas sur la liste, vous n'aurez pas jamais dans, s'en aller, ne pas envoyer une re-essayez de demande, il sera refusé, toujours.Aller loin.

Ce sont les significations:

401:L'utilisateur n'est pas (correctement) authentifié, la ressource/page exiger l'authentification

403:L'authentification de l'utilisateur, mais son rôle ou autorisations ne permettent pas d'accéder ressource demandée, par exemple, l'utilisateur n'est pas administrateur et la page demandée est pour les administrateurs

C'est plus simple dans ma tête que partout ici, donc:

401:Vous avez besoin HTTP basic auth pour voir cela.

403:Vous ne pouvez pas voir, et HTTP basic auth ne va pas aider.

Si l'utilisateur a juste besoin de se connecter en utilisant le site du standard HTML, formulaire de connexion, 401 ne serait pas approprié car il est spécifique à HTTP basic auth.

Je ne recommandent pas l'utilisation de 403 à refuser l'accès à des choses comme /includes, parce qu'en fait, le web est concerné, ces ressources n'existent pas et doit, par conséquent, 404.

Cela laisse 403 "vous devez être connecté".

En d'autres termes, 403 signifie "cette ressource nécessite une certaine forme d'authentification autre que HTTP basic auth".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Je pense qu'il est important de considérer que, pour un navigateur, 401 lance une boîte de dialogue d'authentification pour l'utilisateur de saisir de nouvelles informations d'identification, tandis que 403 ne le fait pas.Les navigateurs pense que, si un 401 est retourné, puis l'utilisateur doit se ré-authentifier.Donc 401 signifie authentification non valide alors que 403, synonyme d'un manque de permission.

Voici certains cas, en vertu de cette logique où une erreur serait retourné à partir de l'authentification ou de l'autorisation, avec des phrases en caractères gras.

Une ressource nécessite une authentification, mais aucune information d'identification ont été spécifié.

401:Le client doit spécifier les informations d'identification.

Les informations d'identification spécifiées sont dans un format non valide.

400:Ce n'est pas 401 ni 403, que les erreurs de syntaxe doit toujours retourner 400.

Les informations d'identification spécifiées référence à un l'utilisateur qui n'existe pas.

401:Le client doit spécifier des informations d'identification valides.

Le spécifiée les informations d'identification sont non valide mais spécifier un utilisateur valide (ou de ne pas spécifier un utilisateur si un utilisateur spécifié n'est pas nécessaire).

401:Encore une fois, le client doit spécifier des informations d'identification valides.

Le spécifiée les informations d'identification ont expiré.

401:C'est quasiment la même qu'en ayant des informations d'identification non valides en général, de sorte que le client doit spécifier des informations d'identification valides.

Les informations d'identification spécifiées sont tout à fait valable, mais ne pas suffit le particulier ressources, mais il est possible que des informations d'identification avec plus d'autorisation.

403:En spécifiant des informations d'identification valides ne serait pas accorder l'accès à la ressource, comme les informations d'identification actuelles sont déjà valide, mais seulement n'ont pas l'autorisation.

Le particulier ressources est inaccessible indépendamment des informations d'identification.

403:Et ce, indépendamment des pouvoirs, donc en spécifiant des informations d'identification valides ne peut pas aider.

Les informations d'identification spécifiées sont tout à fait valable, mais le particulier client est bloqué en les utilisant.

403:Si le client est bloqué, en spécifiant de nouvelles informations d'identification ne fera rien.

Étant donné les dernières RFC sur la question (7231 et 7235) les cas d'utilisation semble assez clair (italiques ajoutés):

401 est pour non authentifié ("manque d'authentification valide");c'est à dire"Je ne sais pas qui vous êtes, ou je n'ai pas confiance, vous êtes qui vous dites que vous êtes."

401 non autorisé

Le 401 (non autorisé) code d'état indique que la demande n'a pas été appliqué parce qu'il manque d'authentification valide les informations d'identification pour la ressource cible.Le serveur de génération d'une réponse 401 DOIT envoyer -tête WWW-Authenticate champ (Section 4.1) contenant au moins un défi applicable à la ressource cible.

Si la demande d'authentification des informations d'identification, puis l'autoroute 401 la réponse indique que l'autorisation a été refusée pour ceux les informations d'identification.L'agent utilisateur PEUT répéter la demande avec un nouveau ou remplacé Autorisation de champ d'en-tête (Section 4.2).Si le 401 la réponse contient le même défi que l'état de la réponse, et la l'agent utilisateur a déjà tenté l'authentification au moins une fois, alors l'agent utilisateur DEVRAIT présenter le clos de la représentation de la utilisateur car il contient généralement pertinentes pour le diagnostic.

403 est pour non autorisé ("refuse d'autoriser");c'est à dire"Je sais qui vous êtes, mais vous n'avez pas la permission d'accéder à cette ressource.'

403 Forbidden

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

Si les informations d'authentification ont été fournis dans la demande, le serveur les juge insuffisantes pour accorder l'accès.Le client Ne DOIT PAS répéter automatiquement la demande avec la même les informations d'identification.Le client PEUT répéter la demande avec de nouveau ou de différent les informations d'identification.Toutefois, une demande peut être interdit pour des raisons sans rapport avec les informations d'identification.

Un serveur d'origine, qui se veut "cacher" de l'existence actuelle d'un interdit cible de la ressource au lieu de répondre avec un code d'état de 404 (Non Trouvé).

Dans le cas de 401 vs 403, ce qui a été répondu à plusieurs reprises.C'est essentiellement une requête HTTP de l'environnement de débat, pas une 'application' débat.

Il semble y avoir une question sur le rouleau de-votre-propre-problème de connexion (application).

Dans ce cas, il suffit de ne pas être connecté n'est pas suffisante pour envoyer un 401 ou 403, sauf si vous utilisez HTTP Auth vs une page de connexion (non liées à la mise HTTP Auth).On dirait que vous cherchez peut-être un "201 Créé", avec un rouleau de-votre-propre-écran de connexion actuelle (au lieu de la ressource demandée) pour l'application au niveau de l'accès à un fichier.Cela en dit:

"Je vous ai entendu, c'est ici, mais essayez plutôt ceci (vous n'êtes pas autorisés à le voir)"

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow