Treść mieszana

TL;DR — Treści mieszane to sytuacja, gdy bezpieczna strona https:// ładuje coś — obraz, skrypt, arkusz stylów — przez niezabezpieczone http://. To miesza bezpieczną stronę z niezabezpieczonymi elementami, co niweczy cel HTTPS. Przeglądarki blokują niebezpieczne rodzaje (skrypty, style, iframe) i ostrzegają o łagodniejszych rodzajach (obrazy, multimedia). To najczęstsza rzecz, która psuje stronę zaraz po przejściu na HTTPS, a naprawa jest prosta: spraw, aby każdy zasób ładował się również przez https://.

Czym są treści mieszane

Gdy przenosisz stronę na HTTPS, sama strona ładuje się bezpiecznie. Ale strona nigdy nie jest tylko HTML-em — pobiera obrazy, skrypty, arkusze stylów, czcionki, filmy i czasami osadzone ramki z innych miejsc. Jeśli którykolwiek z tych elementów jest nadal żądany przez zwykłe http://, masz treści mieszane: bezpieczną stronę niosącą niezabezpieczony ładunek. Dowód potwierdzający to twierdzenie Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Zakres: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 MDN: Mixed content

Jak ujmuje to wyjaśnienie Google, “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (tłumaczenie) „Strona ma treści mieszane, gdy jej początkowy HTML jest ładowany przez bezpieczne połączenie HTTPS, ale inne zasoby (takie jak obrazy, filmy, arkusze stylów i skrypty) są ładowane przez niezabezpieczone połączenie HTTP.”

To ma znaczenie, ponieważ niezabezpieczone elementy ponownie otwierają dokładnie tę dziurę, którą HTTPS zamknął. Każdy, kto znajduje się w sieci między odwiedzającym a serwerem, może odczytać lub manipulować tymi żądaniami http:// — więc kłódka w pasku adresu obiecuje więcej bezpieczeństwa, niż strona faktycznie ma.

Dwa rodzaje i co robią z nimi przeglądarki

Przeglądarki nie traktują wszystkich treści mieszanych tak samo. Dzielą je według tego, ile szkód może wyrządzić niezabezpieczony zasób:

• Aktywne treści mieszane — skrypty, arkusze stylów i iframe. Mogą kontrolować całą stronę, więc zmodyfikowany może przepisać wszystko. Przeglądarki je blokują. To właśnie psuje układ, interaktywność lub cały osadzony widżet po migracji.
• Pasywne treści mieszane — obrazy, audio i wideo. Nie mogą przejąć kontroli nad stroną, więc przeglądarki historycznie ładowały je, ale zabierały kłódkę i pokazywały ostrzeżenie „nie w pełni bezpieczne”. To się zmienia — nowoczesne przeglądarki coraz częściej ulepszają lub blokują również te.

Jedną rzeczą, która nie jest treścią mieszaną, jest zwykły link (<a href="http://…">) do strony HTTP. To tylko przenosi Cię gdzieś; nie ładuje niezabezpieczonego elementu do Twojej bezpiecznej strony.

Jak to naprawić

Naprawa jest prawie zawsze taka sama: spraw, aby niezabezpieczony zasób ładował się przez HTTPS. Zmień http:// na https:// w odwołaniu lub użyj ścieżki, która w ogóle nie koduje na sztywno protokołu. W większości przypadków zasób jest już dostępny przez HTTPS — ktoś po prostu zostawił stary URL http:// w szablonie, wtyczce lub bazie danych.

Jeśli chcesz mieć siatkę bezpieczeństwa na wypadek czegoś, co przeoczyłeś, możesz dodać jedną linię konfiguracji — nagłówek upgrade-insecure-requests — który mówi przeglądarce, aby cicho przepisywała pozostałe żądania zasobów http:// na https:// przed ich wysłaniem. To świetna siatka bezpieczeństwa, ale nie jest powodem, aby pominąć sprzątanie prawdziwego źródła. Dowód potwierdzający to twierdzenie The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Zakres: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 MDN: CSP upgrade-insecure-requests

Chcesz pełny obraz — dokładne listy zasobów blokowanych przez przeglądarki, jak wykrywać treści mieszane na dużą skalę za pomocą konsoli DevTools i raportów CSP, dyrektywy upgrade-insecure-requests i block-all-mixed-content, dlaczego Twój CMS ciągle je wprowadza ponownie oraz jak treści mieszane współdziałają z HSTS? Przełącz się na zakładkę Zaawansowane.

TL;DR — Treść mieszana to strona HTTPS ładująca zasób podrzędny przez HTTP. Obecna taksonomia przeglądarek/W3C dzieli ją na uaktualnialną i blokowalną; starszy podział aktywna/pasywna (użyty poniżej jako rama zasięgu oddziaływania) nadal odpowiada temu podziałowi dla większości typów zasobów, z wyjątkami — obrazy z obsługą CORS, kandydaci srcset/picture oraz żądania do hostów IP są blokowalne, mimo że zwykły img src jest uaktualnialny. Aktywna (skrypty, arkusze stylów, iframe, XMLHttpRequest/fetch i wszystko, co przeglądarka wykonuje) jest blokowana — zmodyfikowany skrypt może przepisać stronę — więc to regresja pierwszego dnia, którą należy naprawić najpierw. Pasywna (obrazy, audio, wideo) historycznie ładowała się z obniżonym wskaźnikiem i obecnie jest coraz częściej automatycznie uaktualniana lub blokowana. Linki kotwicowe i inna nawigacja najwyższego poziomu przez HTTP nie są treścią mieszaną; nie są nimi również niezabezpieczone pobierania, które stanowią pokrewną, ale odrębną granicę. Wykrywaj ją na trzech poziomach — pobranym źródle, stanie renderowania/czasu wykonania i rzeczywistych sesjach użytkowników — poprzez przeszukiwanie witryny HTTPS, czytanie konsoli Chrome DevTools (dokładne sformułowanie zależy od przeglądarki/wersji) lub zbieranie naruszeń Content-Security-Policy-Report-Only; napraw ją, potwierdzając, że odpowiednik HTTPS faktycznie działa, a następnie kierując każdy zasób podrzędny na https:// (ścieżki względne/względne protokołu są w porządku, gdy zweryfikujesz własność i zachowanie podstawowego adresu URL, ale nie są uniwersalnym domyślnym rozwiązaniem). Content-Security-Policy: upgrade-insecure-requests przepisuje żądania zasobów podrzędnych http:// w zakresie (w tym żądania między źródłami) na https:// przed ich wysłaniem i przed uruchomieniem kontroli treści mieszanej/CSP — to siatka, a nie substytut naprawy źródła, bez rezerwy HTTP, jeśli uaktualnienie się nie powiedzie, i nie uaktualnia nawigacji najwyższego poziomu do źródeł zewnętrznych, więc nie zastępuje HSTS. Umieszczenie samej dyrektywy w trybie tylko raportowania to brak operacji — monitoruj za pomocą osobnej polityki tylko raportowania. Bazy danych CMS (wykonaj kopię zapasową i przetestuj każdą zamianę — naiwna zamiana ciągów może uszkodzić dane serializowane), wtyczki, motywy, pracownicy usług/pamięci podręczne oraz tagi reklam/analityczne to powracający recydywiści — audytuj na dużą skalę, a nie strona po stronie.

Centrum HTTPS przedstawia treść mieszaną jako jeden z dwóch trybów awarii pierwszego dnia migracji (drugim są przekierowania). To jest szczegółowe omówienie, do którego prowadzi — dokładne poziomy zasobów, stos wykrywania, dyrektywy CSP oraz operacyjne powody, dla których wciąż powraca.

Co jest treścią mieszaną, a co nie

Treść mieszana jest precyzyjnie zdefiniowana: dotyczy zasobów podrzędnych ładowanych przez stronę, a nie linków zawartych na stronie. Definicja Google: „Strona ma treść mieszaną, gdy jej początkowy HTML jest ładowany przez bezpieczne połączenie HTTPS, ale inne zasoby (takie jak obrazy, wideo, arkusze stylów i skrypty) są ładowane przez niezabezpieczone połączenie HTTP.” Dowód potwierdzający to twierdzenie Mixed content occurs when a secure page loads resources over insecure HTTP, and browsers upgrade or block mixed-content requests by resource type. Zakres: MDN documents current browser categories and behavior; individual browser versions may differ at the margins. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 MDN: Mixed content

