PrestaShop .htaccess: reguły bezpieczeństwa i wydajności, których potrzebujesz

Plik .htaccess to pojedynczy, najmocniejszy, i po cichu najbardziej ryzykowny, plik w instalacji PrestaShop. Kilka dobrze umieszczonych linijek blokuje boty skanujące pliki, które atakują każdy sklep dostępny w publicznym internecie, zmniejsza rozmiar każdej strony o kolejne kilobajty i pilnuje, żeby wrażliwe pliki nigdy nie zostały zaserwowane przeglądarce. Ten sam plik, edytowany nieuważnie, zwraca 500 Internal Server Error pod każdym adresem URL i wyłącza cały sklep, dopóki nie dostaniesz się do klienta FTP. Większość sprzedawców nigdy go nie otwiera. Ten poradnik pokazuje, jak otworzyć go świadomie: które linie dodać, gdzie je umieścić, żeby PrestaShop nie nadpisał Twojej pracy, oraz jak wrócić online w sześćdziesiąt sekund, jeśli coś pójdzie nie tak.

Ostatnia aktualizacja: czerwiec 2026.

To artykuł z regułami i konfiguracją dla całego klastra: konkretne dyrektywy, które wklejasz do pliku .htaccess. Szersza strategia, od czego zacząć wzmacnianie zabezpieczeń i jak myśleć o całej powierzchni ataku, znajduje się w pełnej checkliście wzmacniania bezpieczeństwa, a wersja bez żargonu dla nietechnicznych właścicieli sklepów to prosty poradnik dla właścicieli sklepów. Tutaj zostajemy na poziomie samego pliku.

Czym jest .htaccess i jaki jeden fakt ratuje Twój sklep

.htaccess ("hypertext access") to plik konfiguracyjny dla serwera WWW Apache, działający na poziomie konkretnego katalogu. PrestaShop tworzy go za Ciebie przy pierwszym włączeniu przyjaznych adresów URL w sekcji Parametry sklepu → Ruch & SEO → SEO & adresy URL i przepisuje za każdym razem, gdy przełączysz to ustawienie albo zmienisz wzorzec adresu URL. Ta automatyczna generacja jest właśnie faktem, który Cię ratuje: jeśli kiedykolwiek zepsujesz plik, możesz odtworzyć czystą wersję domyślną z panelu administracyjnego w dwóch kliknięciach (opisujemy to na końcu).

Jedno zastrzeżenie, zanim czegokolwiek dotkniesz: .htaccess działa tylko na Apache. Coraz większa część hostingu PrestaShop działa na Nginx (albo na Apache schowanym za Nginx), gdzie pliki .htaccess są całkowicie ignorowane. Jeśli korzystasz z Nginx, poniższe zasady bezpieczeństwa i wydajności pozostają takie same, ale składnia trafia do bloku witryny/serwera, a nie do pliku w katalogu, jako punkt wyjścia dla reguł przepisywania adresów użyj oficjalnej dokumentacji konfiguracji PrestaShop dla Nginx (albo przykładu dostarczonego przez hosting). Nie masz pewności, z czego korzystasz? Linia Server: Apache albo Server: nginx w nagłówkach odpowiedzi powie Ci to od razu.

Złota zasada: pisz poza markerami PrestaShop

Otwórz plik, a znajdziesz blok zarządzany przez PrestaShop ujęty w markery komentarzy:

Treść markera jest jednoznaczna: PrestaShop zachowuje kod poza tym komentarzem podczas regenerowania pliku. Dlatego Twoje własne reguły bezpieczeństwa i wydajności powinny trafić nad marker ~~start~~ albo pod marker ~~end~~, nigdy pomiędzy nimi. Ten jeden nawyk decyduje o tym, czy reguły przetrwają każde kliknięcie "zapisz ustawienia SEO", czy po cichu znikną w następny wtorek.

Co domyślny blok PrestaShop robi już teraz (zostaw go w spokoju)

Zanim cokolwiek dodasz, warto wiedzieć, co jest już obsługiwane wewnątrz bloku zarządzanego, żeby nie dublować reguł i nie wywołać konfliktów:

• Przepisywanie adresów URL, duży zestaw reguł RewriteRule, który zamienia /123-nike-air-max na coś, co index.php potrafi obsłużyć. To część zarządzana przez PrestaShop; nigdy nie dotykaj jej ręcznie.
• Options -MultiViews, zatrzymuje negocjowanie treści przez Apache, żeby żądanie /about nie zostało obsłużone przez przypadkowy plik about.html, zamiast trafić do routera PrestaShop.
• DirectoryIndex index.php. Zapewnia uruchomienie front controllera, gdy żądany jest katalog.
• RewriteBase, ustawione na / dla instalacji w katalogu głównym albo na /shop/, jeśli PrestaShop działa w podfolderze. Błąd w tym miejscu sprawi, że każdy przyjazny URL zwróci 404.
• Nadpisania wartości PHP na niektórych hostingach (limit pamięci, rozmiar wysyłanych plików), dodawane, gdy nie możesz bezpośrednio edytować php.ini.

Wszystko to jest poprawne od razu po wygenerowaniu. Twoim zadaniem jest dodać warstwę, której PrestaShop nie dostarcza domyślnie: utwardzenie zabezpieczeń i cache.

Reguły bezpieczeństwa do dodania (nad markerem)

Domyślny plik PrestaShop jest funkcjonalny, ale nieutwardzony. Poniższe reguły zamykają realne, regularnie skanowane luki. Wklej je przed markerem ~~start~~.

1. Zablokuj bezpośredni dostęp do wrażliwych plików

Umieść to nad markerem zarządzanym przez PrestaShop na Apache 2.4+:

<FilesMatch "^(composer\.(json|lock)|package(-lock)?\.json|\.env|\.gitignore)$">
    Require all denied
</FilesMatch>

<FilesMatch "^(parameters\.php|settings\.inc\.php)$">
    Require all denied
</FilesMatch>

Drzewo PrestaShop zawiera pliki, które nigdy nie powinny zostać wysłane do przeglądarki: konfigurację YAML, logi, zrzuty SQL, surowe szablony Twig i Smarty. Jeśli bot może wykonać GET /app/config/parameters.yml, może odczytać dane dostępowe do bazy. Zablokuj niebezpieczne rozszerzenia:

<FilesMatch "\.(yml|yaml|log|tpl|twig|sql|md|dist|neon|ini)$">
  Require all denied
</FilesMatch>

(Na starszym hostingu z Apache 2.2 zamień Require all denied na Order deny,allow / Deny from all, hosting powie Ci, której wersji Apache używasz). PrestaShop już umieszcza atrapy index.php w wielu katalogach, ale jawne blokowanie rozszerzeń obejmuje pliki, których te atrapy nie zabezpieczają.

2. Zablokuj najcenniejsze pliki konfiguracyjne po nazwie

Dwa pliki zasługują na osobny, nazwany blok "na wszelki wypadek", bo są najcenniejszym celem: starszy config/settings.inc.php (1.6) i nowszy app/config/parameters.php (1.7–9). To pliki PHP, więc Apache ich normalnie nie wypisze, ale źle skonfigurowany serwer albo kopia .bak mogą je ujawnić. Zablokuj cały zestaw:

<FilesMatch "(parameters\.(php|yml)|settings\.inc\.php|.*\.bak)$">
  Require all denied
</FilesMatch>

3. Zablokuj ujawnienie .git i .env

Jeśli wdrażasz sklep przez Git (warto), możliwy do przeglądania katalog /.git/ oddaje atakującemu całą historię źródeł, w tym dane dostępowe ze starych commitów. Tak samo wygląda sytuacja z pozostawionym przypadkiem plikiem .env:

RedirectMatch 404 /\.git
<FilesMatch "^\.env">
  Require all denied
</FilesMatch>

4. Wyłącz listowanie katalogów

Bez tej reguły każdy, kto wpisze w przeglądarce /upload/ albo /download/, zobaczy klikalny indeks plików, klasyczny wyciek informacji. Jedna linia wyłącza to wszędzie:

Options -Indexes

5. Dodaj nagłówki bezpieczeństwa

Nagłówki odpowiedzi HTTP mówią przeglądarce, żeby włączyła własne mechanizmy ochrony. Wymagają modułu Apache mod_headers (prawie zawsze jest dostępny); opakuj je w <IfModule>, żeby hosting bez tego modułu nie zwrócił błędu 500:

<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
  Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

