Czym jest mixed content?

Mixed content występuje, gdy strona internetowa ładowana przez bezpieczne połączenie HTTPS zawiera zasoby (obrazy, skrypty, arkusze stylów, czcionki, iframe), które są ładowane przez niebezpieczne połączenie HTTP. Jest to problem bezpieczeństwa, ponieważ zasoby HTTP mogą być przechwycone, zmodyfikowane lub zastąpione przez atakującego, nawet jeśli sama strona główna jest zaszyfrowana. Ikona kłódki w przeglądarce znika, a odwiedzający widzą ostrzeżenia, które podważają ich zaufanie do Twojej witryny.

Pasywne vs. aktywne mixed content

Przeglądarki rozróżniają dwie kategorie mixed content i traktują każdą inaczej:

• Pasywne (wyświetlane) mixed content: obejmuje obrazy, audio i wideo ładowane przez HTTP. Ryzyko jest niższe, ponieważ te zasoby nie mogą bezpośrednio modyfikować zachowania strony. Atakujący mógłby podmienić obraz (na przykład pokazać nieodpowiednią treść), ale nie wstrzyknąć kodu. Starsze przeglądarki ładowały pasywne mixed content z ostrzeżeniem. Nowoczesne przeglądarki coraz częściej je blokują, choć niektóre nadal je dopuszczają z obniżonym wskaźnikiem bezpieczeństwa.
• Aktywne mixed content: obejmuje skrypty, arkusze stylów, iframe, czcionki i XMLHttpRequests ładowane przez HTTP. Aktywne mixed content jest znacznie bardziej niebezpieczne, ponieważ zmanipulowany skrypt może wykraść dane logowania, przekierować użytkownika lub wstrzyknąć malware na stronę. Wszystkie nowoczesne przeglądarki domyślnie blokują aktywne mixed content. Zasób po prostu się nie ładuje, co może całkowicie zepsuć funkcjonalność strony.

Jak przeglądarki traktują mixed content

Zachowanie przeglądarek stało się surowsze przez lata. Oto co dzieje się dzisiaj:

• Chrome: blokuje całe aktywne mixed content. Od wersji 80 Chrome automatycznie również uaktualnia mieszane obrazy, audio i wideo do HTTPS. Jeśli wersja HTTPS nie istnieje, zasób jest blokowany.
• Firefox: blokuje aktywne mixed content i pokazuje ikonę tarczy na pasku adresu. Pasywne mixed content powoduje ostrzeżenie, ale w niektórych przypadkach nadal może się załadować.
• Safari: blokuje aktywne mixed content. Pasywne mixed content może się załadować z ostrzeżeniem, w zależności od wersji.
• Edge: stosuje to samo zachowanie oparte na Chromium co Chrome.

Trend jest jasny: przeglądarki przechodzą do blokowania całego mixed content, zarówno aktywnego, jak i pasywnego. Naprawianie problemów z mixed content nie jest już opcjonalne.

Znajdowanie źródeł mixed content

Istnieje kilka sposobów identyfikacji mixed content na Twojej witrynie WordPress:

• Konsola DevTools przeglądarki: otwórz Chrome DevTools (F12), przejdź do zakładki Console i poszukaj żółtych ostrzeżeń lub czerwonych błędów dotyczących mixed content. Chrome powie Ci dokładnie, który URL zasobu powoduje problem.
• Why No Padlock: darmowe narzędzie online (whynopadlock.com), które skanuje URL i wymienia wszystkie znalezione niebezpieczne zasoby na stronie. Przydatne do szybkiego sprawdzenia bez otwierania DevTools.
• Raporty InspectWP: InspectWP automatycznie skanuje Twoją stronę pod kątem wszystkich zasobów ładowanych przez HTTP na stronie HTTPS i wymienia każdy zasób. To najszybszy sposób, aby uzyskać kompletny obraz całej swojej witryny.
• SSL Labs: choć przede wszystkim jest to narzędzie do sprawdzania konfiguracji SSL/TLS, może również zidentyfikować problemy z mixed content na testowanej stronie.

Częste przyczyny mixed content w WordPress

Problemy z mixed content w WordPress zwykle pochodzą z kilku powtarzających się źródeł:

