Błąd 403 Forbidden oznacza, że serwer zrozumiał twoje żądanie i odmówił jego wykonania. Ktoś ustawił regułę, która to żądanie odrzuca - w proxy, serwerze WWW albo aplikacji. Naprawa polega na znalezieniu tej jednej reguły, nie na zbiorczym zmienianiu uprawnień do plików.

Na cudzej stronie możesz zrobić dwie rzeczy: sprawdzić, czy jesteś zalogowany i czy adres jest poprawny, a potem zgłosić problem właścicielowi. Reszta tego tekstu jest dla osoby, która administruje serwerem zwracającym 403 - i chce go naprawić bez otwierania dostępu wszystkim.

Co naprawdę mówi błąd 403 Forbidden?

Status 403 Forbidden to odpowiedź HTTP, w której serwer potwierdza, że zrozumiał żądanie, i jednocześnie odmawia jego spełnienia. Sam kod nie mówi, kto odmówił ani dlaczego - odpowiedź mogła powstać w zaporze na brzegu, w proxy, w serwerze WWW albo w aplikacji. Dopiero log tego komponentu wskazuje regułę.

Nie myl 403 z prośbą o logowanie. Status 401 mówi: brakuje prawidłowych danych logowania, uzupełnij je i spróbuj ponownie. Status 403 mówi: wiem, kim jesteś albo skąd przychodzisz, i mimo to odmawiam. Ponawianie tego samego żądania z tymi samymi danymi niczego więc nie zmieni - zmienić się musi reguła albo podmiot.

Jest jeszcze trzecia możliwość, o której łatwo zapomnieć: serwer może zwrócić 404 zamiast 403, gdy chce ukryć samo istnienie chronionego zasobu. Brak kodu 403 nie dowodzi więc, że kontrola dostępu nie bierze udziału w obsłudze żądania.

Panel działa u administratora, u księgowej nie

Zobacz, jak wygląda typowa pułapka tej diagnozy. Przykład jest fikcyjny, złożony z powtarzalnych awarii po przenosinach serwisu - nie opisuje konkretnej firmy.

Mały sklep internetowy przeszedł na nowy serwer. Strona działa, zamówienia spływają, ale księgowa dzwoni z biura: panel administracyjny pokazuje "403 Forbidden". Administrator otwiera ten sam adres u siebie w domu - działa bez zarzutu. Najpierw podejrzewa uprawnienia plików po przenosinach. Zmienia więc tryby całego katalogu panelu i prosi o test. Dalej 403.

Dopiero porównanie obu prób pokazuje różnicę: ten sam adres, ta sama przeglądarka, inny wynik. Skoro jedna lokalizacja przechodzi, a druga nie, to nie pliki odmawiają - odmawia reguła zależna od adresu klienta. W konfiguracji nginx, przy sekcji panelu, siedzi lista allow ze starymi adresami biura i deny all na końcu. Biuro zmieniło operatora internetu pół roku wcześniej, lista została. Jedna poprawiona linijka kończy sprawę - a godziny spędzone przy uprawnieniach plików nie były nawet blisko.

Ta historia streszcza całą metodę: zanim cokolwiek zmienisz, ustal, co dokładnie różni żądanie odrzucone od przyjętego, i znajdź regułę, która na tę różnicę reaguje.

Zacznij od odtworzenia żądania

Zbierz komplet danych o próbie, która dostała odmowę:

  1. dokładny adres URL razem z nazwą hosta,
  2. metodę żądania - GET, POST albo inną,
  3. stan logowania osoby, u której wystąpił błąd,
  4. moment próby, z dokładnością do minuty,
  5. miejsce, z którego wysłano żądanie - biuro, dom, telefon z sieci komórkowej.

Te dane pozwolą ci potem znaleźć w logach wpis dotyczący tej konkretnej próby, a nie dowolny komunikat z podobnym kodem. Jeżeli błąd dotyczy formularza wysyłanego POST-em, nie traktuj testu GET jako odtworzenia - inna metoda może trafiać w inną regułę.

