403 Запрещено против 401 Несанкционированные ответы HTTP - PullRequest
2352 голосов
/ 21 июля 2010

Для веб-страницы, которая существует, но для которой пользователь, который не имеет достаточных привилегий (они не вошли в систему или не принадлежат к соответствующей группе пользователей), какой правильный HTTP-ответ должен обслуживать? 401? 403? Что-то другое? То, что я читал о каждом из них, пока не очень ясно о разнице между ними. Какие варианты использования подходят для каждого ответа?

Ответы [ 14 ]

3500 голосов
/ 04 августа 2011

Четкое объяснение от Даниэль Ирвин :

Существует проблема с 401 Unauthorized , кодом состояния HTTP для ошибок аутентификации. И это только: аутентификация, а не авторизация. При получении ответа 401 сервер говорит вам: «Вы не аутентифицированный - либо не аутентифицированный вообще, либо аутентифицированный неправильно, но, пожалуйста, повторите аутентификацию и попробуйте еще раз ». Чтобы помочь вам, он всегда будет включать заголовок WWW-Authenticate , который описывает, как аутентифицировать.

Этот ответ обычно возвращается вашим веб-сервером, а не вашим веб-сервером. применение.

Это тоже что-то очень временное; сервер просит вас попробовать еще раз.

Итак, для авторизации я использую ответ 403 Forbidden . Это постоянный, это связано с логикой моего приложения, и это более конкретный ответ, чем 401.

При получении ответа 403 сервер говорит вам: «Извините. я знаю кто вы есть - я верю, кто вы говорите, что вы - но у вас просто нет разрешение на доступ к этому ресурсу. Может быть, если вы спросите систему администратор, вы получите разрешение. Но, пожалуйста, не беспокойтесь я снова, пока ваше затруднительное положение не изменится. "

В итоге, ответ 401 Unauthorized должен использоваться как отсутствующий или неверная аутентификация, и следует использовать ответ 403 Forbidden впоследствии, когда пользователь аутентифицирован, но не авторизован выполнить запрошенную операцию с данным ресурсом.

Другой хороший графический формат того, как следует использовать коды статуса http.

enter image description here

366 голосов
/ 21 июля 2010

См. RFC2616 :

401 Несанкционировано:

Если в запрос уже включены учетные данные авторизации, то в ответе 401 указывается, что для авторизации было отклоненоучетные данные.

403 Запрещено:

Сервер понял запрос, но отказывается его выполнить.

Обновить

Из вашего варианта использования видно, что пользователь не аутентифицирован.Я бы вернул 401.


Редактировать: RFC2616 устарел, см. RFC7231 и RFC7235 .

280 голосов
/ 05 февраля 2013

Что-то, чего нет в других ответах, так это то, что следует понимать, что Аутентификация и Авторизация в контексте RFC 2616 относятся ТОЛЬКО к протоколу HTTP-аутентификации RFC 2617. Аутентификация по схемам вне RFC2617 не поддерживается в кодах состояния HTTP ине учитываются при принятии решения об использовании 401 или 403.

Кратко и кратко

Неавторизовано означает, что клиент не аутентифицирован RFC2617, и сервер инициирует процесс аутентификации.Запрещено означает, что клиент прошел проверку подлинности RFC2617 и не имеет авторизации или что сервер не поддерживает RFC2617 для запрошенного ресурса.

Это означает, что у вас есть свой собственный процесс входа в систему по принципу «сворачивание» и вы никогда не используете HTTPАутентификация, 403 - это всегда правильный ответ, и никогда не следует использовать 401.

Подробно и подробно

Из RFC2616

10.4.2 401 Несанкционированный

Запрос требует аутентификации пользователя.Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее запрос, применимый к запрашиваемому ресурсу.Клиент МОЖЕТ повторить запрос с подходящим полем заголовка Авторизация (раздел 14.8).

и

