PrepBro
← Назад к вопросам

Что такое ошибка 401?

1.0 Junior🔥 121 комментариев
#Тестирование API

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Ошибка 401 Unauthorized: Подробное объяснение для QA Engineer

Ошибка 401 Unauthorized — это код состояния протокола HTTP, который сервер возвращает клиенту (например, браузеру или мобильному приложению), когда запрос к защищенному ресурсу не содержит допустимых учетных данных для аутентификации или когда предоставленные учетные данные неверны.

Ключевая терминология и отличие от 403

  • Unauthorized (Неавторизован): Термин здесь немного вводит в заблуждение. На самом деле, он означает "Не аутентифицирован". Сервер говорит: "Я не знаю, кто вы. Представьтесь, пожалуйста".
  • В отличие от 403 Forbidden: Ошибка 403 означает: "Я знаю, кто вы (аутентификация прошла успешно), но у вас нет прав (авторизации) для доступа к этому ресурсу". 401 — это проблема с логином/паролем/токеном, а 403 — проблема с разрешениями.

Механизм работы и заголовок WWW-Authenticate

При ответе с кодом 401 сервер должен отправить заголовок WWW-Authenticate, который сообщает клиенту, какой механизм аутентификации требуется использовать для доступа к запрашиваемому ресурсу.

Пример ответа сервера:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"
Content-Type: text/html
Content-Length: 123

<html>... (тело с сообщением об ошибке, например, "Требуется авторизация")</html>

В этом примере сервер запрашивает аутентификацию по схеме Basic Auth.

Основные схемы аутентификации, связанные с 401

  1. Basic Authentication: Самый простой метод. Логин и пароль объединяются в строку login:password, кодируются в Base64 и отправляются в заголовке Authorization. 
    Authorization: Basic bG9naW46cGFzc3dvcmQ=

    *Тестирование для QA:* Проверьте передачу неверных данных, пустых полей, спецсимволов в логине/пароле.
  1. Bearer Authentication (Token-based): Наиболее распространена в современных REST API. Клиент получает токен (часто JWT) после успешного входа и использует его в заголовках. 
    Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

    *Тестирование для QA:* Проверьте поведение при просроченном токене, некорректном формате токена, отсутствии заголовка.
  1. Digest Authentication: Более безопасная, чем Basic, использует хэширование с nonce для предотвращения перехвата пароля. Встречается реже.

Сценарии возникновения ошибки 401 с точки зрения тестирования

С точки зрения QA Engineer, ошибка 401 может возникать в следующих ключевых сценариях, которые необходимо покрыть тестами:

  • Позитивные и негативные сценарии аутентификации:
    *   Запрос **без заголовка `Authorization`** к защищенному эндпоинту.
    *   Запрос с **неверным логином/паролем** в Basic Auth.
    *   Запрос с **просроченным, отозванным или недействительным JWT-токеном**.
    *   Запрос с токеном, у которого **истекло время жизни (expired)**.
    *   Использование токена, выданного для **другого окружения** (например, токен production на staging-сервере).
    *   **Неверный формат заголовка** (например, `BearerToken` вместо `Bearer Token`).
  • Сценарии безопасности:
    *   Попытка **повторного использования одноразовых учетных данных** (если такие предусмотрены).
    *   Проверка устойчивости к **SQL-инъекциям** или другим атакам в полях аутентификации (особенно в формах логина, предшествующих получению токена).
    *   Анализ **информативности сообщения об ошибке**. Тело ответа на 401 НЕ должно раскрывать детали (например, "неверный пароль" vs "неверные учетные данные"), чтобы не помогать злоумышленнику в подборе.
  • Сценарии взаимодействия с фронтендом:
    *   Как приложение **обрабатывает и отображает** ошибку 401 пользователю? (Обычно — перенаправление на страницу входа или модальное окно).
    *   Проверка **логики автоматического обновления токена** (refresh token flow) при получении 401. После обновления токена первоначальный запрос должен быть повторен автоматически.
    *   **Поведение при множественных параллельных запросах**, когда один из них возвращает 401.

Практические шаги для QA при тестировании

  1. Используйте инструменты: Postman, SoapUI, curl для прямых запросов к API.

    # Пример запроса без аутентификации
curl -v https://api.example.com/secure/data
# Ответ будет содержать строку "HTTP/1.1 401 Unauthorized"

  2. Проверяйте корректность заголовка WWW-Authenticate (если применимо) в ответе.

  3. Автоматизируйте проверки: Напишите API-тесты, которые целенаправленно проверяют негативные сценарии аутентификации.

    # Пример на Python с использованием pytest и requests
import requests

def test_access_without_token():
    """Попытка доступа к защищенному ресурсу без токена."""
    response = requests.get('https://api.example.com/secure/data')
    assert response.status_code == 401
    assert 'WWW-Authenticate' in response.headers

  4. Интегрируйте в CI/CD: Добавьте такие негативные тесты в пайплайн непрерывной интеграции, чтобы предотвратить регрессию в механизме аутентификации.

Вывод для QA: Ошибка 401 Unauthorized — это не баг, а ожидаемое поведение системы безопасности. Задача тестировщика — убедиться, что эта ошибка корректно возвращается во всех предусмотренных сценариях отсутствия или невалидности учетных данных, что механизмы обработки этой ошибки на клиенте работают (например, редирект на логин), и что она не возникает там, где доступ должен быть предоставлен (позитивные сценарии с валидными данными).