Dla żądania GET bez logowania odtworzysz próbę jedną komendą:

curl --silent --show-error --dump-header - --output /dev/null 'https://HOST/SCIEZKA'

Podmień HOST i /SCIEZKA na badany adres. Komenda wypisze nagłówki odpowiedzi: --dump-header - kieruje je na ekran, --output /dev/null odrzuca treść strony, a para --silent --show-error wycisza pasek postępu, zostawiając komunikaty błędów.

Taki test nie niesie cookies ani nagłówka autoryzacji, więc nie odtwarza sesji zalogowanego użytkownika. Wynik mówi ci, co widzi anonimowy klient - i tylko tyle. I jedna zasada bez wyjątków: tokenów, cookies i danych logowania nie wklejasz do zgłoszeń, artykułów ani współdzielonego terminala.

Który komponent odmówił?

Żądanie po drodze do aplikacji może minąć kilka warstw: zaporę albo CDN na brzegu, proxy, serwer WWW, na końcu samą aplikację. Każda z nich umie zwrócić 403 i każda loguje osobno. Weź zapisany moment próby i ścieżkę, a potem przejdź logi warstw po kolei, szukając wpisu o tym jednym żądaniu.

Wynik tego przeszukania rozstrzyga, gdzie prowadzisz dalszą diagnozę:

  1. Wpis z odmową jest w logu serwera WWW albo proxy - zestaw go z blokiem konfiguracji dopasowanym do tej ścieżki i szukaj reguły dostępu.
  2. Wpis jest w logu aplikacji - sprawdź decyzję jej mechanizmu autoryzacji: rolę, uprawnienie, regułę dla zasobu.
  3. Wpisu nie ma nigdzie po stronie twojego serwera - żądanie zatrzymała wcześniejsza warstwa, na przykład CDN albo zapora. Sprawdź jej panel i logi, zgodnie z rzeczywistą drogą ruchu.

Brak wpisu w logu dowodzi tylko jednego: żądanie tam nie dotarło. Nie wskazuje jeszcze, kto je zatrzymał - to musisz sprawdzić warstwa po warstwie.

Od obserwacji do testu

Poniższa tabela prowadzi od tego, co widzisz, do sprawdzenia, które niczego jeszcze nie zmienia. Regułę modyfikujesz dopiero wtedy, gdy masz dowód, że to ona odpowiada za odmowę.

Obserwacja Gdzie szukać odmowy Dowód do sprawdzenia Następny test
Jeden zalogowany użytkownik widzi zasób, drugi dostaje 403 autoryzacja aplikacji albo serwera WWW wpisy w logu dla obu żądań i reguła przypisana użytkownikowi porównaj decyzję dla obu kont, bez zmiany ich praw
Wynik zależy od miejsca, z którego przychodzi żądanie kontrola adresu klienta w nginx albo wcześniejszej warstwie dopasowany blok konfiguracji i kolejność allow oraz deny odczytaj pierwszą regułę pasującą do badanego adresu
GET przechodzi, POST dostaje 403 reguła dotycząca metody w serwerze WWW lub aplikacji wpis w logu z metodą i dopasowana reguła powtórz oba żądania na tę samą ścieżkę i porównaj wpisy
403 dotyczy jednej ścieżki, reszta działa blok lokalizacji, przepisywanie adresów albo autoryzacja zasobu wpis z dokładną ścieżką i konfiguracja jej obsługi odczytaj regułę dopasowaną do tej ścieżki
Adres katalogu z ukośnikiem na końcu zwraca 403 obsługa pliku indeksowego lub listowania katalogu lista plików index i stan autoindex w bloku nginx sprawdź, czy plik indeksowy istnieje, bez włączania listowania
W konfiguracji jest jawna odmowa nginx albo Apache HTTP Server pierwsza pasująca reguła allow lub deny, dyrektywa Require, RewriteRule z flagą [F] potwierdź, że badane żądanie pasuje do tej reguły
Log serwera zgłasza odmowę otwarcia pliku lub przejścia przez katalog dostęp procesu serwera do systemu plików właściciel, grupa i prawa każdego elementu ścieżki odczytaj prawa z perspektywy procesu, bez uruchamiania chmod