10.4.4 403 Запрещено Сервер понял запрос, но отказывается его выполнить.Авторизация не поможет, и запрос НЕ СЛЕДУЕТ повторять.

Первое, что следует иметь в виду, это то, что «Аутентификация» и «Авторизация» в контексте этого документа относятся именно к протоколам HTTP-аутентификации.из RFC 2617. Они не относятся к каким-либо протоколам проверки подлинности, созданным вами самими, которые вы могли создать, используя страницы входа и т. д. Я буду использовать «вход в систему» ​​для ссылки на проверку подлинности и авторизацию другими способами, кроме RFC2617

Таким образом, реальная разница не в том, в чем проблема, или даже в том, если есть решение.Разница в том, что сервер ожидает, что клиент будет делать дальше.

401 означает, что ресурс не может быть предоставлен, но сервер ЗАПРОСИЛ, чтобы клиент вошел через HTTP-аутентификацию, и отправил заголовки ответа, чтобы инициироватьпроцесс.Возможно, есть авторизации, которые разрешат доступ к ресурсу, возможно, нет, но давайте попробуем и посмотрим, что произойдет.

403 указывает, что ресурс не может быть предоставлен и существует для текущегоПользователь, нет способа решить это через RFC2617 и нет смысла пытаться.Это может быть связано с тем, что известно, что уровень аутентификации недостаточен (например, из-за черного списка IP-адресов), но это может быть связано с тем, что пользователь уже аутентифицирован и не имеет полномочий.Модель RFC2617 является однопользовательской, однопользовательской, поэтому случай, когда у пользователя может быть второй набор учетных данных, которые можно авторизовать, может быть проигнорирован.Это не предполагает и не подразумевает, что какая-либо страница входа в систему или другой протокол аутентификации, отличный от RFC2617, может или не может помочь - это выходит за рамки стандартов и определений RFC2616.


Редактировать: RFC2616 устарел, см. RFC7231 и RFC7235 .

108 голосов
/ 23 февраля 2015
   Resource exists ?
    |       |
 NO |       | YES
    v       v
   404      Is logged-in (authenticated) ?
   or         |              |
   401     NO |              | YES
   403        |              |
              v              v
              401            Can access resource, permissions (authorized) ?
         (404 no reveal)      |            |
             or 301        NO |            | YES
             redirect         |            |
             to login         v            v
                              403          OK 200, 301, ...
                      (or 404: no reveal)

Обычно проверки выполняются в следующем порядке:

  • 401, если не вошел в систему или сеанс истек
  • 403, если у пользователя нет прав доступа к ресурсу (файлу, json, ...)
  • 404, если ресурс не существует (или не желает что-либо раскрывать)

НЕСАНКЦИОНИРОВАН * : код состояния (401), указывающийчто для запроса требуется аутентификация , обычно это означает, что пользователь должен войти в систему (сеанс).Пользователь / агент неизвестен серверу.Можно повторить с другими учетными данными.ПРИМЕЧАНИЕ: это сбивает с толку, поскольку это должно было быть названо «неаутентифицированным» вместо «неавторизованным».Это также может произойти после входа в систему, если сеанс истек.Особый случай: Может использоваться вместо 404, чтобы избежать выявления наличия или отсутствия ресурса (credits @gingerCodeNinja)

FORBIDDEN : код состояния (403), указывающий, что сервер понял запрос, ноотказался выполнить это.Пользователь / агент известен серверу, но имеет недостаточно учетных данных .Повторный запрос не будет работать, если учетные данные не изменены, что очень маловероятно за короткий промежуток времени.Особый случай: Может использоваться вместо 404, чтобы избежать выявления наличия или отсутствия ресурса (credits @gingerCodeNinja)

NOT FOUND : код состояния (404), указывающий, что запрошенный ресурснедоступен.Пользователь / агент известен, но сервер ничего не раскрывает о ресурсе, если он не существует.Повтор не сработает.Это специальное использование 404 (например, github).

108 голосов
/ 21 июля 2010

