CSP w Magento 2: Zarządzaj whitelistą bez deployu

Dlaczego Content Security Policy w Magento 2 bywa koszmarem wdrożeniowym?

Content Security Policy (CSP) to jeden z najważniejszych nagłówków bezpieczeństwa HTTP, jaki możesz wdrożyć w nowoczesnym e-commerce. Mówi przeglądarce klienta wprost: z jakich domen wolno ładować skrypty JavaScript, arkusze stylów, czcionki, obrazy czy ramki iframe. Jeżeli cyberprzestępca zdoła wstrzyknąć złośliwy kod przez lukę w module zewnętrznym (atak typu XSS lub Magecart skimmer), poprawnie skonfigurowane CSP uniemożliwi pobranie obcego skryptu lub wysłanie danych karty płatniczej na nieautoryzowany serwer.

Magento 2 od wersji 2.4 posiada wbudowany mechanizm CSP, ale jego obsługa w warunkach produkcyjnych jest źródłem ciągłych frustracji. Domyślnie każda zaufana domena zewnętrzna – od Google Tag Managera, przez Hotjara, czat pomocy, po bramkę płatności – musi zostać wpisana ręcznie w plik konfiguracyjny csp_whitelist.xml w motywie lub dedykowanym module. Efekt? Dodanie jednego piksela śledzącego przez dział marketingu wymaga zaangażowania programisty, commita do repozytorium i przejścia przez pełen proces CI/CD oraz deployu produkcyjnego. Dlatego udostępniliśmy darmowy moduł CSP Whitelist, który przenosi zarządzanie regułami bezpośrednio do panelu administracyjnego Magento.

Jak wygląda typowy konflikt CSP w codziennej pracy sklepu?

Wyobraź sobie prosty scenariusz: w piątek po południu zespół marketingu odpala nową kampanię i podpina narzędzie do analityki behawioralnej. Kilka minut później konsola przeglądarki zalewa się czerwonymi komunikatami:

Refused to load the script 'https://external-tracker.example.com/analytics.js' because it violates the following Content Security Policy directive: "script-src 'self' ...".

Skrypt nie działa, zdarzenia nie są rejestrowane, a w skrajnych przypadkach – gdy CSP działa w restrykcyjnym trybie blokowania (restrict mode) zamiast report-only – może dojść do zablokowania iframe'a z bramką płatniczą lub formularza logowania. Standardowa ścieżka ratunkowa w Magento to stworzenie pliku w ścieżce app/code/Vendor/Module/etc/csp_whitelist.xml:

<?xml version="1.0"?>
<csp_whitelist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <policies>
        <policy id="script-src">
            <values>
                <value id="example-tracker" type="host">https://external-tracker.example.com</value>
            </values>
        </policy>
    </policies>
</csp_whitelist>

Wymusza to cykl: zadanie w Jirze, praca dewelopera, code review, wdrożenie na staging, testy i dopiero produkcja. Z perspektywy rentowności biznesu angażowanie programisty do dodania jednej domeny URL to strata czasu i budżetu.

Jak wygląda stan bezpieczeństwa CSP w polskich sklepach Magento?

Jako studio regularnie audytujemy sklepy oparte na Magento 2. Z naszego cyklicznego badania rynku („Kondycja polskich sklepów Magento”) wynika alarmujący wniosek: około połowa polskich sklepów Magento w ogóle nie wysyła nagłówka Content Security Policy lub wyłącza go całkowicie po napotkaniu pierwszych problemów konfiguracyjnych.

Dzieje się tak, ponieważ utrzymanie czystej listy w plikach XML jest uciążliwe. Gdy po aktualizacji silnika w konsoli pojawia się setka zablokowanych zasobów, deweloperzy często idą po linii najmniejszego oporu – deaktywują moduł Magento_Csp. W ten sposób sklep pozostaje całkowicie bezbronny wobec ataków typu supply chain, gdzie zainfekowana zostaje biblioteka zewnętrzna ładowana przez CDN. To realna, powszechna luka w polskim e-commerce.

Jak zarządzać whitelistą CSP z panelu admina Magento 2?

Rozwiązaniem problemu jest dynamiczna whitelist-a zapisywana w bazie danych i konfigurowana przez GUI. Po zainstalowaniu modułu zarządzanie regułami odbywa się w sekcji:

Stores > Configuration > Cti > CSP Whitelist

W tym widoku administrator lub osoba z działu technicznego/marketingu może w kilka sekund dodać nową domenę, wybierając odpowiednią dyrektywę z listy rozwijanej:

• script-src – dla zewnętrznych skryptów JS (Google Tag Manager, Meta Pixel, widgety czatów),
• connect-src – dla endpointów XHR/Fetch oraz połączeń WebSocket (np. analityka real-time),
• img-src – dla obrazów serwowanych z zewnętrznych CDN-ów i platform graficznych,
• frame-src – dla osadzanych ramek, takich jak zewnętrzne procesory płatności (Stripe, PayU, Przelewy24) czy odtwarzacze wideo,
• style-src / font-src – dla zewnętrznych arkuszy stylów i krojów pisma (Google Fonts, Typekit).

Po zapisaniu konfiguracji i wyczyszczeniu cache konfiguracji (bin/magento cache:clean config lub bezpośrednio z poziomu panelu Cache Management), nagłówek CSP jest natychmiast aktualizowany o nowe domeny. Zero zmian w kodzie źródłowym, zero deployów.

Dlaczego stworzyliśmy własny fork modułu CTI Digital?

Koncepcja modułu nie jest nowa – pierwotnie stworzyła go brytyjska agencja CTI Digital pod nazwą ctidigital/magento2-csp-whitelist. Moduł rozwiązywał problem znakomicie, ale został porzucony w okolicach 2021 roku. Co gorsza, jego oryginalny plik composer.json nie posiadał zdefiniowanej sekcji require.

W praktyce oznaczało to bombę z opóźnionym zapłonem: menedżer pakietów Composer pozwalał zainstalować stary moduł na nowoczesnych wersjach platformy bez żadnego ostrzeżenia. To, czy taki moduł jeszcze zadziała, staje się loterią zależną od wersji: część porzuconych rozszerzeń wciąż działa, a część wywala sklep błędem fatalnym na nowszym PHP z powodu niekompatybilności sygnatur metod — na dokładnie taki przypadek trafiliśmy przy innym module podczas testów na Magento 2.4.9.

W SISL prowadzimy wewnętrzną inicjatywę: bierzemy porzucone, ale wartościowe i potrzebne moduły społeczności Magento, przepisujemy je do współczesnych standardów i udostępniamy za darmo jako otwartoźródłowe narzędzia.

Kompatybilność z Magento 2.4.9 i PHP 8.4

Nasz fork rozwiązuje wszystkie problemy wieku dziecięcego pierwowzoru. Kod został dostosowany do najnowszych wymagań środowiskowych:

• Zdefiniowano precyzyjne zależności: php: ~8.1.0 || ~8.2.0 || ~8.3.0 || ~8.4.0 || ~8.5.0,
• Dodano wymaganie platformowe: magento/framework: >=103.0.4 <104,
• Zweryfikowano pełną kompatybilność z Magento 2.4.9 oraz PHP 8.4,
• Poprawiono deklaracje typów oraz strukturę wstrzykiwania zależności w klasach odczytujących reguły z bazy danych.

Kod modułu jest publicznie dostępny i open-source. Możesz go pobrać i zweryfikować w repozytorium GitHub: https://github.com/SISL-source/magento2-csp-whitelist.

Instalacja przez Composer

Aby wdrożyć moduł w swoim projekcie, wystarczy dodać repozytorium do pliku composer.json i zainstalować pakiet:

composer config repositories.csp vcs https://github.com/SISL-source/magento2-csp-whitelist
composer require ctidigital/magento2-csp-whitelist:dev-main
bin/magento module:enable CtiDigital_CspWhitelist
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:clean

Kiedy przełączyć CSP z Report-Only na tryb blokowania?

Domyślnie Magento 2 działa w trybie raportowania (nagłówek Content-Security-Policy-Report-Only). W tym stanie przeglądarka nie blokuje żadnych nieautoryzowanych zasobów, a jedynie loguje naruszenia zasad w konsoli deweloperskiej lub wysyła je na skonfigurowany endpoint telemetryczny. To idealny moment na zebranie pełnej listy legalnie działających w sklepie narzędzi i dodanie ich do modułu w panelu admina.

Gdy po kilku dniach intensywnego ruchu na sklepie konsola jest czysta od błędów CSP, należy przełączyć moduł w tryb wymuszania (Enforce). Dopiero wtedy sklep zyskuje realną tarczę ochronną przed atakami XSS i nieautoryzowanym kodem zewnętrznym.

Jeśli konfiguracja polityk bezpieczeństwa, optymalizacja nagłówków HTTP lub audyt stabilności Twojego e-commerce sprawia trudności deweloperskie – napisz do nas. Przeanalizujemy Twój stos technologiczny i wdrożymy rozwiązania, które zabezpieczają sklep bez utrudniania codziennej pracy operacyjnej.