Skip to content

● DIAGNOSTYKA PUBLICZNEGO ZASOBU

Dane.gov.pl nie pobiera pliku: błąd 403 i WAF

Kod 403 oznacza, że serwer zrozumiał żądanie, ale odmówił jego obsługi. Nie potwierdza błędu CSV, XML ani MD5. Przyczyną może być WAF, reguła serwera, ochrona przed botami, blokada adresu IP, wymagane logowanie, hotlink protection albo uprawnienia pliku. Najpierw trzeba ustalić, która warstwa zwróciła odmowę, a dopiero później zmieniać konfigurację.

Sprawdź pobieranie raportu →
Wróć do Wiedzy

Trzy etapy diagnozy 403

01

Ten sam publiczny URL

Sprawdź pełny adres zapisany przy zasobie, kod końcowy po przekierowaniach, HTTPS, typ treści, datę, rozmiar i zawartość bez logowania do WordPressa.

02

Warstwa blokady

Porównaj czas testu ze zdarzeniami CDN lub WAF oraz logami serwera i WordPressa. Brak wpisu na originie wskazuje, że odmowa nastąpiła wcześniej.

03

Minimalny wyjątek

Po potwierdzeniu false positive wyłącz wyłącznie konkretną regułę dla właściwej ścieżki. Następnie ponów test z zewnętrznej sieci i sprawdź, czy reszta ochrony nadal działa.

Jak znaleźć źródło odmowy dostępu

Błąd 403 dotyczy dostępu do zasobu, a nie poprawności jego zawartości. Diagnostyka musi rozdzielić CDN, WAF, serwer źródłowy, WordPress i sam plik.

01

Sprawdź dokładnie ten sam adres

Testuj pełny URL zapisany przy zasobie bez logowania do WordPressa i bez aktywnej sesji administratora. Test wykonany wyłącznie w zalogowanej przeglądarce może dać fałszywie dodatni wynik, ponieważ sesja administratora omija część ograniczeń.

  • Sprawdź zwykłe pobranie GET i kod końcowy po wszystkich przekierowaniach.
  • Potwierdź HTTPS, typ treści, datę i rozmiar zasobu.
  • Zweryfikuj, że pobrany plik zawiera dane, a nie stronę logowania lub błąd HTML.
  • Upewnij się, że URL jest stały i nie wymaga jednorazowego parametru.

02

Ustal, czy blokuje CDN, WAF czy serwer źródłowy

Zapisz godzinę testu w UTC, pełny URL, kod HTTP, nagłówki odpowiedzi i identyfikator żądania, jeżeli został zwrócony. Porównaj ten czas ze zdarzeniami WAF lub CDN, logiem dostępowym serwera, logiem błędów i logiem WordPressa.

Jeżeli zdarzenie jest widoczne w WAF, ale nie w logu źródłowym, odmowa nastąpiła przed WordPressem. Jeżeli żądanie dotarło do hostingu, sprawdź reguły serwera, uprawnienia i sposób obsługi pliku.

03

Najczęstsze źródła 403

Odmowa może wynikać z zabezpieczeń infrastruktury, uwierzytelniania, reguł ścieżki albo uprawnień pliku. Każda przyczyna wymaga innej, ograniczonej poprawki.

  • Reguła Managed WAF, do której legalny URL lub zawartość pasuje jak do sygnatury ataku.
  • Ochrona botów wymagająca JavaScriptu, ciasteczka albo określonego profilu klienta.
  • Blokada IP, kraju lub ASN albo Basic Auth przed publicznym zasobem.
  • Hotlink protection wymagający określonego nagłówka Referer.
  • Reguła .htaccess lub nginx obejmująca katalog raportów.
  • Niewłaściwe uprawnienia pliku albo nieaktualny URL w portalu.

04

Jak poprawić fałszywe trafienie WAF