Согласно RFC 2616 (HTTP / 1.1) 403 отправляется, когда:

Сервер понял запрос, но отказывается его выполнить.Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться.Если метод запроса не был HEAD и сервер желает сообщить, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте.Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404 (Не найдено)

Другими словами, если клиент МОЖЕТ получить доступ к ресурсу саутентификация, 401 должен быть отправлен.

43 голосов
/ 27 февраля 2013

Предполагая HTTP-аутентификацию ( WWW-Authenticate и Авторизация заголовки) используется , если аутентификация другого пользователя предоставит доступк запрошенному ресурсу следует вернуть 401 Unauthorized.

403 Запрещено используется, когда доступ к ресурсу запрещен для всех или ограничен определенной сетью или разрешен только через SSL, независимо от того, что это не так.связанные с HTTP-аутентификацией.

Если HTTP-аутентификация не используется и сервисом является схема аутентификации на основе файлов cookie, которая является нормой в настоящее время, тогда должны быть возвращены 403 или 404.

Относительно 401, это из RFC 7235 (протокол передачи гипертекста (HTTP / 1.1): аутентификация):

3.1.401 Unauthorized

Код состояния 401 (Unauthorized) указывает, что запрос не был применен, поскольку в нем отсутствуют действительные учетные данные аутентификации для целевого ресурса.Исходный сервер ДОЛЖЕН отправить поле заголовка WWW-Authenticate (раздел 4.4), содержащее как минимум один запрос, применимый к целевому ресурсу. Если в запрос включены учетные данные для проверки подлинности, то ответ 401 указывает, что для этих учетных данных было отказано в авторизации .Клиент МОЖЕТ повторить запрос с новым или замененным полем заголовка Авторизация (Раздел 4.1).Если ответ 401 содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже попытался выполнить аутентификацию хотя бы один раз, то пользовательский агент ДОЛЖЕН представить приложенное представление пользователю, поскольку он обычно содержит соответствующую диагностическую информацию.

Семантика 403 (и 404) со временем изменилась.Это из 1999 (RFC 2616):

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается его выполнить.
Авторизация будетне помогает и запрос НЕ СЛЕДУЕТ повторять.
Если метод запроса не был HEAD и сервер желает сделать
открытым, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа влицо.Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404
(не найден).

В 2014 RFC 7231 (протокол передачи гипертекста (HTTP)/1.1): семантика и содержание) изменил значение 403:

6.5.3.403 Запрещено

Код состояния 403 (Запрещено) указывает, что сервер понял запрос, но отказывается его авторизовать.Сервер, который желает сообщить общественности, почему запрос был запрещен, может описать эту причину в полезной нагрузке ответа (если есть).

Если в запросе были предоставлены учетные данные для проверки подлинности, сервер
считаетих недостаточно, чтобы предоставить доступ.Клиент
НЕ ДОЛЖЕН автоматически повторять запрос с теми же учетными данными
.Клиент МОЖЕТ повторить запрос с новыми или другими учетными данными.Однако запрос может быть запрещен по причинам
, не связанным с учетными данными.

Исходный сервер, который хочет «скрыть» текущее существование запрещенного целевого ресурса
, МОЖЕТ вместо этого ответитькод состояния
404 (не найден).

Таким образом, 403 (или 404) теперь может означать что угодно.Предоставление новых учетных данных может помочь ... или может не помочь.

Я полагаю, что причина, по которой это изменилось, заключается в том, что RFC 2616 предполагал, что аутентификация HTTP будет использоваться, когда на практике современные веб-приложения создают собственные схемы аутентификации с использованием, например, форм.и печенье.

26 голосов
/ 25 декабря 2014

