Что будет, если обратиться через GET-запрос к адресу с ограниченным доступом без авторизации?

«Что будет, если обратиться через GET-запрос к адресу с ограниченным доступом без авторизации?» — вопрос из категории HTTP и веб-протоколы, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Сервер вернет один из стандартных HTTP-статусов, указывающих на проблему с доступом. Как QA-инженер, я проверяю корректность этих ответов при тестировании безопасности и авторизации.

Основные ожидаемые статусы:

  1. 401 Unauthorized

    • Что означает: Клиент не предоставил корректные учетные данные (логин/пароль, токен). Требуется аутентификация.
    • Что проверять в ответе: Заголовок WWW-Authenticate может указывать на схему аутентификации (например, Basic realm="Access to site").
    • Контекст в тестировании API: Это ожидаемый ответ для защищенных эндпоинтов, когда токен отсутствует или просрочен.
  2. 403 Forbidden

    • Что означает: Сервер понял запрос, но отказывается его авторизовать. У клиента могут быть верные учетные данные, но недостаточно прав (ролей).
    • Что проверять: В отличие от 401, повторная аутентификация не поможет. Нужны другие права.
    • Контекст в тестировании: Проверяю разграничение прав (например, пользователь с ролью USER пытается получить доступ к админ-панели).
  3. 404 Not Found

    • Иногда используется для сокрытия существования ресурса в целях безопасности (security through obscurity). Вместо того чтобы сказать "у вас нет доступа", сервер говорит "ресурс не найден".
    • Как тестировать: Если для авторизованного пользователя ресурс существует (возвращает 200), а для неавторизованного — 404, это может быть осознанным решением. Нужно свериться с требованиями.

Пример теста на Python с requests для проверки этого поведения:

import requests

# Эндпоинт, требующий JWT-токен
API_URL = "https://api.example.com/v1/admin/users"

# 1. Запрос БЕЗ токена (ожидаем 401 или 403)
response_no_auth = requests.get(API_URL)
print(f"No auth - Status: {response_no_auth.status_code}")  # Ожидаем: 401
assert response_no_auth.status_code in [401, 403], 
    f"Expected 401/403 for unauthorized access, got {response_no_auth.status_code}"

# 2. Запрос с невалидным/просроченным токеном (тоже ожидаем 401)
headers_bad_token = {"Authorization": "Bearer invalid_token_123"}
response_bad_auth = requests.get(API_URL, headers=headers_bad_token)
print(f"Bad token - Status: {response_bad_auth.status_code}")  # Ожидаем: 401
assert response_bad_auth.status_code == 401

# 3. Запрос с валидным токеном, но недостаточными правами (ожидаем 403)
headers_user_token = {"Authorization": "Bearer valid_user_token"}
response_forbidden = requests.get(API_URL, headers=headers_user_token)
print(f"User token - Status: {response_forbidden.status_code}")  # Ожидаем: 403
if response_forbidden.status_code == 403:
    print("Correctly forbidden for regular user.")

Важно для QA: Проверка этих статусов — часть тестирования безопасности (security testing) и валидации бизнес-логики контроля доступа (access control). Ответы должны быть консистентными и не раскрывать лишней информации (например, в теле ошибки 403 не должно быть деталей внутренней структуры папок).