Błąd ERR_BLOCKED_BY_PRIVATE_NETWORK_ACCESS_CHECKS – przyczyny i naprawa

Błąd ERRBLOCKEDBYPRIVATENETWORKACCESSCHECKS pojawia się, gdy przeglądarka (zwłaszcza Google Chrome) blokuje dostęp do zasobów znajdujących się w prywatnej sieci (np. localhost, urządzenia w tej samej sieci LAN), wywoływany z publicznie dostępnej strony internetowej lub przez niespełnienie nowych wymagań bezpieczeństwa przeglądarki. Poniżej znajduje się szczegółowe omówienie przyczyn, wyjaśnienie techniczne działania oraz instrukcje krok po kroku zarówno dla webmasterów/deweloperów, jak i użytkowników końcowych.

Czym jest ERRBLOCKEDBYPRIVATENETWORKACCESSCHECKS?

Ten błąd informuje, że przeglądarka zablokowała próbę połączenia strony internetowej (lub aplikacji webowej) z zasobami w prywatnej sieci, np. serwerem lokalnym, bazą danych lub urządzeniem IoT, ponieważ nie spełniono wymagań wynikających z polityki Private Network Access (PNA). Polityka ta jest wdrażana w Chrome od wersji 94 i ma na celu zapobieganie atakom typu CSRF oraz innym zagrożeniom bezpieczeństwa związanym z dostępem do infrastruktury sieci lokalnej przez skrypt z internetu.

Typowe scenariusze, w których występuje błąd

• Strona internetowa hostowana publicznie próbuje połączyć się z zasobami w sieci lokalnej użytkownika (np. AJAX do http://localhost lub 192.168.x.x)
• Aplikacje developerskie (SPA, dashboardy, API testowe uruchamiane lokalnie)
• Rozwiązania hybrydowe (np. front na hostingu zewnętrznym, backend w sieci LAN)
• Próba połączenia z urządzeniem IoT lub innym serwerem w tej samej sieci, którą uważa się za “prywatną” przez przeglądarkę

Przyczyny występowania błędu

1. Zmiany w polityce bezpieczeństwa Chrome – Chrome wdrożył mechanizm Private Network Access. Publiczne strony www nie mogą inicjować żądań do zasobów w prywatnej sieci bez spełnienia konkretnych warunków.
2. Brak nagłówka CORS (Access-Control-Allow-Private-Network w odpowiedzi serwera) – Serwer w sieci prywatnej nie wystawia wymaganego nagłówka.
3. Brak HTTPS – Wersje testowe PNA wymagają, by żądania pochodziły z kontekstu bezpiecznego (HTTPS).
4. Polityki sieciowe lub zapory blokujące ruch – Sieci firmowe lub domowe mogą wprowadzać własne ograniczenia.

Jak naprawić błąd – instrukcje krok po kroku

Dla Webmastera / Web Developera

1. Zrozum wymagania Private Network Access

• JavaScript w przeglądarce nie może wykonywać żądań do hostów w prywatnej sieci, jeśli strona nie jest serwowana przez HTTPS i serwer nie odpowiada odpowiednim nagłówkiem CORS.
• W Chrome domyślnie od wersji 94 zaczęto blokować nieautoryzowane połączenia z prywatnymi zasobami.

2. Włącz HTTPS wszędzie tam, gdzie to możliwe

• Upewnij się, że zarówno frontend, jak i backend są dostępne przez HTTPS (również lokalnie, np. przez self-signed certificate lub np. mkcert).

3. Skonfiguruj serwer w sieci prywatnej

• Dodaj nagłówek w odpowiedzi na żądania CORS:

 Access-Control-Allow-Origin: <origin> Access-Control-Allow-Private-Network: true 

• W przypadku dynamicznej obsługi, odczytaj nagłówek Origin i zwracaj go w Access-Control-Allow-Origin.

4. Dla środowisk deweloperskich (tylko tymczasowo)

• Uruchom Chrome ze specjalną flagą wyłączającą wymuszenie PNA:

 chrome.exe --disable-features=BlockInsecurePrivateNetworkRequests 

Jednak jest to rozwiązanie wyłącznie do testów, nieprodukcyjne!

5. Zastosuj deprecation trial (tylko przejściowo)

• Google udostępnił tzw. deprecation trial tokens, które pozwalają czasowo wyłączyć restrykcje na publicznej stronie. Szczegóły na blogu Chrome Developers.

Dla użytkownika końcowego

1. Odśwież stronę lub spróbuj innej przeglądarki, która nie wymusza jeszcze PNA (np. Firefox).

2. Upewnij się, że jesteś połączony z właściwą siecią (nie z publiczną siecią Wi-Fi, gdzie reguły mogą być ostrzejsze).

3. Zgłoś problem administratorowi strony lub IT – użytkownik końcowy nie ma zwykle uprawnień do zmiany nagłówków serwera lub zabezpieczeń strony.

Najczęstsze pytania i wyjaśnienia

Dlaczego Google wprowadziło tę zmianę?
Aby uniemożliwić ataki, w których publiczny serwis WWW próbuje nieautoryzowanie komunikować się z Twoją wewnętrzną siecią LAN — do tej pory często wykorzystywane w atakach CSRF i na urządzenia IoT.

Czy można całkowicie wyłączyć ten mechanizm?
Nie, wewnętrznie w produkcyjnym Chrome nie można tego trwało wyłączyć. Deweloperzy mogą użyć flagi lub deprecation trials jedynie tymczasowo w środowiskach testowych.

Co zrobić, gdy jestem użytkownikiem, a strona nie działa?
Zgłoś problem właścicielowi strony — po jego stronie leży rozwiązanie problemu przez wdrożenie odpowiedniego nagłówka CORS i procedur bezpieczeństwa.

Czy Edge, Opera i inne przeglądarki też wprowadzą ten mechanizm?
Edge już korzysta z silnika Chromium, więc analogiczna polityka została lub zostanie wdrożona także tam. Firefox i Safari mają własną politykę bezpieczeństwa, ale mogą wdrożyć podobne ograniczenia w przyszłości.

Przykładowa konfiguracja nagłówków (dla serwera Node.js/Express)

app.use((req, res, next) => { res.header("Access-Control-Allow-Origin", req.headers.origin || "*"); res.header("Access-Control-Allow-Private-Network", "true"); next(); }); 

Podsumowanie kluczowych działań:

• Zawsze używaj HTTPS do komunikacji między frontendem i backendem.
• Aktualizuj backend, by poprawnie obsługiwał żądania CORS z Access-Control-Allow-Private-Network.
• Informuj użytkowników o tymczasowych ograniczeniach i współpracuj z IT, by wdrażać zmiany.

Referencyjne źródła –

• Chrome Developers Blog – Private Network Access update
• oTechWorld – lista błędów sieciowych Chrome