Ошибка 403 Forbidden: почему доступ запрещён

HTTP 403 Forbidden означает, что сервер понял запрос, но отказывается его выполнять. Это принципиально отличается от 401: при 403 проблема не обязана решаться простым повтором того же запроса с теми же credentials.

RFC 9110 прямо допускает разные причины запрета. Если credentials были переданы, сервер может считать их недостаточными. Но 403 способен возникать и вообще без связи с пользовательской ролью: из-за IP allowlist, WAF-правила, запрета directory listing, web-server ACL или политики приложения.

Что означает HTTP 403

Упрощённо:

запрос понятен
      ↓
сервер знает ресурс/правило
      ↓
политика запрещает выполнение
      ↓
403 Forbidden

Главная задача диагностики — найти уровень политики, который принял решение о запрете.

403 и 401 — в чём разница

Если token валиден, но у пользователя нет роли admin, API часто возвращает 403. Если token отсутствует или не принят — 401.

При этом RFC допускает, что сервер вместо 403 может вернуть 404, если хочет скрыть существование запрещённого ресурса.

Где может возникнуть 403

клиент
  ↓
CDN / WAF       ← geo/IP/bot/rate/security policy
  ↓
reverse proxy   ← allow/deny, auth middleware
  ↓
web-server      ← filesystem / directory rules
  ↓
приложение      ← roles / permissions / business policy

Одинаковый код не говорит, какой именно слой заблокировал запрос.

Шаг 1. Зафиксируйте точный запрос

curl -i https://example.com/protected

Смотрите:

• HTTP status;
• Server;
• CDN/WAF headers;
• request ID;
• body;
• Set-Cookie/redirect history при необходимости.

Для API добавьте тот же method, headers и auth, которые использует реальный клиент.

Основные причины 403

Недостаточно прав в приложении

Пользователь успешно аутентифицирован, но authorization policy запрещает действие.

Например:

viewer → GET /reports      → 200
viewer → DELETE /reports/1 → 403
admin  → DELETE /reports/1 → 204

Проверяйте mapping ролей, scopes, tenant membership и конкретное permission rule.

IP allowlist или denylist

Доступ может быть разрешён только корпоративной сети, VPN или конкретным адресам.

Если из одной сети 200, а из другой 403, сравните внешний IP и правила доступа. Учитывайте proxy chain: приложение может видеть адрес proxy, а реальный client IP получать из доверенного forwarding header.

WAF или CDN блокирует запрос

Защитный слой может запрещать:

• определённый path;
• query pattern;
• HTTP method;
• user agent;
• страну/регион;
• IP/reputation;
• сигнатуру запроса.

Если origin напрямую отвечает 200, а публичный URL через CDN — 403, приоритет диагностики смещается к edge policy.

Правила Nginx allow/deny

В конфигурации могут существовать ограничения доступа для location. Не меняйте их вслепую: запрет может защищать admin endpoint или внутренний файл.

Проверяйте активную конфигурацию и конкретный location, который обработал запрос.

Права файловой системы

Для статических файлов web-server должен иметь возможность пройти по каталогам и прочитать нужный файл. Но «поставить 777» — плохая диагностика и плохая эксплуатационная практика.

Сначала определите пользователя процесса и фактические права на путь.

Запрос каталога без разрешённого index/listing

В некоторых web-server конфигурациях запрос directory path может завершиться 403, если нет index-файла, а directory listing отключён. Это не означает, что каталог нужно открывать: возможно, правильное решение — настроить маршрут или index.

Ошибка в приложении после изменения ролей

После релиза могли измениться:

• permission matrix;
• scopes;
• tenant checks;
• middleware order;
• default-deny policy;
• feature flag.

Если массовые 403 начались сразу после deployment, сопоставление по времени критично.

Шаг 2. Определите масштаб

Проверьте несколько URL:

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/account
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/admin

Если запрещён только /admin, вероятна локальная policy. Если 403 получает весь сайт, ищите общие WAF/CDN/proxy правила или глобальную конфигурацию.