• X-Content-Type-Options: nosniff, powstrzymuje przeglądarkę przed zgadywaniem typu pliku i uruchomieniem przesłanego pliku jako skryptu.
• X-Frame-Options: SAMEORIGIN, blokuje clickjacking, odmawiając załadowania Twojego sklepu w iframe innej witryny.
• Referrer-Policy, ogranicza ilość danych z adresu URL przekazywanych zewnętrznym serwisom przy kliknięciach wychodzących.
• Permissions-Policy, domyślnie odmawia dostępu do kamery, mikrofonu i geolokalizacji, żeby przejęty skrypt nie mógł po cichu o nie poprosić.

Zwróć uwagę na celowe pominięcie: stary nagłówek X-XSS-Protection jest przestarzały i ignorowany (albo szkodliwy) we współczesnych przeglądarkach, nie dodawaj go. Nagłówek, który warto dodać w następnej kolejności, Content-Security-Policy, jest potężny, ale łatwo nim zepsuć motyw PrestaShop, więc powinien trafić do ostrożnego, przetestowanego wdrożenia, a nie do kopiuj-wklej. CSP to także Twoja najmocniejsza ochrona przed skimmerami kart na stronach płatności, mechanikę takiego ataku opisuje anatomia ataku w stylu Magecart.

Jest jedna rzecz, której .htaccess celowo nie robi dobrze: limitowanie ruchu i geoblokowanie nadużyć na dużą skalę. Ogólne listy IP w dyrektywach Deny from w .htaccess szybko się starzeją i nie zatrzymują rozproszonych skanerów. Prawdziwą kontrolę odwiedzających, filtrowanie złych botów, bany IP, reguły krajów, obsługuj na poziomie aplikacji albo warstwy edge: zobacz blokowanie złych botów i niechcianego ruchu oraz, dla sklepów, które już odczuwają presję, jak przetrwać zalew crawlerów z ?q=.

Reguły wydajności do dodania

Ten sam plik pozwala włączyć dwa najbardziej opłacalne usprawnienia szybkości front-endu. Znów: poza markerami, każde opakowane w <IfModule>.

Kompresja Gzip / Deflate

Odpowiedzi tekstowe, HTML, CSS, JS, JSON, SVG, kompresują się zwykle o około 60–80%, więc strona produktu PrestaShop wysyłająca około 150 KB znaczników może opuścić serwer bliżej 40 KB. Co to oznacza dla Ciebie? Szybsze pierwsze renderowanie, niższy współczynnik odrzuceń i lepszy wynik PageSpeed, bez zmiany choćby jednego szablonu:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml
  AddOutputFilterByType DEFLATE application/javascript application/json image/svg+xml
  AddOutputFilterByType DEFLATE font/woff2 image/x-icon
</IfModule>

Wielu dostawców hostingu włącza kompresję globalnie na serwerze. Jeśli Twój też tak robi, powyższy blok opakowany w <IfModule> jest nieszkodliwy i po prostu zbędny, mod_deflate nie skompresuje ponownie już skompresowanej odpowiedzi. Jeśli hosting zablokował mod_deflate przez AllowOverride, osłona <IfModule> chroni przed błędem 500; jeśli mimo wszystko zobaczysz taki błąd po dodaniu bloku, usuń go i pozwól serwerowi obsłużyć kompresję globalnie.

Cache przeglądarki (nagłówki Expires)

Ta reguła mówi przeglądarce powracającego odwiedzającego, żeby użyła statycznych zasobów, które już ma, zamiast pobierać je ponownie, to największy zysk przy kolejnych wizytach. Długie czasy cache są bezpieczne tylko dla zasobów wersjonowanych albo oznaczonych odciskiem wersji (PrestaShop i wiele motywów/modułów dodaje wersję w parametrze query string albo zmienia nazwy plików po przebudowaniu paczek); dla wszystkiego, co nie spełnia tego warunku, używaj krótszych czasów albo upewnij się, że strategia odświeżania cache, token w query string lub wersja w nazwie pliku. Naprawdę działa, zanim dodasz długi nagłówek Expires, bo przestarzały plik CSS/JS może utknąć w przeglądarkach po aktualizacji:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresDefault "access plus 2 days"
</IfModule>

Keep-Alive i ETags, zostaw je serwerowi

