Bezpieczeństwo aplikacji to kilka konkretnych kontroli: sesja HTTP, panel admina, sekrety, biblioteki, upload plików i skan znanych luk. Zapora na krawędzi odcina masę. Nie łata Magento ani wtyczki.
Cel jest prosty: utrudnić kradzież sesji, wejście na panel i wyciek hasła bazy z repozytorium.
Co warto włączyć
Cookie sesji z flagami HttpOnly, Secure i SameSite ogranicza kradzież identyfikatora przez skrypt na stronie i wysyłkę po zwykłym HTTP. Dwuskładnikowe logowanie na panelu odcina hasło wyciekłe z phishingu. Sekret w menedżerze albo w zmiennych wdrożenia, a nie w Gicie: skan publicznego repo nie dostaje bazy.
composer audit i npm audit pokazują znane luki w bibliotekach. Agent na hoście alarmuje, gdy ktoś zmieni konfigurację sklepu albo doda plik w katalogu mediów. Skan podatności znajduje stare PHP i otwarte porty. Maskowanie zrzutu na stagingu odcina kopię produkcji na laptopie agencji.
Jak to ustawić w praktyce
W Magento: cookie tylko przez HTTPS, 2FA na wszystkich kontach admina, własna ścieżka panelu, env.php poza repozytorium, w mediach bez wykonywania PHP. W CI zadanie pada przy krytycznej luce w Composerze.
W WordPressie: wyłącz edycję plików z panelu, 2FA albo SSO, xmlrpc wyłączony jeśli nieużywany, wtyczki z datą aktualizacji.
Na hoście: agent Wazuh na konfiguracji i nginx, cotygodniowy skan originu i panelu, panel admina za Cloudflare Access albo VPN, nie samo hasło na publicznym 443.
Warstwy: security.
W skrócie: krawędź tnie masę. Aplikację chroni sesja, 2FA, sekrety poza Gitem i aktualne zależności. Bez tego panel i baza zostają w zasięgu pierwszego skanu.