403 Interdit vs 401 Réponses HTTP non autorisées
Pour une page Web existante, mais pour laquelle un utilisateur ne disposant pas de privilèges suffisants (ils ne sont pas connectés ou n'appartient pas au groupe d'utilisateurs approprié), quelle est la réponse HTTP appropriée à servir? 401? 403? Autre chose? Ce que j'ai lu sur chacune d'elles 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?
Une explication claire de Daniel Irvine :
Il y a un problème avec 401 Unauthorized , le code d'état HTTP pour les erreurs d'authentification. Et c’est ça: c’est pour l’authentification, pas pour l’autorisation. En recevant une réponse 401, le serveur vous dit: "Vous n'êtes pas authentifié - du moins ou pas du tout - mais veuillez vous réauthentifier et réessayer." Pour vous aider, il sera toujours inclus un WWW-Authenticate en-tête décrivant comment s’authentifier.
Cette réponse est généralement renvoyée par votre serveur Web, pas par votre application Web.
C’est aussi quelque chose de très temporaire; le serveur vous demande de réessayer.
Donc, pour l'autorisation, j'utilise la réponse 403 Forbidden . C’est permanent, lié à la logique de mon application, et c’est une réponse plus concrète qu’un 401.
En recevant une réponse 403, le serveur vous dit: "Je suis désolé. Je sais qui vous êtes - je crois qui vous dites que vous êtes - mais vous n’avez simplement pas la permission d’accéder à cette ressource. Peut-être que si vous demandez gentiment à l'administrateur système, vous obtiendrez une permission. Mais s'il vous plaît, ne me dérangez plus jusqu'à ce que votre situation change. "
En résumé, une réponse 401 non autorisée doit être utilisée pour une authentification manquante ou incorrecte, et une réponse 403 interdite devrait être utilisé après, lorsque l'utilisateur est authentifié mais n'est pas autorisé à effectuer l'opération demandée sur la ressource donnée.
Un autre format graphique Nice de la manière dont les codes de statut http doivent être utilisés.
Voir RFC2616 :
401 non autorisé:
Si la demande contient 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 demande, mais refuse de l'exécuter.
Mettre à jour
D'après votre cas d'utilisation, il semble que l'utilisateur ne soit pas authentifié. Je reviendrais 401.
Il manque quelque chose aux autres réponses: il faut comprendre que l'authentification et l'autorisation dans le contexte de la RFC 2616 se référent UNIQUEMENT au protocole d'authentification HTTP de la RFC 2617. L'authentification par des schémas en dehors de la RFC2617 n'est pas prise en charge dans les codes d'état HTTP et n'est pas prise en compte. pour décider d'utiliser 401 ou 403.
Bref et laconique
Unauthorized indique que le client n'est pas authentifié par la RFC2617 et que le serveur est en train de lancer le processus d'authentification. Interdit indique que le client est authentifié par RFC2617 et qu'il ne dispose 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 à rouler vous-même et que vous n'utilisez jamais l'authentification HTTP, 403 est toujours la réponse appropriée et 401 ne doit jamais être utilisé.
Détaillé et détaillé
À partir de RFC2616
10.4.2 401 non autorisé
La demande nécessite une authentification de l'utilisateur. La réponse DOIT inclure un champ d'en-tête WWW-Authenticate (paragraphe 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 d'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 font spécifiquement référence aux protocoles d'authentification HTTP de RFC 2617. Ils ne font pas référence aux protocoles d'authentification personnalisables que vous avez éventuellement créés. Utilisation des pages de connexion, etc. J'utiliserai "login" pour faire référence à l'authentification et à l'autorisation par des méthodes autres que RFC2617
La vraie différence n'est donc pas le problème ou même s'il existe une solution. La différence est ce que le serveur attend du client ensuite.
401 indique que la ressource ne peut pas être fournie, mais le serveur DEMANDE que le client se connecte via une authentification HTTP et ait envoyé des en-têtes de réponse pour lancer le processus. Il se peut que certaines autorisations permettent d'accéder à la ressource, mais il n'y en a peut-être pas, mais essayons et voyons ce qui se passe.
403 indique que la ressource ne peut pas être fournie et qu'il n'existe, pour l'utilisateur actuel, aucun moyen de résoudre ce problème via la RFC2617 et qu'il ne sert à rien d'essayer. 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 peut-être du fait que l’utilisateur est déjà authentifié et n’a pas l’autorité voulue. Le modèle RFC2617 étant un utilisateur, des informations d'identification, le cas où l'utilisateur peut disposer d'un second jeu d'informations d'identification pouvant être autorisé peut être ignoré. Cela ne suggère ni n'implique qu'une sorte de page de connexion ou autre protocole d'authentification non conforme à la norme RFC2617 puisse être utile ou non, ce qui n'est pas conforme aux normes et à la définition de la RFC2616.
La ressource existe? | | NO | | OUI V v 404 Est-il connecté (authentifié)? Ou | | 401 NO | | OUI 403 | | v v 401 Peut-il accéder aux ressources, autorisations (autorisées)? (404 pas de révélation) | | ou 301 NO | | OUI Redirect | | pour vous connecter v v 403 OK 200, 301, ... (ou 404: pas de révélation)
Les contrôles sont généralement effectués dans cet ordre:
- 401 si non connecté ou session expirée
- 403 si l'utilisateur n'a pas la permission d'accéder à la ressource (fichier, json, ...)
- 404 si la ressource n'existe pas (ou ne veut rien révéler)
NON AUTORISÉ: Code d'état (401) indiquant que la demande nécessite authentification, cela signifie généralement que l'utilisateur doit être connecté (session). 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é'. Cela peut également se produire après la connexion si la session a expiré. Cas particulier: Peut être utilisé à la place de 404 pour éviter de révéler la présence ou la non-présence d'une ressource (credits @gingerCodeNinja)
INTERDIT: Code d'état (403) indiquant que le serveur a compris la requête mais a refusé de l'exécuter. Utilisateur/agent connu du serveur mais ayant informations d'identification insuffisantes. La répétition d'une demande ne fonctionnera pas, à moins que les informations d'identification ne soient modifiées, ce qui est très peu probable dans un court laps de temps. Cas particulier: Peut être utilisé à la place de 404 pour éviter de révéler la présence ou la non-présence d'une ressource (credits @gingerCodeNinja)
NOT FOUND: 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, comme si elle n'existait pas. Répéter ne fonctionnera pas. Ceci est une utilisation spéciale de 404 (github le fait par exemple).
Selon RFC 2616 (HTTP/1.1) 403 est envoyé lorsque:
Le serveur a compris la demande, 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 la demande n'était pas HEAD et que le serveur souhaite rendre publique la raison pour laquelle la demande n'a pas été remplie, il DEVRAIT décrire le motif du refus dans l'entité. Si le serveur ne souhaite pas mettre cette information à la disposition du client, le code d'état 404 (Introuvable) 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é.
en supposant que l'authentification HTTP ( WWW-Authenticate et Authorization en-têtes) est en cours d'utilisation, si s'authentifier comme un autre utilisateur accorderait l'accès à la ressource demandée, 401 Unauthorized devrait alors être renvoyé.
403 Forbidden est utilisé lorsque l'accès à la ressource est interdit à tout le monde, limité à un réseau donné ou autorisé uniquement via SSL, quelle que soit la condition que celle-ci ne soit pas liée à l'authentification HTTP.
Si l'authentification HTTP n'est pas utilisée et que le service utilise un schéma d'authentification basé sur les cookies, comme c'est la norme de nos jours, un 403 ou un 404 devrait être renvoyé.
En ce qui concerne 401, il s'agit de RFC 7235 (protocole de transfert d'hypertexte (HTTP/1.1): authentification):
3.1. 401 non autorisé
Le code d'état 401 (non autorisé) indique que la demande n'a pas été appliquée car elle ne dispose pas d'informations d'authentification valides pour la ressource cible. Le serveur d'origine DOIT envoyer un champ d'en-tête WWW-Authenticate (paragraphe 4.4) contenant au moins un défi applicable à la ressource cible. Si la demande comprenait des informations d'identification d'authentification, la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification. Le client PEUT répéter la demande avec un champ d'en-tête d'autorisation nouveau ou remplacé (chapitre 4.1). Si la réponse 401 contient le même défi que la réponse précédente et que l'agent utilisateur a déjà tenté l'authentification au moins une fois, il DEVRAIT alors présenter la représentation jointe à l'utilisateur, car il contient généralement les informations de diagnostic pertinentes.
La sémantique de 403 (et 404) a changé au fil du temps. C'est à partir de 1999 (RFC 2616):
10.4.4 403 interdit
Le serveur a compris la demande, mais refuse de l'exécuter.
L'autorisation ne vous aidera pas et la demande NE DEVRAIT PAS être répétée.
Si la méthode de la requête n'était pas HEAD et que le serveur souhaite effectuer
public pourquoi la demande n'a pas été satisfaite, il DEVRAIT décrire le motif du refus dans l'entité. Si le serveur ne souhaite pas mettre cette information à la disposition du client, le code d'état 404
(Introuvable) peut être utilisé à la place.
En 2014, la RFC 7231 (protocole de transfert hypertexte (HTTP/1.1): sémantique et contenu) a modifié la signification de la 403:
6.5.3. 403 interdit
Le code d’état 403 (interdit) indique que le serveur a compris la demande mais refuse de l’autoriser. Un serveur qui souhaite rendre public la raison pour laquelle la demande a été interdite peut décrire cette raison dans la charge utile de la réponse (le cas échéant).
Si des informations d’authentification ont été fournies dans la demande, 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
identifiants. Le client PEUT répéter la demande avec des informations d'identification nouvelles ou différentes. Cependant, une demande peut être interdite pour des raisons
sans lien avec les informations d'identification.Un serveur Origin qui souhaite "masquer" l'existence actuelle d'un
ressource cible interdite PEUT au lieu de cela répondre avec un code d'état de
404 (non trouvé).
Ainsi, un 403 (ou un 404) pourrait maintenant signifier n'importe quoi. Fournir de nouvelles informations d'identification peut aider… ou pas.
Je crois que la raison pour laquelle cela a changé est que RFC 2616 supposait que l'authentification HTTP serait utilisée lorsque, dans la pratique, les applications Web actuelles créent des schémas d'authentification personnalisés à l'aide, par exemple, de formulaires et de cookies.
C'est une question plus ancienne, mais une option qui n'avait jamais été évoquée était de renvoyer un 404. Du point de vue de la sécurité, la réponse la plus votée souffre d'un potentiel vulnérabilité de fuite d'informations . Supposons, par exemple, que la page Web sécurisée en question soit une page d’administrateur système, ou peut-être plus communément, un enregistrement d’un système auquel l’utilisateur n’a pas accès. Idéalement, vous ne voudriez pas qu'un utilisateur malveillant sache même qu'il y a une page/un enregistrement là-bas, encore moins qu'il n'a pas d'accès. Lorsque je construis quelque chose comme cela, je vais essayer d'enregistrer les demandes non authentifiées/non autorisées dans un journal interne, mais je renverrai un 404.
OWASP contient des plus d'informations expliquant comment un attaquant pourrait utiliser ce type d'informations dans le cadre d'une attaque.
Cette question a été posée il y a quelque temps, mais la pensée des gens évolue.
Section 6.5. dans ce brouillon (rédigé par Fielding et Reschke) donne au code d'état 403 une signification légèrement différente de celle documentée dans RFC 2616 .
Il reflète ce qui se passe dans les schémas d'authentification et d'autorisation utilisés par un certain nombre de serveurs Web et de frameworks populaires.
J'ai mis l'accent sur le point qui me semble le plus important.
6.5.3. 403 Interdit
Le code d’état 403 (interdit) indique que le serveur a compris la demande mais refuse de l’autoriser. Un serveur qui souhaite rendre public la raison pour laquelle la demande a été interdite peut décrire cette raison dans la charge utile de la réponse (le cas échéant).
Si des informations d'authentification ont été fournies dans la demande, le serveur les considère 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 demande peut être interdite pour des raisons autres que les informations d'identification.
Un serveur Origin qui souhaite "masquer" l'existence actuelle d'une ressource cible interdite PEUT au lieu de cela répondre 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.
TL; DR
- 401: un refus lié à l'authentification
- 403: un refus qui n'a rien à voir avec l'authentification
Exemples pratiques
Si Apache requiert une authentification (via .htaccess), et que vous frappez Cancel, il répondra avec un 401 Authorization Required
Si nginx trouve un fichier mais n’a pas de droits d’accès (utilisateur/groupe) à 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 demande nécessite une 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)
Signification: Sans lien avec l'authentification
... L'autorisation n'aidera pas ...
Plus de détails:
Le serveur a compris la demande, 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 garder cette information du client)
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 doit avoir une réponse différente:
- Si elles ne sont pas du tout connectées, vous devez retourner 401 non autorisé
- S'ils sont connectés mais n'appartiennent pas au groupe d'utilisateurs approprié, vous devez renvoyer 403 Forbidden
Note sur la RFC en fonction des commentaires reçus sur cette réponse:
Si l'utilisateur n'est pas connecté, il n'est pas authentifié, son équivalent HTTP est 401 et est appelé à tort Unauthorized dans la RFC. Comme section 10.4.2 déclare pour 401 non autorisé :
"La requête nécessite une authentification utilisateur ."
Si vous n'êtes pas authentifié, 401 est la réponse correcte. Cependant, si vous n'êtes pas autorisé, au sens sémantiquement correct, 403 est la réponse correcte.
C'est plus simple dans ma tête que partout ailleurs, alors:
401: Vous avez besoin de l'authentification de base HTTP pour voir cela.
403: Vous ne pouvez pas voir cela, et l'authentification de base HTTP ne vous aidera pas.
Si l'utilisateur doit simplement se connecter à l'aide du formulaire de connexion HTML standard de votre site, 401 ne serait pas approprié car il est spécifique à l'authentification de base HTTP.
Je ne recommande pas d'utiliser 403 pour refuser l'accès à des éléments tels que /includes, car, en ce qui concerne le Web, ces ressources n'existent pas du tout et devraient donc 404.
Cela laisse 403 comme "vous devez être connecté".
En d'autres termes, 403 signifie "cette ressource nécessite une forme d'authentification autre que l'authentification de base HTTP".
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 initie une boîte de dialogue d'authentification pour que l'utilisateur entre de nouvelles informations d'identification, alors que 403 ne le fait pas. Les navigateurs pensent que, si un 401 est renvoyé, l'utilisateur doit s'authentifier à nouveau. Ainsi, 401 correspond à une authentification invalide, tandis que 403 correspond à un manque d'autorisation.
Voici quelques cas dans cette logique où une erreur serait renvoyée par une authentification ou une autorisation, avec des phrases importantes en gras.
- Une ressource nécessite une authentification, mais pas d'informations d'identification était 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.
4: Ce n'est ni 401 ni 403, car les erreurs de syntaxe devraient toujours renvoyer 400.
- Les informations d'identification spécifiées font référence à tilisateur qui n'existe pas.
401: le client doit spécifier des informations d'identification valides.
- Les informations d'identification spécifiées sont invalid mais spécifient un utilisateur valide (ou ne spécifiez pas d'utilisateur si un utilisateur spécifié n'est pas requis).
401: Encore une fois, le client doit spécifier des informations d'identification valides.
- Les informations d'identification spécifiées ont expiré.
401: C'est pratiquement la même chose que d'avoir des informations d'identification non valides en général. Le client doit donc spécifier des informations d'identification valides.
- Les informations d'identification spécifiées sont complètement valides mais ne sont pas suffisantes les ressources, bien qu'il soit possible que des informations d'identification disposant de plus d'autorisations le puissent.
4: La spécification d'informations d'identification valides ne donnerait pas accès à la ressource, car les informations d'identification actuelles sont déjà valides mais ne sont pas autorisées.
- Le particulier ressource est inaccessible quels que soient les identifiants.
4: Ceci est indépendant des informations d'identification. Par conséquent, spécifier des informations d'identification valides ne peut pas vous aider.
- Les informations d'identification spécifiées sont complètement valides, mais le client est bloqué de les utiliser.
4: Si le client est bloqué, la spécification de nouveaux identifiants ne fera rien.
401: Je ne sais pas qui vous êtes. C'est une erreur d'authentification. 4: Je sais qui vous êtes. Mais vous n'avez pas la permission d'accéder à cette ressource. Ceci est une erreur d'autorisation.
Compte tenu des derniers RFC sur le sujet ( 7231 et 7235 ), le cas d'utilisation semble assez clair (italiques ajoutés):
- 401 est pour non authentifié ("manque d'authentification valide"); "Je ne sais pas qui vous êtes, ou je ne crois pas que vous êtes qui vous dites que vous êtes."
401 non autorisé
Le code d'état 401 (non autorisé) indique que la demande n'a pas été appliquée car il ne dispose pas d'informations d'authentification valides pour la ressource cible. Le serveur qui génère une réponse 401 DOIT envoyer un champ d'en-tête WWW-Authenticate (paragraphe 4.1) contenant au moins un défi applicable à la ressource cible.
Si la demande comprenait des informations d'identification d'authentification, la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification. L'agent d'utilisateur PEUT répéter la demande avec un champ d'en-tête d'autorisation nouveau ou remplacé (section 4.2). Si la réponse 401 contient le même défi que la réponse précédente et que l'agent utilisateur a déjà tenté l'authentification au moins une fois, il DEVRAIT alors présenter la représentation jointe à l'utilisateur, car il contient généralement les informations de diagnostic pertinentes.
- 403 est pour non autorisé ("refuse d'autoriser"); "Je sais qui vous êtes, mais vous n'avez pas la permission d'accéder à cette ressource."
403 Interdit
Le code d'état 403 (interdit) indique que le serveur a compris la demande mais refuse de l'autoriser . Un serveur qui souhaite rendre public la raison pour laquelle la demande a été interdite peut décrire cette raison dans la charge utile de la réponse (le cas échéant).
Si des informations d'authentification ont été fournies dans la demande, le serveur les considère insuffisantes pour accorder l'accès. Le client NE DEVRAIT PAS répéter automatiquement 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. Toutefois, une demande peut être interdite pour des raisons autres que les informations d'identification.
Un serveur Origin qui souhaite "masquer" l'existence actuelle d'une ressource cible interdite PEUT au lieu de cela répondre avec un code d'état de 404 (non trouvé).