Keep-Alive (ponowne użycie jednego połączenia TCP dla wielu zasobów) pomaga każdej stronie PrestaShop, bo każda ładuje dziesiątki plików, ale prawie zawsze jest już włączone na poziomie hostingu, więc nie walcz z tym w .htaccess. ETags działają podobnie: są w porządku dla sklepu na jednym serwerze, ale czasem przeszkadzają w odświeżaniu cache w konfiguracjach klastrowych albo z CDN (zwykle CDN zarządza nimi za Ciebie). Zasada praktyczna: nie dodawaj dyrektyw dla rzeczy, które Twój stos już obsługuje, każda zbędna linia to kolejna szansa na błąd 500.

Typowe błędy, które wyłączają sklep

• Edycja wewnątrz markerów. Własne reguły między ~~start~~ i ~~end~~ zostaną usunięte przy kolejnej regeneracji. Zawsze pisz poza nimi.
• Nieosłonięte bloki kompresji lub nagłówków. Zduplikowana definicja na hostingu, który już kompresuje odpowiedzi, zwykle jest tylko zbędna, ale nieopakowana linia Header albo AddOutputFilterByType na hostingu, gdzie moduł nie jest załadowany, zwróci 500. Zawsze opakowuj w <IfModule> i usuń blok, jeśli nadal powoduje konflikt.
• Błędny RewriteBase. Instalacja w podfolderze (/shop/) z RewriteBase / zwróci 404 dla każdego przyjaznego adresu URL.
• Brak RewriteEngine On. Skopiuj reguły przepisywania z ogólnego poradnika bez tej dyrektywy, a wszystko poza stroną główną zacznie zwracać 404. (Własny blok PrestaShop ją zawiera, problem dotyczy osób wklejających zewnętrzne reguły).
• Dyrektywy zabronione przez hosting. Hostingi współdzielone często blokują php_value, Options i Header na poziomie serwera (AllowOverride). Użycie zablokowanej dyrektywy zwraca 500. Sprawdź to, zanim ją dodasz.

Jak odzyskać sklep po zepsutym .htaccess w mniej niż minutę

Lista SEO i adresów URL pokazuje każdą stronę z jej nazwą, tytułem i przyjaznym adresem URL.

Błąd 500 na każdej stronie po zapisie wygląda katastrofalnie; w rzeczywistości to jeden z najszybszych problemów hostingowych do naprawienia, bo przyczyną zawsze jest plik, który właśnie dotknąłeś. Trzy ścieżki, od najszybszej:

• FTP/SFTP. Połącz się, zmień nazwę .htaccess na .htaccess.broken (albo go usuń). Sklep wróci od razu; przestaną działać tylko przyjazne adresy URL, dopóki nie zregenerujesz pliku.
• Menedżer plików hostingu. W cPanelu albo swoim panelu włącz pokaż ukryte pliki (pliki z kropką są domyślnie ukryte), a potem zmień nazwę albo napraw plik w ten sam sposób.
• Wygeneruj czysty plik z panelu administracyjnego. Gdy sklep wróci, przejdź do Parametry sklepu → Ruch & SEO → SEO & adresy URL, wyłącz przyjazne adresy URL, zapisz, włącz ponownie i znów zapisz. PrestaShop zapisze świeży, poprawny plik domyślny, Twoją siatkę bezpieczeństwa na każdą awarię .htaccess.

Tanie ubezpieczenie: cp .htaccess .htaccess.backup przed każdą edycją zajmuje sekundę i oszczędza cały wieczór. Jeszcze lepiej: najpierw wprowadzaj zmiany na środowisku staging.

Przetestuj, zanim odejdziesz

• Przeklikaj krytyczne ścieżki: stronę główną, kategorię, produkt, koszyk i cały proces zakupu, zła reguła potrafi zepsuć jeden typ strony, zostawiając inne bez problemu.
• Zweryfikuj zyski wydajności: Google PageSpeed Insights pokaże, czy kompresja albo cache przeglądarki faktycznie działają.
• Sprawdź nagłówki: przepuść swoją domenę przez securityheaders.com, żeby potwierdzić wysyłanie każdego nagłówka bezpieczeństwa.

Najczęściej zadawane pytania

Gdzie dokładnie umieścić własne reguły w pliku .htaccess?

Poza blokiem zarządzanym przez PrestaShop, nad markerem # ~~start~~ albo pod markerem # ~~end~~, nigdy pomiędzy nimi. Sam komentarz markera mówi, że PrestaShop zachowuje kod poza blokiem podczas regenerowania pliku. Wszystko, co umieścisz między markerami, zostanie usunięte przy następnym zapisie ustawień SEO albo zmianie wzorca adresu URL.