Это старый вопрос, но один вариант, который так и не был поднят, заключался в возврате 404. С точки зрения безопасности ответ с наибольшим количеством голосов страдает от потенциальной уязвимости утечки информации . Скажем, например, что рассматриваемая защищенная веб-страница является страницей системного администратора или, что более часто, является записью в системе, к которой у пользователя нет доступа. В идеале вы бы не хотели, чтобы злоумышленник даже знал, что там есть страница / запись, не говоря уже о том, что у него нет доступа. Когда я создаю что-то вроде этого, я пытаюсь записывать неавторизованные / неавторизованные запросы во внутренний журнал, но возвращаю 404.

OWASP содержит дополнительную информацию о том, как злоумышленник может использовать этот тип информации в качестве части атаки.

21 голосов
/ 22 мая 2014

Этот вопрос был задан некоторое время назад, но мышление людей движется дальше.

Раздел 6.5.3 в этом черновике (автор Fielding and Reschke) дает код состояния 403 немного другойзначение, описанное в RFC 2616 .

Отражает то, что происходит в схемах аутентификации и авторизации, используемых рядом популярных веб-серверов и сред.

I 'Я подчеркнул бит, который я считаю наиболее заметным.

6.5.3.403 Запрещено

Код состояния 403 (Запрещено) указывает, что сервер понял запрос, но отказывается его авторизовать.Сервер, который желает сообщить общественности, почему запрос был запрещен, может описать эту причину в полезной нагрузке ответа (если есть).

Если в запросе были предоставлены учетные данные для проверки подлинности, сервер считает их недостаточными для предоставления доступа. Клиент НЕ ДОЛЖЕН повторять запрос с теми же учетными данными.Клиент МОЖЕТ повторить запрос с новыми или другими учетными данными. Однако запрос может быть запрещен по причинам, не связанным с учетными данными.

Исходный сервер, который хочет «скрыть» текущее существование запрещенного целевого ресурса, МОЖЕТ вместо этого ответить кодом состояния 404 (Не найдено).

Какое бы соглашение вы не использоваливажно обеспечить единообразие для всего сайта / API.

11 голосов
/ 25 февраля 2015

TL; DR

  • 401: отказ, связанный с аутентификацией
  • 403: отказ, не имеющий отношения к аутентификации

Практические примеры

Если apache требует аутентификации (через .htaccess), и вы нажмете Cancel, он ответит 401 Authorization Required

Если nginx находит файл, но не имеет прав доступа (пользователь / группа) для чтения / доступа к нему, он ответит 403 Forbidden

RFC (2616 Раздел 10)

401 Несанкционированный (10.4.2)

Значение 1: Необходимо подтвердить подлинность

Запрос требует аутентификации пользователя. ...

Значение 2: Аутентификация недостаточна

... Если в запрос уже включены учетные данные авторизации, то в ответе 401 указывается, что для этих учетных данных было отказано в авторизации. ...

403 Запрещено (10.4.4)

Значение: Не имеет отношения к аутентификации

... Авторизация не поможет ...

Подробнее:

  • Сервер понял запрос, но отказывается его выполнить.

  • СЛЕДУЕТ описать причину отказа в организации

  • Вместо этого можно использовать код состояния 404 (не найден)

    (если сервер хочет сохранить эту информацию от клиента)

9 голосов
/ 01 октября 2012

они не авторизованы или не принадлежат к соответствующей группе пользователей

Вы указали два разных случая; у каждого случая должен быть свой ответ:

  1. Если они вообще не вошли в систему, вы должны вернуть 401 Unauthorized
  2. Если они вошли в систему, но не принадлежат к соответствующей группе пользователей, вы должны вернуть 403 Запрещено

Примечание к RFC на основе комментариев, полученных к этому ответу:

Если пользователь не вошел в систему, он не прошел проверку подлинности, HTTP-эквивалент которого равен 401 и вводит в заблуждение «Не авторизован в RFC». Как указано в разделе 10.4.2 для 401 Несанкционированный :

"Запрос требует пользователя аутентификация ."

Если вы не прошли проверку подлинности, 401 - правильный ответ. Однако, если вы не авторизованы, в семантически правильном смысле 403 является правильным ответом.

...