Dokumentacja Cloudflare zaleca rozpoczęcie od zdarzeń bezpieczeństwa i identyfikacji reguły, która spowodowała blokadę. Jeśli potwierdzono false positive, należy utworzyć wyjątek dla konkretnej reguły zamiast wyłączać cały zestaw ochrony.

  • Odtwórz jedno żądanie i znajdź odpowiadające mu zdarzenie.
  • Zapisz identyfikator reguły i potwierdź, że URL prowadzi wyłącznie do publicznego raportu.
  • Zastosuj najwęższy wyjątek, ponów test z zewnętrznej sieci i sprawdź pozostałe ścieżki.
  • Nie zakładaj stałego IP klienta, jeśli oficjalna dokumentacja nie publikuje takiego zakresu.

05

Odpowiedź 200 też może być błędna

Serwer może zwrócić stronę logowania, challenge WAF albo komunikat HTML z kodem 200. Po pobraniu sprawdź początek i strukturę pliku, Content-Type, oczekiwaną datę, rozmiar, brak przekierowania do logowania oraz sumę kontrolną, jeśli jest elementem procesu.

06

Sprawdź stan widoczny na portalu

Po przywróceniu publicznego dostępu przejdź do widoku zbioru i zasobu, porównaj datę danych oraz sprawdź odczyt przez publiczne API. API dane.gov.pl udostępnia odczyty zbiorów, zasobów, historii i raportu uszkodzonych linków.

Raport uszkodzonych linków jest kontrolą okresową, nie testem w czasie rzeczywistym. Brak adresu w raporcie nie potwierdza, że dzisiejsze pobranie się udało.

07

Dane do zgłoszenia technicznego

Przekaż pełny publiczny URL, czas zdarzenia ze strefą, kod HTTP, końcowy URL, nagłówki bez cookies i sekretów, identyfikator zdarzenia WAF, wynik testu bez logowania i z drugiej sieci oraz oczekiwany typ pliku i datę danych.

Nie wysyłaj haseł, tokenów, ciasteczek sesyjnych ani pełnego pliku konfiguracyjnego.

Bezpieczna kolejność naprawy

  1. Odtwórz błąd na dokładnym publicznym URL bez logowania i zapisz czas testu.
  2. Zbierz kod, nagłówki, końcowy URL, typ odpowiedzi i identyfikator żądania.
  3. Porównaj zdarzenie z logami CDN, WAF, serwera i WordPressa, aby wskazać warstwę blokady.
  4. Potwierdź konkretną regułę lub ustawienie, a następnie wprowadź najwęższy możliwy wyjątek.
  5. Ponów test z zewnętrznej sieci i zweryfikuj rzeczywistą zawartość pliku, nie tylko kod 200.
  6. Sprawdź zasób i datę danych na portalu oraz zachowaj wynik kontroli.

Najczęstsze pytania

Nie. Kod 403 dotyczy odmowy obsługi żądania. Walidację zawartości wykonuje się oddzielnie po uzyskaniu prawidłowego dostępu do pliku.

Źródła oficjalne

  1. RFC 9110 — 403 ForbiddenŹródło pierwotneInternet Engineering Task Force · Dostęp
  2. Troubleshoot Cloudflare managed rulesŹródło pierwotneCloudflare · Dostęp
  3. Cloudflare WAF exceptionsŹródło pierwotneCloudflare · Dostęp
  4. DANE.GOV.PL API — dokumentacja publicznaŹródło pierwotneKancelaria Prezesa Rady Ministrów / dane.gov.pl · Dostęp
  5. Uszkodzone linkiŹródło pierwotneMinister Cyfryzacji — dane.gov.pl · Dostęp

Powiązane tematy

Nie zgaduj, która warstwa blokuje plik

Zbierz URL, czas błędu i identyfikator reguły. Dzięki temu wsparcie może oddzielić problem raportu, hostingu i WAF bez wyłączania całej ochrony.

Przejdź do wsparcia →