Шаг 3. Сравните пользователя и роль

Для application-level 403 сравните:

• user ID;
• tenant/workspace;
• role;
• scopes;
• resource ownership;
• действие;
• policy decision.

Не логируйте пароль или полный access token.

Полезен структурированный audit/security log вроде:

request_id=...
user_id=...
action=delete_report
resource_id=...
decision=deny
reason=missing_permission

Конкретный формат зависит от приложения.

Шаг 4. Проверьте CDN/WAF против origin

Если инфраструктура позволяет безопасно обратиться к origin с правильным Host/SNI, сравните результаты. Не открывайте внутренний origin публично только ради теста.

Логика:

public URL → 403
origin     → 200

указывает на edge/proxy слой.

Если оба возвращают 403, запрет может находиться глубже.

Шаг 5. Проверьте web-server logs

Для Nginx:

sudo tail -n 200 /var/log/nginx/access.log
sudo tail -n 200 /var/log/nginx/error.log

Ищите exact timestamp и request ID. Причины 403 в error log зависят от конкретной конфигурации — filesystem permission и access forbidden by rule требуют разных исправлений.

Шаг 6. Не маскируйте причину изменением кода на 200

Иногда проблему «исправляют», заставляя endpoint всегда возвращать 200 и сообщение об отказе в body. Это ломает машинную семантику и мониторинг.

Если действие запрещено, корректный 4xx полезнее скрытого отказа в успешном HTTP-ответе.

403 в REST API

Пример:

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "forbidden"
}

Ответ не должен раскрывать чувствительную внутреннюю информацию о ролях и ресурсах. Но для собственных логов желательно иметь более точную server-side причину.

Связанный материал: ошибка 401 Unauthorized.

Почему 403 бывает только у мониторинга или бота

WAF может отдельно оценивать user agent, частоту запросов, IP или отсутствие browser-like поведения. Если реальный пользователь получает 200, а автоматическая проверка — 403:

1. сравните IP;
2. проверьте WAF events;
3. сравните method/headers;
4. убедитесь, что монитор не обращается к закрытому URL;
5. не обходите защиту глобальным отключением WAF.

Лучше создать узкое и документированное правило для легитимного технического трафика, если оно действительно необходимо.

Как проверить восстановление

После изменения policy проверяйте как разрешённый, так и запрещённый сценарий:

разрешённый пользователь → ожидаемый 200/204
запрещённый пользователь → ожидаемый 403

Если после «исправления» оба пользователя получают 200, возможно, вы случайно сняли ограничение целиком.

Автоматический контроль критичных URL

Для публичного URL, который должен быть доступен без аутентификации, неожиданный 403 — реальный внешний сбой. UpWatch можно использовать для регулярной проверки ожидаемого HTTP-ответа такого URL.

Для закрытых endpoint важно отдельно управлять техническими credentials и разрешениями проверки.

Типичные ошибки

Сразу ставить chmod 777

Это может создать уязвимость и не исправить WAF/application policy.

Отключать WAF целиком

Так вы убираете защитный слой вместо локализации конкретного правила.

Путать 401 и 403

Это ведёт диагностику в неправильную сторону.

Проверять только одного пользователя

Ошибка может зависеть от роли, tenant или ownership.

Возвращать 404/200 без понимания причины

Коды могут использоваться осознанно, но не должны служить косметическим скрытием дефекта.

Практический чек-лист

1. Подтвердить настоящий 403.
2. Зафиксировать URL, method, user context и время.
3. Определить, один URL или весь сервис.
4. Сравнить пользователей/роли.
5. Определить слой: CDN/WAF, proxy, web-server, приложение.
6. Проверить access/error/security logs.
7. Проверить IP/geo/allowlist rules.
8. Не ослаблять security глобально.
9. Исправить конкретную policy.
10. Проверить позитивный и негативный сценарии.

Источники и спецификации

• RFC 9110: 403 Forbidden
• RFC 9110: 401 Unauthorized
• curl: официальная документация