Po wpisaniu adresu HTTP w przeglądarce internetowej wyświetla się błąd „403 Forbidden”, który oznacza, że
Kod HTTP 403 Forbidden oznacza, że serwer zrozumiał żądanie przeglądarki, ale odmawia dostępu do wskazanego zasobu. Czyli nie chodzi o to, że strona nie istnieje, tylko o to, że użytkownik albo klient nie ma odpowiednich uprawnień. W praktyce może to wynikać z braku logowania, niewłaściwej roli użytkownika, blokady adresu IP, reguł w pliku .htaccess, konfiguracji serwera WWW albo polityki dostępu w aplikacji. Moim zdaniem warto zapamiętać prostą różnicę: 404 Not Found to brak zasobu, 401 Unauthorized zwykle wymaga uwierzytelnienia, a 403 Forbidden mówi: „wiem, o co prosisz, ale nie wolno ci tego dostać”. W dobrych praktykach administracyjnych taki błąd sprawdza się od strony uprawnień plików i katalogów, konfiguracji serwera Apache/Nginx/IIS, reguł zapory oraz mechanizmów autoryzacji w aplikacji. To ważne także przy bezpieczeństwie, bo serwer nie powinien ujawniać użytkownikowi więcej informacji niż potrzeba.
Błąd 403 Forbidden łatwo pomylić z innymi problemami, bo użytkownik widzi po prostu, że strona się nie otwiera. Jednak technicznie jest to odpowiedź protokołu HTTP związana z odmową dostępu, a nie z fizycznym brakiem pliku na serwerze. Gdy zasób nie istnieje albo serwer nie może go znaleźć pod podanym adresem URL, typowym kodem jest 404 Not Found. To inny przypadek: przy 403 serwer najczęściej wie, że zasób istnieje, ale nie pozwala go pobrać. Błędna konfiguracja adresu IP karty sieciowej też nie pasuje do tego komunikatu. Gdy komputer ma źle ustawiony adres IP, maskę, bramę albo DNS, częściej pojawi się problem z połączeniem, brak odpowiedzi serwera, timeout albo komunikat przeglądarki o niemożności odnalezienia strony. Sam kod 403 pochodzi już z warstwy aplikacji, więc oznacza, że komunikacja HTTP jednak zaszła. Ograniczenie wielkości danych wysyłanych przez klienta również ma swoje osobne kody i sytuacje, np. 413 Payload Too Large, gdy żądanie jest za duże. Typowy błąd myślowy polega na traktowaniu wszystkich komunikatów WWW jako awarii sieci. W diagnostyce warto patrzeć warstwowo: najpierw łączność, potem DNS, potem HTTP, a na końcu uprawnienia i konfiguracja aplikacji. Tutaj kluczowe są właśnie autoryzacja i kontrola dostępu.