Pułapką, która fałszywie uspokaja, jest znacznik kotwicy. Link <a href="http://…"> do strony HTTP nie jest treścią mieszaną — prowadzi do nowego dokumentu; nie ładuje niezabezpieczonego zasobu do bieżącego zabezpieczonego. Dotyczy to każdej nawigacji najwyższego poziomu do strony HTTP, nie tylko kliknięć kotwic.

Mimo to warto wysyłać linki wychodzące do miejsc docelowych HTTPS. Przy nowoczesnej przeglądarce domyślna Referrer-Policy (strict-origin-when-cross-origin) sprawia, że kliknięcie ze strony HTTPS do miejsca docelowego HTTP faktycznie pomija nagłówek Referer, co może zniekształcić analitykę odsyłaczy — ale to zachowanie jest zależne od polityki i przeglądarki, a nie uniwersalną zasadą: strona (lub pośredniczący proxy/CDN), która ustawia luźniejszą Referrer-Policy, może nadal wysyłać odsyłacz przy tym obniżeniu. Sprawdź faktyczną Referrer-Policy obowiązującą, zanim stwierdzisz, ile danych o odsyłaczach dana witryna traci — ale w każdym razie to osobny problem od treści mieszanej, a nie sama treść mieszana.

Aktywne a pasywne: rozróżnienie, które wyznacza Twoje priorytety

Nowoczesna dokumentacja przeglądarek i W3C klasyfikuje treści mieszane przede wszystkim jako uaktualnialne versus blokowalne — typy zasobów, które przeglądarka będzie po cichu ponawiać przez HTTPS, versus te, których odmawia wprost — a nie jako starszy podział aktywny/pasywny. Podział aktywny/pasywny jest nadal użytecznym skrótem dla dlaczego przeglądarki wyznaczają tę linię (jak dużą część strony zasób mógłby naruszyć) i tak właśnie przedstawia to własny wyjaśniacz Google, więc poniżej pozostaje jako główna rama triażu — po prostu nie traktuj go jako aktualnej oficjalnej taksonomii, gdy musisz rozumować o konkretnym typie zasobu; zobacz wyjątki po dwóch listach.

Przeglądarki klasyfikują treści mieszane według tego, jak dużą część strony niebezpieczny zasób mógłby narazić. Google: “Active mixed content poses a greater threat than passive mixed content.” (tłumaczenie) „Aktywne treści mieszane stanowią większe zagrożenie niż pasywne treści mieszane.” To jedno zdanie powinno kierować Twoją kolejnością triażu.

Aktywne treści mieszane wchodzą w interakcję z — i mogą przejąć — całą stronę. Google opisuje je jako “scripts, stylesheets, iframes, and any other code the browser can download and execute.” (tłumaczenie) „skrypty, arkusze stylów, iframe’y i każdy inny kod, który przeglądarka może pobrać i wykonać”. W praktyce lista aktywnych elementów to:

• <script src="http://…"> — najgorszy przypadek; przechwycony skrypt może przepisać cały DOM, wykraść dane formularzy lub wstrzyknąć treść.
• <link rel="stylesheet" href="http://…"> — CSS może ukryć, przesunąć lub nałożyć cokolwiek, więc jest traktowane jako aktywne.
• <iframe src="http://…"> — osadzony niebezpieczny dokument wewnątrz Twojego bezpiecznego.
• XMLHttpRequest / fetch() do http:// — niebezpieczne dane, na których strona następnie działa.
• Czcionki internetowe, zasoby <object>/<embed> oraz warianty <link>, które pobierają treści wykonywalne lub kontrolujące układ.

Ponieważ naruszony aktywny zasób może przepisać stronę, “Most browsers already block this type of content by default to protect users.” (tłumaczenie) „Większość przeglądarek już domyślnie blokuje ten typ treści, aby chronić użytkowników”. Dlatego aktywne treści mieszane to to, co widocznie psuje rzeczy po migracji — zablokowany arkusz stylów usuwa Twój CSS, zablokowany skrypt zabija interaktywność, zablokowany iframe pozostawia dziurę. Najpierw napraw aktywne. To funkcjonalny błąd, a nie tylko ostrzeżenie bezpieczeństwa.

Pasywne (wyświetlane) treści mieszane — Google: “including images, video, and audio” (tłumaczenie) „w tym obrazy, wideo i audio” — “doesn’t interact with the rest of the page.” (tłumaczenie) „nie wchodzą w interakcję z resztą strony.” Przechwycony obraz może zostać zamieniony, ale nie może przejąć dokumentu. Dlatego historycznie przeglądarki ładowały go i tylko obniżały wskaźnik: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (tłumaczenie) „Do niedawna pasywne treści mieszane były ładowane we wszystkich przeglądarkach, ponieważ ich blokowanie zepsułoby wiele stron internetowych. To się teraz zaczyna zmieniać.” Kierunek zmian w przeglądarkach zmierza w stronę automatycznego uaktualniania zasobów pasywnych do HTTPS tam, gdzie to możliwe, i blokowania tych, których nie można uaktualnić, więc „pasywne = nieszkodliwe” nie jest już bezpiecznym założeniem, na którym można budować.

Wyjątki, których nie obejmuje podział aktywny/pasywny

Linia uaktualnialne/blokowalne ma kilka wyjątków, które nie podążają za ogólnym wzorem „obrazy uaktualniane, skrypty blokowane” powyżej — to przypadki, które w praktyce najczęściej sprawiają ludziom problemy:

• Żądania obrazów z włączonym CORS są wymuszanie odrzucane, a nie ulepszane. Zwykły <img src="http://…"> jest ulepszalny, ale żądanie obrazu z ustawionym crossorigin jest traktowane inaczej przez algorytm mieszanych treści i kończy się niepowodzeniem zamiast cichego ulepszenia.
• Kandydaci srcset i <picture> są blokowalni, a nie ulepszalni. Ten sam obraz, żądany przez mechanizm obrazów responsywnych zamiast zwykłego src, wpada do kategorii blokowalnych — nie zakładaj, że każde odwołanie do obrazu zachowuje się tak samo.
• Hosty z adresami IP są blokowane, a nie ulepszane, nawet dla w inny sposób ulepszalnego typu zasobu. Odwołanie takie jak http://203.0.113.5/logo.png nie otrzymuje automatycznego ulepszenia, które otrzymałby odpowiednik hostowany na domenie.
• Zagnieżdżone konteksty i pracownicy są w zakresie. Sprawdzanie mieszanych treści dotyczy również iframe oraz pracowników usługowych/współdzielonych, nie tylko głównego dokumentu — pracownik pobierający niezabezpieczony skrypt nadal stanowi mieszaną treść.
• Lokalne i pętlowe pochodzenie mają swoją własną niuans. localhost, adresy pętlowe i konteksty file:// są „potencjalnie zaufanymi pochodzeniami” zgodnie ze specyfikacją nawet bez TLS, więc prosta heurystyka HTTP-vs-HTTPS nie odwzorowuje się czysto na lokalne środowiska programistyczne.
• Niebezpieczne pobierania to pokrewna, ale oddzielna granica. Pobieranie zainicjowane z bezpiecznej strony przez http:// to realne ryzyko, ale podlega własnemu mechanizmowi bezpieczeństwa pobierania, a nie regułom mieszanych treści dla podzasobów w tej sekcji.
• Nawigacja HTTP na najwyższym poziomie nadal nie jest mieszaną treścią, w tym przypadek linku kotwicowego powyżej — to właściwość nawigacji, a nie ładowanego podzasobu, niezależnie od tego, ile z tych innych wyjątków ma zastosowanie.

Wykrywanie mieszanych treści — cały stos

Nie ma jednego przycisku, a każda warstwa poniżej odpowiada na inne pytanie — czysty wynik na jednej warstwie nie zwalnia z pozostałych. Diagnozuj pobrane źródło (co faktycznie odwołuje się w surowym HTML), stan renderowania/czasu wykonania (co przeglądarka żąda po przeanalizowaniu strony i uruchomieniu skryptów) oraz rzeczywiste sesje użytkowników (co dzieje się dla odwiedzającego za banerem zgody, przekierowaniem geograficznym, ścianą logowania lub tagiem strony trzeciej, który uruchamia się tylko w określonych warunkach) osobno. Nakładaj te warstwy od „jednej strony” do „całej witryny”:

1. Konsola Chrome DevTools (stan renderowania/czasu wykonania). Załaduj stronę HTTPS i otwórz konsolę. Zablokowana aktywna mieszana treść rejestruje komunikat w stylu “Mixed Content: The page … was loaded over HTTPS, but requested an insecure … This request has been blocked; the content must be served over HTTPS.” (tłumaczenie) „Mieszana treść: strona … została załadowana przez HTTPS, ale zażądała niezabezpieczonego zasobu. To żądanie zostało zablokowane; treść musi być serwowana przez HTTPS.” Pasywna treść, która jest ładowana, rejestruje ostrzeżenie zamiast blokady. Panel Security (lub zakładka Issues) grupuje to per strona. Szybkie do sprawdzeń punktowych i potwierdzania konkretnej poprawki — ale traktuj dokładne brzmienie komunikatu, układ panelu, a nawet to, które typy zasobów są blokowane, jako zależne od przeglądarki i wersji; zostało to potwierdzone w Chrome według stanu na 2026-07 i powinieneś zweryfikować aktualne brzmienie na faktycznej przeglądarce/wersji, którą diagnozujesz, zamiast cytować je jako stały ciąg UI, i spodziewaj się, że Firefox, Safari i Edge będą się różnić.

2. Crawler witryny (pobrane źródło, na dużą skalę). DevTools jest per strona; crawl jest ogólnowitrzynowy. Ahrefs Site Audit i Screaming Frog oba flagują strony, które odwołują się do podzasobów http:// na stronie HTTPS — jedyny realistyczny sposób na znalezienie mieszanych treści wśród tysięcy URL-i. To główne narzędzie do audytu, ale nadal czyta źródło: czysty crawl nie dowodzi, że wyrenderowana strona lub prawdziwa sesja też są czyste — zapisuj, która przeglądarka/narzędzie/wersja wyprodukowała dany wynik, zamiast raportować jeden niekwalifikowany wynik pozytywny/negatywny.

3. Raportowanie naruszeń CSP (rzeczywiste sesje użytkowników). Możesz sprawić, by przeglądarki prawdziwych odwiedzających raportowały Ci mieszane treści, co pozwala wykryć zasoby, które ładują się tylko na niektórych stronach, dla niektórych użytkowników, w określonych stanach zgody lub z tagów stron trzecich, których nie kontrolujesz — warstwa, do której nie dociera ani crawl, ani pojedyncze sprawdzenie w DevTools. web.dev: “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (tłumaczenie) „Możesz użyć polityki bezpieczeństwa treści, aby zbierać raporty o mieszanych treściach w swojej witrynie. Aby włączyć tę funkcję, ustaw dyrektywę Content-Security-Policy-Report-Only, dodając ją jako nagłówek odpowiedzi dla swojej witryny.” Tryb Report-Only raportuje naruszenia bez egzekwowania polityki, więc możesz zmierzyć problem w produkcji, zanim włączysz blokowanie. (Mechanizm to nowoczesny nagłówek report-to / Reporting-Endpoints lub starszy report-uri. Zauważ, że to inna, ogólnego przeznaczenia polityka tylko do raportowania niż samo upgrade-insecure-requests — umieszczenie tej konkretnej dyrektywy w trybie tylko do raportowania nie działa, co omówiono poniżej.)

Użyj wszystkich trzech: DevTools do weryfikacji wyrenderowanej strony, crawlera do inwentaryzacji pobranego źródła, raportów CSP do wychwycenia długiego ogona rzeczywistych sesji, który ujawnia się tylko w prawdziwym środowisku. Jeden przechodzący crawl to dowód dotyczący źródła, a nie gwarancja, że każdy stan zgody, wariant ad-tech, gałąź personalizacji czy worker jest czysty.

Naprawa u źródła

Prawdziwa naprawa zaczyna się, zanim dotkniesz pojedynczego odwołania: zweryfikuj, że odpowiednik HTTPS faktycznie istnieje, ma ważny certyfikat i zwraca treści, których oczekujesz — nie zakładaj, że zamiana schematu jest bezpieczna tylko dlatego, że domena się rozwiązuje. Gdy to potwierdzisz, każde odwołanie do zasobu podrzędnego powinno rozwiązywać się przez HTTPS. Opcje poniżej są w przybliżonej kolejności preferencji, ale każda z nich nadal zależy od własności i kontekstu, a nie tylko od wpisywanego ciągu znaków:

• Bezwzględne adresy URL HTTPS — zmień http://cdn.example.com/app.js na https://cdn.example.com/app.js. Jawne i jednoznaczne; najbezpieczniejsza opcja domyślna, gdy nie masz pewności co do kontekstu serwowania opisanego poniżej.
• Ścieżki względne do katalogu głównego lub względne — w przypadku zasobów, które posiadasz w tej samej witrynie, /assets/app.js automatycznie dziedziczy schemat strony. Wytyczne Google dotyczące HTTPS: “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (tłumaczenie) „Upewnij się, że adresy URL wewnątrz witryny i zewnętrzne nie zależą od konkretnego protokołu. Używaj ścieżek względnych lub pomiń protokół, jak w //example.com/something.js.” Traktuj to jako warunkowe, a nie uniwersalne zalecenie: ma zastosowanie tylko wtedy, gdy potwierdzisz, że faktycznie posiadasz zasób (ścieżka względna do zasobu strony trzeciej nie ma sensu), że rzeczywisty bazowy adres URL strony rozwiązuje się tak, jak oczekujesz (tag <base>, ścieżka przez proxy lub kontekst osadzony/AMP mogą zmienić znaczenie „względny”), oraz że nic w dalszej części łańcucha nie odtwarza adresu URL w sposób, który ponownie wprowadza http:// — na przykład kod po stronie klienta budujący adres URL z window.location lub zapisanej wartości bezwzględnej.
• Adresy URL względne protokołu (//example.com/something.js) nadal działają, ale nie są preferowanym uniwersalnym rozwiązaniem — ogranicz je do tych samych kontroli własności/bazowego adresu URL co powyżej, a nie tylko z przyzwyczajenia. W sieci w pełni opartej na HTTPS jawny https:// jest zwykle jaśniejszy i pozwala uniknąć niespodzianek, jeśli plik zostanie kiedykolwiek otwarty z kontekstu innego niż HTTP; sięgaj po adresy względne protokołu tylko wtedy, gdy masz konkretny powód, aby nie kodować na sztywno schematu.

Na dużą skalę prawie nigdy nie edytujesz szablonów ręcznie, jeden po drugim — ale nie uruchamiaj też niechronionej zamiany ciągów znaków w bazie danych na produkcji. http://yourdomain → https://yourdomain wygląda jak prosta operacja znajdź i zamień, a w przypadku pól tekstowych często jest bezpieczna, ale treść CMS może być serializowana lub ustrukturyzowana (tablice serializowane w PHP, pliki JSON, dane edytora blokowego), gdzie naiwna zamiana podciągu uszkadza rekord zamiast go naprawić. Użyj narzędzi świadomych aplikacji, które rozumieją format serializacji, najpierw wykonaj kopię zapasową bazy danych i przetestuj zamianę, aby móc przejrzeć dotknięte wiersze przed zatwierdzeniem. Następnie napraw kilka plików szablonów/konfiguracji, które generują adresy URL; crawler i raporty CSP zajmą się pozostałymi przypadkami.

upgrade-insecure-requests: siatka bezpieczeństwa (i jej ograniczenia)

Proaktywnym zabezpieczeniem jest dyrektywa Content-Security-Policy. web.dev: “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (tłumaczenie) „Dyrektywa CSP upgrade-insecure-requests nakazuje przeglądarce uaktualnić niezabezpieczone adresy URL przed wysłaniem żądań sieciowych.” Ustaw nagłówek:

Content-Security-Policy: upgrade-insecure-requests

Według MDN dyrektywa traktuje wszystkie niezabezpieczone adresy witryny obsługiwane przez HTTP tak, jakby zastąpiono je bezpiecznymi adresami HTTPS. Konkretnie uaktualnia “requests to load resources (such as images, scripts, or fonts),” (tłumaczenie) „żądania ładowania zasobów, takich jak obrazy, skrypty lub czcionki”; “navigation requests (such as link targets) which are same-origin with the document,” (tłumaczenie) „żądania nawigacji, takie jak cele linków, pochodzące z tego samego źródła co dokument”; “navigation requests in nested browsing contexts, such as iframes,” (tłumaczenie) „żądania nawigacji w zagnieżdżonych kontekstach przeglądania, takich jak iframe’y”; oraz wysyłanie formularzy. Dowód potwierdzający to twierdzenie The upgrade-insecure-requests CSP directive rewrites insecure URLs as secure URLs before requests are made. Zakres: MDN documents the directive's rewriting behavior and limits; it does not guarantee that an HTTPS version of every resource exists. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 MDN: CSP upgrade-insecure-requests

Dwa szczegóły operacyjne mają znaczenie poza tym cytatem. Po pierwsze, aktualizacja zasobów podrzędnych nie jest ograniczona do żądań samego pochodzenia — to aktualizacja nawigacji jest ograniczona do samego pochodzenia, zgodnie z cytatem powyżej; zwykłe żądania zasobów podrzędnych są przepisywane również między pochodzeniami, więc skrypt hostowany na CDN lub czcionka innej firmy zostaną zaktualizowane, a nie tylko zasoby z tej samej witryny. Po drugie, przepisanie następuje przed sprawdzeniem przez przeglądarkę mieszanych treści i CSP, dlatego zasób, który w przeciwnym razie zostałby całkowicie zablokowany jako mieszana treść, może zostać załadowany czysto po aktualizacji — aktualizacja wyprzedza blokadę.

Trzy ograniczenia, których nie wolno ignorować:

• Nie aktualizuje nawigacji najwyższego poziomu innych firm. MDN: “However, top-level navigation requests whose target is a different origin will not be upgraded.” (tłumaczenie) „Jednak żądania nawigacji najwyższego poziomu, których celem jest inne pochodzenie, nie zostaną uaktualnione”. Z tego powodu dyrektywa wyraźnie nie zastępuje HSTS: nie zapewnia przejścia na HTTPS użytkownikom wchodzącym z odsyłaczy w witrynach zewnętrznych. (Więcej o tym podziale poniżej.)
• To siatka, a nie naprawa, i nie ma trybu awaryjnego. Jeśli zasób naprawdę nie jest dostępny przez HTTPS, zaktualizowane żądanie po prostu kończy się niepowodzeniem — nie wraca do oryginalnej wersji http://. Oczyszczenie źródła to nadal zadanie; dyrektywa obejmuje to, co przeoczyłeś, a nie to, co jest naprawdę zepsute.
• Tryb tylko do raportowania nie wykonuje aktualizacji — to operacja bez efektu. Umieszczenie upgrade-insecure-requests w nagłówku Content-Security-Policy-Report-Only jest ignorowane przez przeglądarkę: nic nie jest przepisywane i nic nie jest dla niego raportowane również. Jeśli chcesz uzyskać wgląd w to, na co aktualizacja wpłynęłaby przed jej wdrożeniem, uruchom osobną, ogólną politykę tylko do raportowania, która raportuje niedozwolone miejsca docelowe http:// (to samo podejście default-src https: tylko do raportowania używane do wykrywania powyżej) — nie uzyskasz tego wglądu, czyniąc upgrade-insecure-requests samą tylko do raportowania.

block-all-mixed-content — głównie historyczne

Istnieje towarzysząca dyrektywa, block-all-mixed-content, która — według MDN — “zapobiega ładowaniu jakichkolwiek zasobów przez HTTP, gdy strona używa HTTPS,” w tym “zarówno blokowalnych, jak i ulepszalnych treści mieszanych,” i dotyczy również iframe’ów. W praktyce została zastąpiona. MDN oznacza ją jako przestarzałą i “nieaktualną w specyfikacji,” zauważając: “Treści, które nie są blokowane, są teraz zawsze ulepszane do bezpiecznego połączenia, więc ta dyrektywa nie jest potrzebna.” Sięgaj po upgrade-insecure-requests; traktuj block-all-mixed-content jako przestarzałość, którą możesz odziedziczyć, a nie coś do wdrożenia na nowo. Jeśli już wysyłasz upgrade-insecure-requests, block-all-mixed-content nie ma nic do zrobienia dla ulepszonych żądań — przepisanie ulepszenia następuje najpierw, więc do czasu, gdy miałoby zostać uruchomione sprawdzenie blokowania, żądanie zostało już ulepszone (lub już się nie powiodło). To nie tylko przestarzałość; to redundancja wszędzie tam, gdzie UIR jest już wdrożone.

Dlaczego Twój CMS ciągle to wprowadza ponownie

Treści mieszane to nie jednorazowe sprzątanie — one powracają, ponieważ kilka systemów po cichu ponownie wstrzykuje adresy URL http://, gdy myślisz, że już skończyłeś:

• Baza treści. W WordPress, Drupal i większości systemów CMS, redaktorzy wklejają obrazy i osadzenia z bezwzględnymi adresami URL http:// bezpośrednio do treści wpisów. Te żyją w bazie danych, a nie w szablonie, więc poprawka na poziomie kodu nigdy ich nie dotyka — stąd wyszukiwanie i zamiana w bazie danych.
• Motywy i wtyczki. Motyw lub wtyczka, która na sztywno koduje adres URL zasobu http:// (czcionkę, skrypt, obraz tła), wprowadza ponownie treści mieszane na każdej stronie, którą renderuje, a aktualizacja wtyczki może je przywrócić po tym, jak je wyczyściłeś.
• Technologie reklamowe, analityka i tagi stron trzecich. Menedżery tagów, sieci reklamowe, widżety czatu i fragmenty analityczne ładują własne podzasoby — a jeśli tag dostawcy nadal wywołuje http://, to są treści mieszane, których nie możesz naprawić we własnym kodzie. To jest dokładnie ten długi ogon, do którego służą raporty CSP; trwałe rozwiązanie polega na naciskaniu na dostawcę, aby serwował przez HTTPS (lub porzuceniu tagu). Jeśli dostawca nie ma działającego punktu końcowego HTTPS, trwałe opcje są te same trzy: nakłonić ich do naprawy, zastąpić zależność lub ją porzucić — nie ma czwartej opcji, która utrzymywałaby niebezpieczną wersję w działaniu.
• Pracownicy usług i pamięci podręczne. Pracownik usługi może buforować odpowiedź (lub samo żądanie), która nadal wskazuje na http://, i będzie nadal serwować tę nieaktualną referencję przy powtórnych wizytach, nawet po naprawieniu źródła. Odtwórz podejrzewaną poprawkę w sesji incognito/bez pamięci podręcznej, zanim uznasz, że nie zadziałała, i upewnij się, że wdrożenie zmieniające adresy URL zasobów również zwiększa wersję pracownika usługi/pamięci podręcznej, aby nieaktualne wpisy zostały usunięte, a nie odtworzone.
• Na sztywno zakodowane http:// w starych treściach oraz szablonach e-mail/druku, które są ponownie używane.

Praktyczny wniosek: wbuduj wykrywanie w cykliczny audyt (crawler + raporty CSP), a nie w jednorazową listę kontrolną na dzień premiery.

Jak treści mieszane współdziałają z HSTS

Treści mieszane i HSTS rozwiązują sąsiednie, ale różne problemy, a ich mylenie jest częstym błędem:

• upgrade-insecure-requests naprawia podzasoby, o które prosi Twoja własna bezpieczna strona — ulepsza obrazy/skrypty/iframe’y, które strona pobiera.
• HSTS (Strict-Transport-Security) wymusza nawigację najwyższego poziomu do Twojej witryny na HTTPS — nawet pierwsze żądanie, zanim zadziała jakiekolwiek przekierowanie — i chroni przed atakami typu SSL-stripping. Google przedstawia HSTS jako sposób na “uniknięcie kosztu przekierowania 301” i na “pokonanie ataków takich jak SSL Stripping.”

Nie zastępują się nawzajem. Jak wyjaśnia MDN, upgrade-insecure-requests „nie zapewni, że użytkownicy odwiedzający Twoją witrynę za pośrednictwem linków na stronach osób trzecich zostaną przeniesieni na HTTPS dla nawigacji najwyższego poziomu, a zatem nie zastępuje nagłówka Strict-Transport-Security (HSTS).” W pełni zabezpieczona konfiguracja wykorzystuje oba: upgrade-insecure-requests (lub czyste adresy URL źródeł), aby bezpieczna strona nie zawierała niezabezpieczonych zasobów, oraz HSTS, aby nikt nie docierał do witryny przez HTTP w pierwszej kolejności. I zwykłe zastrzeżenie dotyczące HSTS nadal obowiązuje — Google: „Nie włączaj HSTS, dopóki nie będziesz pewien, że działanie Twojej witryny jest wystarczająco solidne, aby uniknąć kiedykolwiek wdrażania HTTPS z błędami walidacji certyfikatu,” a preload jest bliski drzwiom jednokierunkowym.

Czy mieszana treść szkodzi SEO bezpośrednio?

Zacznij od bezpośrednich skutków, ponieważ to one są tym, co faktycznie kontrolujesz: mieszana treść jest przede wszystkim problemem bezpieczeństwa i funkcjonalności. Zablokowana aktywna mieszana treść całkowicie psuje renderowanie i interaktywność — brakujący arkusz stylów lub skrypt to realna regresja, niezależnie od tego, co wyszukiwarka sobie o tym pomyśli. To wystarczający powód, aby naprawić to, zanim w ogóle pomyślisz o rankingach.

Konsekwencje SEO są realne, ale warunkowe, nie bezpośrednie ani gwarantowane. Obecne oficjalne wytyczne Google nie ustanawiają naprawiania mieszanej treści jako bezpośredniego wzmocnienia rankingu — sam sygnał rankingowy HTTPS opiera się na schemacie (czy URL zaczyna się od https://), a nie na kontroli czystości podzasobów, więc pojedynczy niezabezpieczony obraz sam w sobie nie kosztuje Cię „sygnału HTTPS”. Ale skutki pośrednie mogą się nadal pojawić w zależności od tego, co faktycznie jest zepsute: jeśli Googlebot renderuje stronę, której CSS lub JS został zablokowany jako mieszana treść, może zaindeksować zepsutą lub niekompletną wersję; obniżony wskaźnik bezpieczeństwa może zaszkodzić zaufaniu użytkowników, zaangażowaniu i konwersjom nawet bez żadnej zmiany w rankingu; a ogólna preferencja Google dla kanonicznych HTTPS jest sama w sobie warunkowa — nieprawidłowe certyfikaty, niezabezpieczone zależności, przekierowania HTTPS-na-HTTP lub sprzeczne sygnały kanoniczne gdzie indziej na stronie mogą zmienić to, który URL zostanie wybrany, niezależnie od mieszanej treści. Traktuj efekty renderowania, indeksowania, kanonizacji i analityki jako rzeczy do zweryfikowania na własnych stronach, a nie uniwersalne wyniki do obiecywania — i napraw mieszaną treść przede wszystkim ze względów bezpieczeństwa i funkcjonalności.

To znajduje się w szerszym temacie HTTPS dla SEO, który obejmuje plan migracji, wagę sygnału rankingowego i HSTS w pełni; jeśli debugujesz również sam certyfikat (błędy łańcucha, wygaśnięcie, DV/OV/EV), to jest to poboczny szczegółowy przewodnik.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Treść mieszana = strona HTTPS ładująca zasób podrzędny przez HTTP. Chodzi o zasoby, które strona ładuje, a nie linki, które zawiera — odnośnik do strony HTTP (lub jakakolwiek nawigacja najwyższego poziomu przez HTTP) nie jest treścią mieszaną, podobnie jak niezabezpieczone pobieranie (powiązana, ale odrębna granica).
• Obecna taksonomia to ulepszalne/blokowalne; aktywne/pasywne to starsze, ale wciąż użyteczne ujęcie zasięgu wybuchu. Aktywne (skrypty, arkusze stylów, iframe, XMLHttpRequest/fetch — wszystko, co przeglądarka wykonuje) jest blokowane, ponieważ zmodyfikowany skrypt może przepisać stronę; to regresja z dnia premiery, napraw to najpierw. Pasywne (obrazy, audio, wideo) historycznie ładowane z obniżoną kłódką, a obecnie coraz częściej automatycznie ulepszane lub blokowane. Wyjątki od ogólnego wzorca: żądania obrazów z włączonym CORS są wymuszane jako nieudane, a nie ulepszane, kandydaci srcset/<picture> są blokowalni (nie ulepszalni), podobnie jak zwykły img src, hosty z adresami IP są blokowane, a nie ulepszane, a zagnieżdżone konteksty/pracownicy i lokalne/pętlowe pochodzenie mają swoje własne niuanse.
• Wykrywaj na trzech warstwach, nie jednej: pobrane źródło (crawler taki jak Ahrefs Site Audit lub Screaming Frog, w całym serwisie), stan renderowany/czasu wykonania (konsola Chrome DevTools/panel Security, na stronę — dokładne sformułowanie zależy od przeglądarki/wersji, potwierdzone dla Chrome według stanu na 2026-07) oraz rzeczywiste sesje użytkowników (raporty naruszeń Content-Security-Policy-Report-Only, długa ogon produkcyjny obejmujący tagi stron trzecich i zasoby objęte zgodą). Czysty wynik na jednej warstwie nie zwalnia z pozostałych.
• Napraw u źródła, po zweryfikowaniu, że odpowiednik HTTPS faktycznie działa: wskaż każdy zasób podrzędny na https://; ścieżki względne/względne protokołu są w porządku tylko po zweryfikowaniu własności i rzeczywistego zachowania podstawowego adresu URL strony, a nie domyślnie. Na dużą skalę wykonaj kopię zapasową bazy danych i przetestuj każdą zamianę — naiwna zamiana ciągów może uszkodzić serializowane/ustrukturyzowane dane CMS — a następnie napraw pozostałe pliki szablonów/konfiguracji. Uważaj na pracowników usług/pamięci podręczne odtwarzające nieaktualne odwołania http:// po naprawie źródła.
• upgrade-insecure-requests (nagłówek CSP) przepisuje żądania zasobów podrzędnych http:// w zakresie — w tym między domenami — na https:// przed ich wysłaniem i przed uruchomieniem kontroli treści mieszanej/CSP, co stanowi siatkę bezpieczeństwa bez rezerwowego HTTP, jeśli ulepszenie się nie powiedzie. Nie ulepsza nawigacji najwyższego poziomu do domen trzecich, więc nie zastępuje HSTS, a umieszczenie samej dyrektywy w trybie tylko-raportowanie jest bezczynne — monitoruj za pomocą osobnej polityki tylko-raportowanie zamiast tego.
• block-all-mixed-content jest przestarzała/nieaktualna i zbędna, gdy upgrade-insecure-requests jest wdrożone (ulepszenie działa najpierw, więc blokowanie-wszystkiego nie ma nic do zablokowania).
• To się powtarza, ponieważ baza danych CMS, motywy/wtyczki, pracownicy usług/pamięci podręczne oraz tagi reklam/analityczne wciąż wprowadzają adresy URL http:// — audytuj regularnie, nie jednorazowo.
• Wpływ na SEO jest warunkowy, nie bezpośredni: obecne wytyczne Google nie ustanawiają bezpośredniego wzrostu rankingowego z naprawy treści mieszanej, a sygnał HTTPS jest oparty na schemacie. Ale zablokowane aktywne zasoby mogą sprawić, że Googlebot wyrenderuje/zaindeksuje zepsutą stronę, obniżenie kłódki kosztuje zaufanie, a preferencja Google dotycząca kanonicznego HTTPS jest sama w sobie warunkowa, np. od ważności certyfikatu i sprzecznych sygnałów — nie jest gwarancją związaną konkretnie z treścią mieszaną.

Oficjalna dokumentacja

Dokumentacja źródłowa od Google oraz zespołów przeglądarek i standardów.

Google / web.dev

• Co to jest treść mieszana? — definicja oraz podział na treść aktywną i pasywną wraz z zachowaniem przeglądarek.
• Naprawianie treści mieszanej — znajdowanie problemu, poprawianie adresów podzasobów, upgrade-insecure-requests i raportowanie CSP.
• Włącz HTTPS na swoich serwerach — względne i zależne od protokołu adresy URL, uwaga o elementach HTTP <iframe> oraz wskazówki dotyczące HSTS.
• Zapobieganie treści mieszanej jako część wytycznych Google dotyczących HTTPS — szerszy poradnik migracji witryny, w którym mieszczą się te poprawki.

MDN / standardy

• CSP: upgrade-insecure-requests — co uaktualnia, czego nie uaktualnia i dlaczego nie zastępuje HSTS.
• CSP: block-all-mixed-content — przestarzała dyrektywa blokująca.
• MDN — treść mieszana — opis zachowania przeglądarek wobec treści blokowalnej i możliwej do uaktualnienia.
• Polityka bezpieczeństwa treści (CSP) — nagłówek obejmujący te dyrektywy, w tym raportowanie.

Cytaty ze źródła

Definicje na piśmie z Google web.dev i dokumentów standardów MDN. Każdy link jest linkiem bezpośrednim, który przeskakuje do cytowanego fragmentu, jeśli platforma to obsługuje.

Google / web.dev — czym jest mieszana treść

• “A page has mixed content when its initial HTML is loaded over a secure HTTPS connection, but other resources (such as images, videos, stylesheets, and scripts) are loaded over an insecure HTTP connection.” (tłumaczenie) „Strona ma mieszaną treść, gdy jej początkowy HTML jest ładowany przez bezpieczne połączenie HTTPS, ale inne zasoby (takie jak obrazy, filmy, arkusze stylów i skrypty) są ładowane przez niezabezpieczone połączenie HTTP.” Źródło
• “Active mixed content poses a greater threat than passive mixed content.” (tłumaczenie) „Aktywna mieszana treść stanowi większe zagrożenie niż pasywna mieszana treść.” Źródło
• Aktywna mieszana treść “includes scripts, stylesheets, iframes, and any other code the browser can download and execute,” (tłumaczenie) „obejmuje skrypty, arkusze stylów, iframe’y i każdy inny kod, który przeglądarka może pobrać i wykonać”, a “Most browsers already block this type of content by default to protect users.” (tłumaczenie) „Większość przeglądarek już domyślnie blokuje ten typ treści, aby chronić użytkowników.” Źródło
• Pasywna mieszana treść, “including images, video, and audio,” (tłumaczenie) „obejmująca obrazy, wideo i audio”, “doesn’t interact with the rest of the page.” (tłumaczenie) „nie wchodzi w interakcje z resztą strony”. Oraz: “Until recently, passive mixed content was loaded in all browsers, because blocking it would have broken many websites. This is now beginning to change.” (tłumaczenie) „Do niedawna pasywna mieszana treść była ładowana we wszystkich przeglądarkach, ponieważ jej zablokowanie zepsułoby wiele witryn. To się teraz zaczyna zmieniać.” Źródło

Google / web.dev — wykrywanie i naprawa

• “You can use content security policy to collect reports of mixed content on your site. To enable this feature, set the Content-Security-Policy-Report-Only directive by adding it as a response header for your site.” (tłumaczenie) „Możesz użyć polityki bezpieczeństwa treści, aby zbierać raporty o mieszanej treści na swojej stronie. Aby włączyć tę funkcję, ustaw dyrektywę Content-Security-Policy-Report-Only, dodając ją jako nagłówek odpowiedzi dla swojej witryny.” Źródło
• “The upgrade-insecure-requests CSP directive instructs the browser to upgrade insecure URLs before making network requests.” (tłumaczenie) „Dyrektywa CSP upgrade-insecure-requests instruuje przeglądarkę, aby uaktualniła niezabezpieczone adresy URL przed wykonaniem żądań sieciowych.” Źródło
• “Make sure intrasite URLs and external URLs don’t depend on a specific protocol. Use relative paths or leave out the protocol as in //example.com/something.js.” (tłumaczenie) „Upewnij się, że adresy URL wewnątrz witryny i zewnętrzne nie zależą od konkretnego protokołu. Używaj ścieżek względnych lub pomiń protokół, jak w //example.com/something.js.” Źródło

MDN — upgrade-insecure-requests i jego ograniczenia

• “The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site’s insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).” (tłumaczenie) „Dyrektywa upgrade-insecure-requests w HTTP Content-Security-Policy (CSP) instruuje agentów użytkownika, aby traktowali wszystkie niezabezpieczone adresy URL witryny (te obsługiwane przez HTTP) tak, jakby zostały zastąpione bezpiecznymi adresami URL (tymi obsługiwanymi przez HTTPS).” Source
• “However, top-level navigation requests whose target is a different origin will not be upgraded.” (tłumaczenie) „Jednak żądania nawigacji najwyższego poziomu, których celem jest inne pochodzenie, nie zostaną uaktualnione.” Source
• “The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the Strict-Transport-Security (HSTS) header.” (tłumaczenie) „Dyrektywa upgrade-insecure-requests nie zapewni, że użytkownicy odwiedzający Twoją witrynę przez linki na stronach trzecich zostaną uaktualnieni do HTTPS dla nawigacji najwyższego poziomu, a zatem nie zastępuje nagłówka Strict-Transport-Security (HSTS).” Source

MDN — block-all-mixed-content jest przestarzałe

• “The HTTP Content-Security-Policy (CSP) block-all-mixed-content directive prevents loading any assets over HTTP when the page uses HTTPS.” (tłumaczenie) „Dyrektywa block-all-mixed-content w HTTP Content-Security-Policy (CSP) zapobiega ładowaniu jakichkolwiek zasobów przez HTTP, gdy strona używa HTTPS.” Jest ona jednak oznaczona jako przestarzała i “obsolete in the specification,” (tłumaczenie) „nieaktualna w specyfikacji”, ponieważ “Content that isn’t blocked is now always upgraded to a secure connection, so this directive is not needed.” (tłumaczenie) „Treść, która nie jest blokowana, jest teraz zawsze uaktualniana do bezpiecznego połączenia, więc ta dyrektywa nie jest potrzebna.” Source

Lista kontrolna treści mieszanych

Uruchom to podczas i po migracji HTTP→HTTPS, a następnie cyklicznie:

Znajdź to

• Załadowano kluczowe szablony (strona główna, produkt, artykuł, kasa) przez HTTPS z otwartą konsolą Chrome DevTools i odnotowano każdy komunikat „Mixed Content”.
• Przeprowadzono pełne przeszukanie (Ahrefs Site Audit lub Screaming Frog) i pobrano listę stron odwołujących się do zasobów podrzędnych http://.
• Ustawiono Content-Security-Policy-Report-Only z punktem końcowym raportowania, aby wychwycić długi ogon produkcyjny (per użytkownik, per strona i tagi stron trzecich).

Napraw to (aktywne najpierw)

• Wszystkie aktywne odwołania naprawione: <script>, <link rel="stylesheet">, <iframe>, fetch/XMLHttpRequest, czcionki — te są blokowane, więc psują stronę.
• Wszystkie pasywne odwołania naprawione: <img>, <audio>, <video> oraz ich adresy URL <source>/poster.
• Zastąpienie w bazie danych CMS (http://yourdomain → https://yourdomain) dla wklejonej treści — z kopią zapasową, próbą suchą z narzędziami świadomymi aplikacji, a nie surowym zastępowaniem ciągów w polach serializowanych/strukturalnych.
• Znaleziono i załatano zakodowane na stałe adresy URL zasobów http:// w motywie/wtyczce.
• Wpisy service workera/pamięci podręcznej odtworzone w sesji bez pamięci podręcznej, a wersja pamięci podręcznej/service workera zwiększona, aby nie odtwarzać nieaktualnych odwołań http://.
• Tagi stron trzecich (reklamy, analityka, czat, osadzenia) potwierdzone jako ładowane przez HTTPS — albo dostawca wypchnął / tag usunięto.

Zabezpiecz i zweryfikuj

• Ustawiono nagłówek Content-Security-Policy: upgrade-insecure-requests jako siatkę bezpieczeństwa (ze zrozumieniem, że nie zastępuje HSTS).
• Ponownie przeszukano i ponownie sprawdzono konsolę — zero zablokowanych aktywnych zasobów, czysta kłódka na sprawdzonych stronach.
• Dodano wykrywanie treści mieszanych do cyklicznego audytu, nie tylko do listy kontrolnej uruchomienia (aktualizacje wtyczek i nowa treść wprowadzają je ponownie).

Jakiej poprawki wymaga ten przypadek treści mieszanych?

Pracuj w dół od objawu.

Czy niebezpieczny element to zasób ładowany przez stronę, czy link, który strona zawiera?

• Link (<a href="http://…">) → nie jest to mieszana treść. Zostaw go (opcjonalnie wskaż na HTTPS dla czystości danych referencyjnych). Zatrzymaj się tutaj.
• Załadowany zasób (skrypt, styl, iframe, obraz, czcionka, multimedia, fetch) → kontynuuj.

Czy zasób jest dostępny przez HTTPS?

• Tak, i zweryfikowałeś to (ważny certyfikat, zwraca oczekiwaną treść) → zmień odniesienie na https:// (bezpieczna domyślna opcja) lub względną / protokołowo-względną ścieżkę tylko jeśli jesteś właścicielem zasobu i sprawdziłeś zachowanie adresu bazowego strony. To jest prawdziwa poprawka. Gotowe.
• Nie / niepewny → czy to pierwsza strona (twój własny zasób)?
  • Pierwsza strona → udostępnij go przez HTTPS (to twój serwer; możesz). Następnie popraw odniesienie jak wyżej.
  • Strona trzecia (tag dostawcy, reklama, osadzenie) → poproś dostawcę o punkt końcowy HTTPS; jeśli go nie ma, zastąp lub usuń tag. upgrade-insecure-requests spróbuje go ulepszyć, ale jeśli dostawca nie ma wersji HTTPS, ulepszone żądanie po prostu się nie powiedzie.

Czy to aktywne czy pasywne?

• Aktywne (skrypt / arkusz stylów / iframe / fetch / czcionka) → najwyższy priorytet — jest zablokowane, więc strona jest funkcjonalnie uszkodzona, dopóki tego nie naprawisz.
• Pasywne (obraz / audio / wideo) → też to napraw, ale to mniejsza pilność (obniżenie kłódki / możliwe przyszłe blokowanie, nie natychmiastowe uszkodzenie).

Czy chcesz siatkę bezpieczeństwa na to, co przeoczyłeś?

• Ustaw Content-Security-Policy: upgrade-insecure-requests. Pamiętaj: siatka, nie substytut — i nie obejmuje nawigacji najwyższego poziomu stron trzecich, więc nie jest zamiennikiem HSTS.

Czy musisz również wymusić HTTPS na stronie najwyższego poziomu dla pierwszych / zewnętrznych odsyłaczy?

• To HSTS, osobny mechanizm. Dodaj Strict-Transport-Security — ale tylko wtedy, gdy twoja operacja certyfikatów jest niezawodna, ponieważ HSTS (zwłaszcza preload) jest bliski drzwiom jednokierunkowym.

Modele mentalne

1. Zasoby, nie linki. Mieszana treść dotyczy tego, co bezpieczna strona ładuje, nigdy tego, do czego linkuje. Jeśli nie możesz zdecydować, czy coś się liczy, zapytaj: czy przeglądarka pobiera to, aby zbudować bieżącą stronę? Tak → możliwa mieszana treść. To tylko prowadzi mnie do innej strony → to nie jest mieszana treść.

2. Triage według tego, co robi przeglądarka, nie według abstrakcyjnej powagi. Aktywne (skrypty, style, iframe) jest zablokowane → to błąd funkcjonalny, napraw najpierw. Pasywne (obrazy, multimedia) jest ostrzegane/ulepszane → napraw następnie. Zachowanie przeglądarki jest twoją kolejką priorytetów.

3. Wykrywanie to lejek: weryfikuj → inwentaryzuj → złap ogon. Konsola DevTools (jedna strona, dokładnie), crawler (cała witryna, większość), raporty CSP (produkcja, strony trzecie, długi ogon per użytkownik). Żadne pojedyncze narzędzie nie widzi wszystkich trzech.

4. Napraw źródło; złap resztę. Wyczyść rzeczywiste adresy URL — bazę danych, szablony, tagi. Następnie dodaj upgrade-insecure-requests jako zabezpieczenie na to, co się prześlizgnie. Dyrektywa jest ubezpieczeniem, nie naprawą.

5. Dwa różne zadania “wymuszania HTTPS”, dwa różne narzędzia. upgrade-insecure-requests ulepsza podzasoby, które żąda twoja bezpieczna strona. HSTS wymusza nawigację najwyższego poziomu do twojej witryny na HTTPS. Nie nakładają się i jedno nigdy nie zastępuje drugiego — wzmocniona witryna używa obu.

6. To powtarzający się audyt, nie jednorazowe zadanie. Baza danych CMS, aktualizacje wtyczek/motywów i tagi stron trzecich ciągle wprowadzają http://. Traktuj wykrywanie jako zaplanowane przeszukiwanie, inaczej po cichu wróci.

Antywzorce mieszanej treści

Błędy, które pozostawiają niebezpieczną treść aktywną — lub maskują ją zamiast naprawić.

• Traktowanie upgrade-insecure-requests jako rozwiązania. To sieć. Jeśli zasób nie ma wersji HTTPS, ulepszone żądanie kończy się niepowodzeniem, a Ty ukrywasz zepsutą zależność zamiast ją rozwiązać. Wyczyść adresy URL źródła; użyj dyrektywy dla ogona.
• Zakładanie, że wdrożenie kodu wyczyściło bazę danych. W CMS większość adresów URL obrazów i osadzeń http:// znajduje się w wierszach treści, a nie w szablonach. Poprawka szablonu pozostawia każdy stary post w mieszanym stanie. Uruchom wyszukiwanie i zamianę w bazie danych.
• Depriorytetyzacja aktywnej mieszanej treści, bo „to tylko ostrzeżenie”. To nie jest — aktywna jest blokowana. Zablokowany arkusz stylów lub skrypt to funkcjonalna awaria, a nie kosmetyczne upomnienie.
• Sprawdzanie strony głównej i uznawanie zadania za skończone. Mieszana treść ukrywa się na stronach produktów, starych postach na blogu i ścieżkach, które odwiedzają tylko niektórzy użytkownicy. Przecrawluj całą witrynę i użyj raportowania CSP dla tego, czego crawl nie może osiągnąć.
• Ignorowanie tagów stron trzecich. Dostawca reklam, analityki lub czatu, który nadal wywołuje http://, to mieszana treść, której nie możesz naprawić we własnym repozytorium. Ściganie jej w swoim kodzie na zawsze to zmarnowany wysiłek — naciskaj na dostawcę lub usuń tag.
• Używanie block-all-mixed-content w nowej kompilacji. Jest przestarzałe i nieaktualne. Sięgnij po upgrade-insecure-requests.
• Mylenie upgrade-insecure-requests z HSTS. Jedno ulepsza podzasoby; drugie wymusza HTTPS na poziomie najwyższym i broni przed strippingiem SSL. Wdrożenie jednego i założenie, że pokryłeś drugie, pozostawia realną lukę.
• Pomijanie wykrywania w cyklicznym audycie. Naprawienie raz i nigdy więcej nie sprawdzanie gwarantuje, że aktualizacja wtyczki lub wklejony obraz http:// przywróci problem niezauważenie.

Mieszana treść — ściągawka

Aktywna vs. pasywna

Stos wykrywania

Dyrektywy CSP

Nie-myl-tych

Jednowierszowa naprawa (CMS): wyszukiwanie i zamiana w bazie danych http://yourdomain → https://yourdomain, potem załataj szablony/wtyczki, potem ustaw upgrade-insecure-requests.

Znajdź mieszaną treść — fragmenty

1. Przecrawluj jedną stronę z wiersza poleceń

Pobierz stronę i oznacz wszelkie niebezpieczne podzasoby src/href pozostawione w HTML.

macOS / Linux

# Flag insecure script/img/link/iframe/source references on a single URL
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

To widzi tylko surowy HTML — zasoby wstrzykiwane przez JavaScript nie pojawią się, dlatego właśnie używasz też DevTools i prawdziwego crawlera.

2. Konsola Chrome DevTools — lista niezabezpieczonych zasobów na wyrenderowanej stronie

Wklej do konsoli na stronie HTTPS, aby wychwycić nawet odniesienia wstawiane przez JS:

// Every element with an http:// resource attribute in the live DOM
[...document.querySelectorAll('[src],[href],[srcset],[data-src]')]
  .filter(el => /^http:\/\//.test(
    el.src || el.href || el.getAttribute('srcset') || el.getAttribute('data-src') || ''
  ))
  .map(el => ({ tag: el.tagName, url: el.src || el.href }));

Przeglądarka sama rejestruje komunikat, że mieszana treść została zablokowana i musi być udostępniana przez HTTPS — przeczytaj go najpierw.

3. Zakładka — zrzut konsoli jednym kliknięciem

Zapisz jako zakładkę; kliknij ją na dowolnej stronie HTTPS, aby zalogować w konsoli jej odniesienia http://:

javascript:(()=>{const h=[...document.querySelectorAll('[src],[href]')].filter(e=>/^http:\/\//.test(e.src||e.href)).map(e=>e.src||e.href);console.log('%cMixed content candidates:','font-weight:bold',h.length);h.forEach(u=>console.log(u));})();

4. Włącz raportowanie CSP (wykrywanie w produkcji)

Dodaj nagłówek tylko do raportów, aby przeglądarki prawdziwych odwiedzających informowały Cię o naruszeniach — w tym o tagach zewnętrznych i stronach, których nie obejmuje crawl:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-report-endpoint

Tryb tylko do raportów raportuje bez egzekwowania, więc możesz bezpiecznie ocenić skalę problemu przed włączeniem upgrade-insecure-requests lub egzekwowania. (Nowoczesny odpowiednik używa report-to z nagłówkiem Reporting-Endpoints.)

5. Nagłówek bezpieczeństwa (po naprawieniu źródła)

Content-Security-Policy: upgrade-insecure-requests

Pamiętaj, że nie aktualizuje nawigacji najwyższego poziomu stron trzecich i nie jest zamiennikiem HSTS.

Stała procedura audytu mieszanej treści

Uruchamiaj ją po wdrożeniu HTTPS, wydaniach CMS lub motywów, zmianach w menedżerze tagów oraz regularnie w przypadku witryn o często zmieniającej się treści.

1. Przeskanuj strony HTTPS w trybie surowym i wyrenderowanym. Wyeksportuj niezabezpieczone adresy URL z src, srcset, arkuszy stylów, iframe, multimediów i żądań fetch/XHR; zwykłe linki kotwicowe HTTP nie są mieszaną treścią.
2. Zbierz dowody z przeglądarki. Przejrzyj DevTools na reprezentatywnych szablonach i użyj Content-Security-Policy-Report-Only, aby wychwycić naruszenia wywołane przez prawdziwych odwiedzających i tagi zewnętrzne.
3. Sklasyfikuj każde znalezisko. Oznacz je jako aktywne lub pasywne, pierwszej lub trzeciej strony, statyczne lub wstrzykiwane przez JavaScript, i zidentyfikuj szablon, pole bazy danych, wtyczkę, tag lub dostawcę, który jest właścicielem źródła.
4. Napraw odniesienie źródłowe. Wskaż działający zasób HTTPS lub bezpieczny względny adres URL. Nie zakładaj, że zmiana http:// na https:// wystarczy; zweryfikuj, czy miejsce docelowe faktycznie obsługuje TLS.
5. Użyj CSP jako siatki bezpieczeństwa. Dodaj upgrade-insecure-requests dopiero po przejrzeniu znalezisk. Może zmniejszyć ekspozycję, ale nie naprawia rekordu CMS ani nie zastępuje HSTS.
6. Przeskanuj i wyrenderuj ponownie. Błędy aktywnej mieszanej treści powinny wynosić zero na testowanych szablonach; zasoby pasywne również powinny rozwiązywać się przez HTTPS bez fallbacku.
7. Zapobiegaj nawrotom. Popraw źródłowy szablon lub przepływ pracy edytora, zachowaj zbieranie tylko do raportów tam, gdzie to właściwe, i przypisz nowe naruszenia właścicielowi systemu.

Objaw → prawdopodobna przyczyna → naprawa

Testy wydania dotyczące treści mieszanej

Test 1: przegląd wyrenderowanych szablonów

• Cel: Wykrycie aktywnych i pasywnych zasobów, których surowy HTML nie ujawnia.
• Metoda: Wyrenderuj reprezentatywny adres URL z każdego szablonu i stanu interakcji; sprawdź dane wyjściowe konsoli i sieci pod kątem niebezpiecznych lub zablokowanych żądań.
• Oczekiwany wynik: Żaden podzasób nie jest żądany przez HTTP i żadna aktywna treść nie jest blokowana.
• Wyzwalacz błędu: Jakiekolwiek ostrzeżenie o treści mieszanej, błąd automatycznego uaktualnienia lub brak układu/funkcji spowodowany zablokowanym zasobem.
• Następne działanie: Prześledź żądanie do jego szablonu, tagu, wtyczki lub zapisanego pola; napraw źródło i uruchom ponownie przegląd.

Test 2: porównanie źródła i CSP

• Cel: Wykrycie naruszeń wprowadzanych tylko dla prawdziwych odwiedzających lub przez strony trzecie.
• Metoda: Porównaj wyniki indeksowania z Content-Security-Policy-Report-Only zdarzeniami, pogrupowanymi według zablokowanego adresu URL, szablonu strony, dyrektywy i właściciela.
• Oczekiwany wynik: Brak niewyjaśnionych naruszeń występujących tylko w produkcji; znany szum jest udokumentowany i wykluczony wąsko.
• Wyzwalacz błędu: Powtarzalne naruszenie nieobecne w indeksowaniu lub nieposiadane źródło strony trzeciej.
• Następne działanie: Odtwórz stan odwiedzającego i popraw lub usuń integrację wstrzykującą.

Test 3: test nawrotu po publikacji

• Cel: Weryfikacja, że CMS nie generuje już nowych niebezpiecznych odwołań.
• Metoda: Opublikuj element testowy przez normalny przepływ redakcyjny, a następnie przeszukaj i wyrenderuj go za pomocą tych samych kontroli, które są używane w produkcji.
• Oczekiwany wynik: Wygenerowany znacznik i załadowane zasoby używają prawidłowych adresów URL HTTPS.
• Wyzwalacz błędu: Nowa strona odtwarza odwołanie HTTP wcześniej usunięte ze starszych treści.
• Następne działanie: Popraw domyślny edytor, szablon, wtyczkę lub transformację treści przed kontynuowaniem wydania.

Zasoby warte Twojego czasu

Moje wystąpienia

• Lepiej dmuchać na zimne z HTTPS — SMX East 2016 (SlideShare) — moje szczegółowe omówienie TLS, typowych błędów wdrażania HTTPS oraz pułapek migracji, które w pierwszej kolejności powodują treści mieszane. (Stałe zastrzeżenie: to moje rozumienie tych systemów, a statystyki adopcji w nim zawarte pochodzą z 2016 r.)

Moje powiązane artykuły

• Przewodnik dla początkujących po technicznym SEO — gdzie HTTPS i treści mieszane wpisują się w szerszy obraz techniczny.

Z branży

• Co to jest treść mieszana? (web.dev / Google) — kanoniczna definicja oraz podział na aktywną i pasywną.
• Naprawianie treści mieszanej (web.dev / Google) — krok po kroku: znajdowanie jej, poprawianie adresów URL podzasobów, upgrade-insecure-requests i raportowanie CSP.
• MDN — upgrade-insecure-requests — dokładnie co aktualizuje, czego nie aktualizuje i dlaczego nie zastępuje HSTS.
• MDN — block-all-mixed-content — przestarzała dyrektywa blokująca, na wypadek gdybyś ją odziedziczył.
• MDN — Treść mieszana — referencja dotycząca zachowania przeglądarek dla zasobów blokowalnych i aktualizowalnych.
• Włącz HTTPS na swoich serwerach (web.dev / Google) — względne adresy URL i adresy URL zależne od protokołu oraz otaczające wskazówki dotyczące konfiguracji HTTPS.

Statystyki, które warto cytować

• Aktywna treść mieszana jest domyślnie blokowana. Google: “Most browsers already block this type of content by default to protect users.” (tłumaczenie) „Większość przeglądarek już domyślnie blokuje ten typ treści, aby chronić użytkowników” — powód, dla którego aktywna treść mieszana to awaria funkcjonalna, a nie ostrzeżenie. Źródło
• Aktywna treść mieszana stanowi większe zagrożenie. Własny ranking Google tych dwóch poziomów: “Active mixed content poses a greater threat than passive mixed content.” (tłumaczenie) „Aktywna treść mieszana stanowi większe zagrożenie niż pasywna treść mieszana” — właściwie ustala kolejność triażu. Źródło
• Pasywna treść mieszana nie jest już bezpiecznie „dozwolona”. Google: “Until recently, passive mixed content was loaded in all browsers … This is now beginning to change.” (tłumaczenie) „Do niedawna pasywna treść mieszana była ładowana we wszystkich przeglądarkach… Teraz zaczyna się to zmieniać” — założenie, że „obrazy są nieszkodliwe”, wygasa. Źródło
• upgrade-insecure-requests nie zastępuje HSTS. MDN stwierdza to wprost: “does not replace the Strict-Transport-Security (HSTS) header.” (tłumaczenie) „nie zastępuje nagłówka Strict-Transport-Security (HSTS)” — te dwa mechanizmy rozwiązują różne połowy problemu. Źródło
• ~89 % sieci jest na HTTPS (W3Techs, 2026; potwierdź aktualną liczbę), co jest dokładnie powodem, dla którego pozostałe podzasoby http:// na inaczej bezpiecznej stronie są teraz typowym trybem awarii — strony są na HTTPS; ładunek zostaje w tyle. Kontekst przez centrum HTTPS.

Sprawdź się: Treść mieszana

Pięć szybkich pytań o treści mieszanej. Wybierz odpowiedź na każde, a następnie sprawdź.

Dziennik zmian