Błąd 403 Forbidden oznacza, że serwer otrzymał żądanie, zrozumiał je i odmówił odpowiedzi. W przeciwieństwie do 401 zalogowanie się niekoniecznie pomoże: serwer mówi, że ten klient, z tego adresu, z tymi uprawnieniami nie ma dostępu do tego zasobu. Przyczyną prawie zawsze jest jakaś reguła, a nie awaria: uprawnienia plików, brak pliku indeksu, reguła deny w konfiguracji serwera, firewall lub ochrona przed botami, blokada IP lub kraju albo konto bez odpowiedniej roli. Właściciele stron znajdą tę regułę w logu błędów albo w dzienniku zdarzeń firewalla; odwiedzający mogą zwykle zmienić tylko to, co wysyłają.
403 a 401 a 404
KodCo mówi serwerCo pomaga401 UnauthorizedKim jesteś? Podaj dane logowania.Zalogowanie się albo prawidłowy klucz API lub token403 ForbiddenWiem, czego chcesz, i nie mogę Ci tego dać.Inne uprawnienia, adres lub żądanie404 Not FoundNic tu nie ma.Właściwy adres
Serwery nie zawsze trzymają się podręcznika. Niektóre zwracają 404 zamiast 403, żeby ukryć istnienie prywatnej strony, a inne zwracają 403 dla brakujących plików: prywatny bucket w magazynie danych może na przykład zwrócić 403 dla obiektu, którego nie ma, jeśli klient nie ma prawa wyświetlać zawartości bucketu. Resztę znajdziesz w zestawieniu kodów statusu HTTP.
Najczęstsze przyczyny
Uprawnienia plików i folderów. Użytkownik serwera WWW nie może odczytać pliku ani wejść do folderu – często po wgraniu plików lub wdrożeniu, które skopiowało je jako inny użytkownik.
Brak pliku indeksu. Żądanie folderu bez index.html lub index.php na serwerze z wyłączonym listowaniem katalogów kończy się kodem 403. Tak samo działa nieudane wdrożenie, które zostawiło pusty folder.
Reguły deny. deny all w nginx, Require all denied w Apache albo reguła w .htaccess, która blokuje ścieżkę, typ pliku lub user agenta.
Firewall lub ochrona przed botami. WAF, ochrona przed botami w CDN albo wtyczka bezpieczeństwa uznaje, że żądanie wygląda na automatyczne lub złośliwe, i je blokuje, czasem stroną z wyzwaniem.
Blokady IP i krajów. Adres, sieć lub kraj odwiedzającego jest na liście blokad albo strona jest dostępna tylko z sieci biurowej lub przez VPN.
Brak uprawnień. Odwiedzający jest zalogowany, ale jego rola nie daje dostępu do strony, albo kluczowi API brakuje zakresu (scope) dla danego endpointu.
Wygasłe lub błędne podpisane linki. Linki do pobrania z podpisem lub terminem ważności zwracają 403, gdy wygasną.
Ochrona przed hotlinkowaniem. Obrazy lub pliki pobierane z innej strony albo bez oczekiwanego nagłówka Referer są odrzucane.
Co mogą zrobić odwiedzający
Sprawdź adres. Link, który kończy się na folderze zamiast na stronie, albo literówka w ścieżce mogą trafić na folder, którego serwer nie wyświetla.
Zaloguj się albo zaloguj się na właściwe konto. Niektóre serwisy pokazują 403 niezalogowanym odwiedzającym lub kontom bez dostępu.
Wyczyść pliki cookie serwisu i odśwież stronę. Stara sesja lub nieaktualne cookie z wyzwania mogą sprawiać, że firewall wciąż Cię odrzuca.
Zmień sieć. Wyłącz VPN lub proxy albo je włącz, albo spróbuj przez dane mobilne. Adresy współdzielone i z centrów danych są blokowane częściej niż domowe łącza.
Wyłącz rozszerzenia dla tego serwisu. Niektóre rozszerzenia chroniące prywatność zmieniają nagłówki tak, że uruchamiają firewall.
Daj znać właścicielowi serwisu, podając godzinę i ewentualny numer referencyjny ze strony błędu. Dzięki temu numerowi znajdzie dokładnie tę regułę.
Jak właściciel strony może to znaleźć i naprawić
Najpierw ustal, kto odpowiedział. Przyjrzyj się stronie błędu i nagłówkom odpowiedzi: CDN lub firewall zwykle się przedstawia – stroną we własnym stylu, nagłówkiem Server albo identyfikatorem żądania. Jeśli to Twój serwer WWW, przyczynę poda jego log błędów. Jeśli CDN lub WAF – jego dziennik zdarzeń.
Uprawnienia i pliki indeksu
Na serwerach z Linuksem foldery zwykle potrzebują uprawnień 755, a pliki 644, a ich właścicielem powinien być użytkownik, jako który działa serwer WWW lub PHP. Sprawdź stan przed jakąkolwiek zmianą i nigdy nie naprawiaj błędu 403 uprawnieniami 777, które pozwalają każdemu użytkownikowi serwera zapisywać pliki Twojej strony:
ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +
nginx zapisuje w logu „directory index of … is forbidden”, gdy folder nie ma pliku indeksu; Apache loguje, że nie może znaleźć indeksu, a listowanie katalogów jest wyłączone. Sprawdź, czy wdrożenie umieściło pliki tam, gdzie wskazuje katalog główny dokumentów serwera.
Reguły serwera
nginx loguje „access forbidden by rule” przy regule deny, a Apache „client denied by server configuration” przy regule Require. Przeszukaj konfigurację i każdy plik .htaccess na ścieżce w poszukiwaniu pasującej reguły. W WordPressie zapisanie ustawień bezpośrednich odnośników nadpisuje podstawową część .htaccess, a wtyczki bezpieczeństwa dodają tam własne blokady, a także w swoich ustawieniach.
Firewalle, CDN-y i wtyczki bezpieczeństwa
Znajdź zablokowane żądanie w dzienniku zdarzeń po czasie, adresie lub identyfikatorze żądania, sprawdź, która reguła zadziałała, i zdecyduj, czy reguła jest błędna, czy żądanie rzeczywiście było niepożądane. Dodawaj wyjątki dla konkretnych adresów lub ścieżek, zamiast wyłączać regułę dla całego serwisu. Po zmianie w firewallu testuj z sieci spoza biura, bo Twój własny adres może być na liście dozwolonych.
Dlaczego monitor dostaje 403, a Twoja przeglądarka nie
Częsta sytuacja: strona u Ciebie działa, ale monitor dostępności zgłasza 403. Zwykle nic nie jest zepsute. Coś przed stroną traktuje sprawdzenie jak bota – bo nim jest:
Ochrona przed botami. CDN-y i WAF-y stawiają wyzwania klientom, którzy nie uruchamiają JavaScriptu lub wyglądają na automatycznych. Przeglądarka rozwiązuje wyzwanie, monitor nie potrafi, więc dostaje 403 albo stronę z wyzwaniem.
Adresy z centrów danych. Monitory sprawdzają z serwerów, a niektóre reguły domyślnie blokują sieci hostingowe.
Blokady krajów. Serwis, który wpuszcza tylko ruch z własnego kraju, blokuje monitor sprawdzający z zagranicy.
Reguły limitów. Niektóre firewalle zwracają 403 zamiast 429, gdy klient wysyła zbyt wiele żądań.
Rozwiązaniem jest dodanie monitora do listy dozwolonych, najlepiej po adresach IP, bo user agenta może skopiować każdy. Nie rozwiązuj tego, uznając 403 za „dostępne” dla całego serwisu: wtedy prawdziwa blokada Twoich odwiedzających przejdzie niezauważona. Jeśli strona naprawdę musi pozostać za ochroną, monitoruj endpoint health check poza nią. Przewodnik o ograniczaniu fałszywych alertów opisuje inne przyczyny alertów, które nie są awariami.
Błędy 403 a Uptimecheck
Monitor HTTP(S) w ramach monitorowania dostępności Uptimecheck domyślnie uznaje statusy od 200 do 399 za dostępne, więc 403 liczy się jako awaria. Drugie sprawdzenie potwierdza ją, zanim dostaniesz alert, a incydent wyjaśnia, kto odpowiedział: gdy 403 lub strona z wyzwaniem pochodzi z Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence lub AWS WAF, incydent podaje nazwę tej usługi i to, co należy w niej dopuścić. Sprawdzenia stron odbywają się ze Sztokholmu w Szwecji, z user agentem zawierającym „Uptimecheck”. Artykuł Jak przepuścić Uptimecheck przez firewall podaje nasze adresy wraz z gotowymi regułami dla Cloudflare, wtyczek bezpieczeństwa WordPressa i nginx, a artykuł dlaczego monitor może zgłaszać awarię, gdy strona działa opisuje pozostałe powody.
Chcesz wiedzieć, czy strona w ogóle odpowiada? Bezpłatne narzędzie Is it down? uznaje każdą odpowiedź poniżej 500, w tym 403, za dostępną: serwer odpowiedział, nawet jeśli odmówił.
Odróżniaj zablokowane sprawdzenie od prawdziwej awarii. Wypróbuj Uptimecheck bezpłatnie przez 14 dni, bez karty kredytowej.