Gdzie szukać reguły w nginx?

Znajdź blok konfiguracji dopasowany do badanego hosta i ścieżki. Dyrektywy allow i deny ograniczają dostęp według adresu klienta, a nginx sprawdza je po kolei i zatrzymuje się na pierwszym dopasowaniu. Liczy się więc nie tylko treść reguły, ale i jej miejsce na liście - deny nad pasującym allow wygrywa.

Przy adresie katalogu z ukośnikiem na końcu obejrzyj dyrektywę index. Wymienia ona pliki indeksowe, które nginx próbuje po kolei. Gdy żadnego nie znajdzie, żądanie może przejąć moduł autoindex, a ten jest domyślnie wyłączony - i właśnie stąd bierze się 403 na katalogu pełnym plików. Nie włączaj publicznego listowania jako naprawy. Ustal najpierw, czy katalog ma serwować plik indeksowy, i wskaż go w konfiguracji.

Gdzie szukać reguły w Apache?

W Apache HTTP Server dostęp rozstrzygają dyrektywy Require - w konfiguracji serwera oraz, jeśli to dopuszczono, w pliku .htaccess. Zapis Require all denied odmawia bezwarunkowo, pozostałe warianty oceniają użytkownika według wskazanego mechanizmu.

Plik .htaccess ma pułapkę - reguły z tego pliku działają tylko wtedy, gdy konfiguracja serwera dopuszcza ich klasę przez AllowOverride. Sama obecność dyrektywy w pliku nie znaczy więc, że bierze ona udział w obsłudze żądania - sprawdź, czy w ogóle jest czytana.

Trzecie miejsce to przepisywanie adresów. Jeżeli log albo konfiguracja prowadzą do RewriteRule, obejrzyj flagi dopasowanej reguły: flaga [F] każe zwrócić 403. Nie wyłączaj całego .htaccess ani mechanizmu przepisywania. Wskaż jedną regułę i zakres żądań, których dotyczy.

Kiedy sprawdzać uprawnienia plików?

Wtedy, gdy log serwera pokazuje odmowę otwarcia pliku albo przejścia przez katalog. Bez takiego wpisu zmiana trybów jest strzałem w ciemno - w najlepszym razie nic nie da, w najgorszym otworzy dostęp szerzej, niż ktokolwiek planował.

Przy katalogach mylą się dwa prawa: x pozwala wejść do katalogu i sięgnąć po obiekty w środku, r pozwala wylistować zawartość. Serwer, który ma odczytać plik, potrzebuje prawa x do każdego katalogu na drodze do niego - brak tego prawa w dowolnym miejscu ścieżki kończy się błędem EACCES. Sprawdź więc właściciela, grupę i prawo x wszystkich katalogów nadrzędnych, patrząc z perspektywy użytkownika, na którym działa proces serwera.

Rozdziel przy tym dwa pojęcia. HTTP 403 to odpowiedź protokołu, którą widzi klient. EACCES, w terminalu wyświetlany jako Permission denied, to błąd systemu plików - może pojawić się w logu serwera jako dowód, ale to inna warstwa. Sam komunikat Permission denied rozbieramy osobno, a bezpieczną zmianę trybów i właściciela opisuje tekst o chmod.

Jak potwierdzić naprawę, nie otwierając wszystkiego?

Po zmianie wskazanej reguły powtórz dokładnie to samo żądanie: ten sam użytkownik, ta sama metoda, ta sama ścieżka. Żądanie zalogowanego użytkownika powtarzasz w jego sesji, w przeglądarce - nie bezstanowym wzorcem curl z początku tekstu. Porównaj odpowiedź z poprzednią i znajdź jej wpis w logu komponentu, który wcześniej odmawiał.