Dodałem reguły i teraz każda strona zwraca 500. Jak najszybciej odzyskać sklep?

Przyczyną zawsze jest plik, który właśnie dotknąłeś. Połącz się przez FTP/SFTP (albo przez menedżer plików hostingu z widocznymi plikami ukrytymi), zmień nazwę .htaccess na .htaccess.broken, a sklep wróci od razu, przestaną działać tylko przyjazne adresy URL, dopóki ich nie zregenerujesz. Następnie przywróć sklep i wygeneruj czysty plik z Parametry sklepu → Ruch & SEO → SEO & adresy URL, wyłączając przyjazne adresy URL, zapisując, włączając je ponownie i znów zapisując.

Mój hosting działa na Nginx, czy te reguły .htaccess cokolwiek robią?

Nie. .htaccess to funkcja Apache, a Nginx całkowicie ją ignoruje. Te same zasady bezpieczeństwa i wydajności nadal obowiązują, ale dyrektywy trafiają do bloku serwera, nie do pliku w katalogu. Użyj oficjalnej konfiguracji PrestaShop dla Nginx (albo przykładu od hostingu) jako podstawy dla reguł przepisywania i przełóż reguły deny/header/compression na bloki location. Sprawdź nagłówek odpowiedzi Server:, żeby potwierdzić, na czym działa sklep.

Czy dodanie kompresji i nagłówków Expires zdubluje to, co hosting już robi?

Zwykle jest to nieszkodliwe. mod_deflate nie skompresuje ponownie już skompresowanej odpowiedzi, więc zbędny blok po prostu nic nie robi. Ryzykiem jest nieopakowana dyrektywa na hostingu, gdzie moduł nie jest załadowany, wtedy pojawi się 500. Zawsze opakowuj bloki kompresji i nagłówków w <IfModule>, a jeśli nadal widzisz konflikt, usuń blok i pozwól serwerowi obsłużyć to globalnie.

Czy warto dodać tutaj także nagłówek Content-Security-Policy?

Nie metodą kopiuj-wklej. CSP to Twoja najmocniejsza obrona przed skimmerami kart na stronie płatności, ale zbyt restrykcyjna polityka po cichu psuje skrypty motywu, iframe'y płatności i analitykę. Należy wdrażać ją ostrożnie i testowo, najpierw w trybie report-only, obserwując, co zostałoby zablokowane, a dopiero potem egzekwować. Nie wrzucaj ogólnej linii CSP do .htaccess i nie uznawaj tematu za zamknięty.

Gdzie kończy się .htaccess, a zaczynają moduły

Dobrze ustawiony .htaccess to naprawdę mocna, darmowa pierwsza warstwa, zamyka luki związane z ujawnianiem plików, których szukają skanery, oraz włącza kompresję i cache, dzięki którym PrestaShop działa szybciej. Ale to narzędzie tępe. Nie potrafi ocenić, kto wykonuje żądanie, nie odzyska sklepu po włamaniu i nie utrzyma nieaktualizowalnego sklepu załatanego względem znanych CVE. To zadania warstwy aplikacji:

• Utknąłeś na starej wersji, której nie możesz zaktualizować? Reguły serwera nie załatają podatnego rdzenia. Wirtualne łatanie już tak, zobacz zaawansowane wzmacnianie zabezpieczeń dla sklepów, których jeszcze nie możesz zaktualizować.
• Ochrona logowania do panelu administracyjnego i kont klientów (2FA, polityka haseł) jest poza zakresem .htaccess, opisujemy ją tutaj.
• Jeśli wydarzy się najgorsze, plik z nagłówkami nie pomoże Ci zareagować, pomoże plan reakcji na naruszenie danych.

Po stronie wydajności działa ta sama logika: ręcznie dopisane reguły Expires i Deflate są dobrym punktem wyjścia, ale pełny cache stron, inteligentna minifikacja, optymalizacja obrazów i integracja z CDN przesuwają realny sklep z poziomu "działa poprawnie" do "działa szybko", a to powinno mieszkać w utrzymywanym module, nie w coraz dłuższym pliku .htaccess. Takie rozwiązania budujemy w mypresta.rocks: techniczna głębia jest obsłużona za Ciebie, dzięki czemu szybkość i spokój są ustawieniami w panelu administracyjnym, a nie linijkami, które musisz wpisać idealnie w pliku zdolnym położyć cały sklep.