403 Forbidden: причини, виправлення й блокування ботів

403 проти 401

RFC 9110 проводить межу чітко. 401 Unauthorized означає, що потрібна автентифікація, або надані облікові дані не прийнято, і відповідь має нести заголовок WWW-Authenticate, що описує, як автентифікуватися. 403 Forbidden означає, що сервер відмовляється авторизувати запит, і повторна автентифікація не допоможе.

Специфікація також дозволяє серверу відповідати 404 замість 403, коли він не хоче розкривати, що ресурс узагалі існує. Тому URL-адреса, про яку ви знаєте, що вона є, може повернутися з захищеного сервера як "не знайдено". Розбираючи 403, пам'ятайте, що зворотний випадок теж існує.

Що спричиняє 403

• Права файлової системи. Процес вебсервера не може прочитати файл чи пройти через директорію. Класика після ручного копіювання файлів чи відновлення, що змінило власника.
• Лістинг директорій вимкнено. Запит до папки без індексного файлу повертає 403 на серверах, налаштованих відмовляти в лістингах. Правильна поведінка, заплутана помилка.
• Правила авторизації застосунку. Користувач увійшов у систему, але йому бракує ролі, тарифу чи членства в орендарі, потрібних для цього ресурсу.
• Списки дозволених і заборонених IP. Адмінський шлях, обмежений офісними адресами, повертає 403 усім іншим, включно з будь-ким, хто тестує з дому чи з мобільної мережі.
• Правила міжмережевого екрана вебзастосунків. WAF блокує запит, чия URL-адреса, заголовки чи тіло збіглися з сигнатурою. Часто запит виглядає для вас цілком невинним.
• Гео-блокування. Трафік з деяких країн чи регіонів відхиляють на краю мережі, тож сайт у порядку з одного континенту і заборонений з іншого.
• Захист від хотлінкінгу. Правило, що відхиляє запити на зображення чи медіа, чий заголовок Referer відсутній чи вказує на інший домен. Запити без реферера часто потрапляють під це випадково.
• Фільтрування ботів і user agent. Запит заблоковано через те, за кого себе видає клієнт, а не через те, про що він просив. Саме цей випадок ловить моніторинг.

Випадок "403 для моніторів, 200 для людей"

Це найпоширеніша хибна тривога в моніторингу аптайму, і це не помилка моніторингу. Сайт справді повертає 403, просто не браузерам.

Керування ботами на CDN чи WAF оцінює кожен запит за його user agent, TLS-відбитком, порядком заголовків, репутацією IP і тим, чи проходить він виклик JavaScript чи інтерактивний виклик. Автоматизована HTTP-перевірка за задумом - автоматизований клієнт: вона не виконує виклики JavaScript і чесно ідентифікує себе. Тож її блокують чи кидають на виклик, поки ваш браузер проходить безперешкодно, і результат - сайт, що сигналізує про недоступність, поки кожна людина підтверджує, що він працює.

Дві ознаки швидко це видають: 403 приходить миттєво, а не із затримкою, що виключає перевантаження, і він стабільний для автоматизованого клієнта, але ніколи не відтворюється в браузері в тій самій мережі.

Як додати службу моніторингу в allowlist

1. Підтвердьте, що блокування засноване на ідентичності. Повторіть запит як звичайний HTTP-клієнт, а тоді з рядком user agent браузера, і порівняйте:

   curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
   curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://example.com/

   Якщо коди різняться, це робить правило user agent.
2. Знайдіть правило, що спрацювало. Панелі WAF і CDN логують заблоковані запити з ідентифікатором відповідного правила. Це швидше й безпечніше, ніж угадувати, яке правило послабити.
3. Додавайте в allowlist за IP-адресою, де можна. Провайдери моніторингу публікують адреси, які використовують їхні контрольні точки. Додати їх як правило-виняток точно, і не послаблює захист ні для кого іншого.
4. Або додавайте в allowlist за user agent. Налаштуйте перевірку надсилати характерний user agent і додайте правило, що робить для нього виняток. Це легше підтримувати, ніж список IP, але сприймайте це як зручність, а не межу безпеки, бо user agent може скопіювати будь-хто.
5. Віддавайте перевагу правилу-винятку над вимкненням захисту. Зробіть виняток для шляху чи клієнта моніторингу з конкретного правила, а решту набору правил лишіть чинною.
6. Перевіряйте повторно з кількох регіонів. Правило може застосовуватися нерівномірно між edge-локаціями, тож підтвердьте виправлення більш ніж із одного місця, перш ніж закривати тікет.

Виправлення 403, що не про ботів

1. Перевірте, чи URL-адреса взагалі має бути публічною. Половина розслідувань 403 закінчується відповіддю, що блокування правильне.
2. Перевірте власника й права на шляху й на кожній батьківській директорії. Процесу сервера потрібне право виконання на директоріях, не лише право читання на файлі.
3. Шукайте індексний файл, якщо URL-адреса - це директорія, або навмисно увімкніть лістинг, якщо він потрібен.
4. Читайте конфігурацію сервера на предмет правил заборони, обмежень за IP і перевірок реферера на цьому шляху, тоді рівень авторизації застосунку.
5. Перевірте край мережі перед origin. Запитайте origin напряму. 403, що зникає, коли ви обходите CDN, - це правило edge, а не проблема застосунку.

Як побачити блокування ззовні власної мережі

403, спричинений оновленням WAF чи зміною прав, не виглядає як збій зсередини: ваша сесія автентифікована, ваша адреса в allowlist, а сторінки, які ви перевіряєте, - саме ті, що працюють. Запланована HTTP-перевірка перевіряє очікуваний код на важливих URL-адресах ззовні вашої мережі, тож щойно заборонена сторінка одразу піднімає сповіщення. Гео-блокування й edge-правила різняться за регіоном, тож кількість точок спостереження важлива: HostTracker перевіряє з понад 300 точок у 158 містах, що перетворює "заборонено в деяких країнах" на видиму різницю між локаціями. Якщо відмова тимчасова й пов'язана з обсягом запитів, а не з ідентичністю, код зазвичай буде 429 замість цього, це розглянуто в посібнику з 429 Too Many Requests, а ширша родина - в огляді 4xx.