To połowa dowodu. Druga połowa to kontrola negatywna: żądanie od użytkownika albo z adresu, który nadal ma dostawać odmowę - w tej samej warstwie, tą samą metodą, na tę samą ścieżkę. Reguła dostępu ma dwie strony i obie trzeba sprawdzić. Naprawa, po której wszyscy mają dostęp, nie jest naprawą, tylko wyłączeniem kontroli.

Jeden udany adres potwierdza przy tym wyłącznie badane żądanie i jego drogę obsługi. Nie traktuj go jako dowodu, że cała aplikacja i wszystkie reguły autoryzacji działają poprawnie.

Pytania o 403 Forbidden

Co oznacza błąd 403 Forbidden?

Serwer zrozumiał żądanie i odmawia jego spełnienia. Kod sam z siebie nie wskazuje ani reguły, ani komponentu - odpowiedź mogła powstać w proxy, serwerze WWW albo aplikacji. Diagnoza polega na powiązaniu dokładnego żądania z wpisem w logu warstwy, która odmówiła, i z jej konfiguracją.

Jak naprawić błąd 403 na własnym serwerze?

Odtwórz dokładne żądanie z zapisanym momentem próby, znajdź w logach komponent, który zarejestrował odmowę, i odczytaj pasującą regułę dostępu, autoryzacji albo obsługi ścieżki. Zmień tylko tę regułę. Potem powtórz to samo żądanie i wykonaj kontrolę negatywną dla podmiotu, który nadal ma nie mieć dostępu.

Czym różni się 401 od 403?

Status 401 mówi, że żądaniu brakuje prawidłowych danych logowania - uzupełnienie ich może pomóc. Status 403 to odmowa wykonania zrozumianego żądania, także z powodów niezwiązanych z logowaniem, na przykład przez regułę adresową. Konkretnej przyczyny nie wyczytasz z samego kodu, potrzebujesz logu i konfiguracji.

Czy błąd 403 oznacza złe uprawnienia pliku?

Nie zawsze i nie domyślnie. Uprawnienia plików to jedna z kilku warstw, a ich sprawdzanie uzasadnia dopiero wpis w logu o odmowie otwarcia pliku lub przejścia przez katalog. Bez tego dowodu najpierw ustal źródło odpowiedzi i reguły proxy, serwera WWW oraz aplikacji. Trybów nie zmieniaj zbiorczo.

Czy można ominąć 403 Forbidden?

Cudzej kontroli dostępu nie obchodzisz - jeśli masz prawo do zasobu, zaloguj się właściwą ścieżką albo poproś właściciela o dostęp. Właściciel serwera nie omija własnej blokady, tylko ją diagnozuje: wskazuje błędną regułę na podstawie odpowiedzi, logu i konfiguracji, a potem zmienia wyłącznie jej zakres.

Dlaczego katalog zwraca 403, chociaż pliki istnieją?

Katalog bez pliku wymienionego w dyrektywie index zwraca 403, gdy listowanie zawartości jest wyłączone - a w nginx moduł autoindex jest domyślnie nieaktywny. Wskaż właściwy plik indeksowy zamiast włączać publiczne listowanie. Sprawdź też w logu, czy proces serwera ma dostęp do całej ścieżki.

Ten tekst prowadzi diagnozę odpowiedzi HTTP 403 z serwera, proxy albo aplikacji. Pozostałe odmowy i błędy serwera zbiera przewodnik po diagnostyce błędów serwera.

Fakty w tym tekście pochodzą z RFC 9110 (sekcje 15.5.2 i 15.5.4), ze stron man curl i path_resolution(7), z dokumentacji nginx dla modułów ngx_http_access_module, ngx_http_index_module i ngx_http_autoindex_module, z dokumentacji Apache HTTP Server 2.4 dla mod_authz_core, autoryzacji i flag RewriteRule oraz z opisu Mode Structure w GNU Coreutils.