• Zakodowane na sztywno URL-e HTTP w treści: jeśli zmigrowałeś swoją witrynę z HTTP na HTTPS, Twoje stare wpisy i strony mogą nadal zawierać URL-e obrazów i linki zaczynające się od http://. Były wtedy poprawne, ale stały się mixed content po migracji.
• Stare zasoby motywu: niektóre starsze motywy lub motywy potomne mają zakodowane na sztywno URL-e HTTP w swoich CSS, plikach JavaScript lub plikach szablonów. Arkusz stylów ładujący obraz tła z http://example.com/bg.jpg tworzy mixed content.
• Zasoby wtyczek: wtyczki ładujące zewnętrzne skrypty lub style przez HTTP powodują mixed content. Jest to szczególnie powszechne w starszych lub źle utrzymywanych wtyczkach, które nie zostały zaktualizowane pod kątem HTTPS.
• Zewnętrzne osadzenia: iframe, osadzone filmy lub widgety z zewnętrznych usług używające URL-i HTTP. Jeśli zewnętrzna usługa wspiera HTTPS (większość teraz wspiera), zmiana URL-a na HTTPS to rozwiązuje.
• Konfiguracja CDN: jeśli Twoje CDN nie jest skonfigurowane do dostarczania zasobów przez HTTPS, każdy plik CSS, JS i obraz dostarczany przez CDN staje się mixed content.

Naprawianie mixed content w WordPress

Rozwiązanie zależy od źródła problemu. Oto najczęstsze poprawki:

• Zastępowanie URL-i w bazie danych: dla zakodowanych na sztywno URL-i HTTP w treści wpisów użyj narzędzia wyszukaj i zastąp, aby zaktualizować wszystkie wystąpienia http://twojadomena.com do https://twojadomena.com w bazie danych. Wtyczka Better Search Replace jest do tego szeroko używana. Pozwala podglądać zmiany przed ich zastosowaniem i działa we wszystkich tabelach bazy danych. Zawsze rób kopię zapasową bazy danych przed uruchomieniem wyszukaj-i-zastąp.
• SSL Insecure Content Fixer: ta wtyczka WordPress automatycznie naprawia niebezpieczne URL-e w locie. Przepisuje URL-e HTTP na HTTPS w wyniku strony bez modyfikowania bazy danych. To dobre rozwiązanie tymczasowe, gdy rozwiązujesz przyczyny źródłowe, ale dodaje niewielki narzut wydajnościowy, ponieważ przetwarza każde ładowanie strony.
• Really Simple SSL: kolejna popularna wtyczka, która obsługuje przejście z HTTP na HTTPS. Naprawia mixed content przez filtrowanie wyniku strony, ustawia przekierowania i aktualizuje ustawienia URL witryny WordPress.
• Ręczne poprawki motywu i wtyczek: jeśli mixed content pochodzi z pliku motywu lub wtyczki, edytuj kod źródłowy, aby zastąpić http:// na https:// lub, lepiej, użyj URL-i względnych względem protokołu (//example.com/file.js) lub funkcji WordPress esc_url() do dynamicznego generowania URL-i.

Zastępowanie URL-i w bazie danych szczegółowo

Najbardziej dogłębny sposób naprawy mixed content ze starej treści wpisów to wyszukaj-i-zastąp w bazie danych. Oto proces:

1. Zrób kopię zapasową swojej bazy danych. To nie jest opcjonalne; źle wykonane wyszukaj-i-zastąp może zepsuć całą Twoją witrynę.
2. Zainstaluj i aktywuj wtyczkę Better Search Replace.
3. Wyszukaj http://twojadomena.com i zastąp https://twojadomena.com.
4. Wybierz wszystkie tabele bazy danych (zwłaszcza wp_posts, wp_postmeta i wp_options).
5. Najpierw uruchom test, aby zobaczyć, ile zamian zostałoby wykonanych.
6. Jeśli liczby wyglądają dobrze, wykonaj rzeczywistą zamianę.

Dla użytkowników WP-CLI komenda wp search-replace 'http://twojadomena.com' 'https://twojadomena.com' --all-tables robi to samo z wiersza poleceń. WP-CLI poprawnie obsługuje zserializowane dane w bazie danych, co jest kluczowe dla opcji i ustawień widgetów.

Przekierowanie HTTPS przez .htaccess

Po naprawieniu mixed content upewnij się, że wszystkie żądania HTTP do Twojej witryny są przekierowywane na HTTPS. Zapobiega to dostępowi odwiedzających i wyszukiwarek do wersji HTTP. Na serwerach Apache dodaj te reguły do pliku .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Na serwerach Nginx dodaj to do swojego bloku serwera:

server {
    listen 80;
    server_name twojadomena.com www.twojadomena.com;
    return 301 https://$server_name$request_uri;
}

To przekierowanie samo w sobie nie naprawia mixed content, ale zapewnia, że nikt przypadkowo nie odwiedzi wersji HTTP Twojej witryny. Połączone z zastępowaniem URL-i w bazie danych i poprawkami wtyczek, kończy migrację HTTPS.

Co sprawdza InspectWP

InspectWP skanuje Twoją stronę pod kątem wszystkich zasobów ładowanych przez HTTP na stronie HTTPS i wymienia każdy z nich, w tym typ zasobu i pełny URL. Daje Ci to jasną listę kontrolną dokładnie tego, co należy naprawić. Strony bez problemów z mixed content pokazują czysty wynik, potwierdzając, że Twoja konfiguracja HTTPS działa poprawnie.