PrestaShop .htaccess: Sicherheits- und Performance-Regeln, die Sie brauchen

Die .htaccess-Datei ist die mit Abstand mächtigste — und am unauffälligsten gefährlichste — Datei in einer PrestaShop-Installation. Eine Handvoll gut platzierter Zeilen blockiert die dateiscannenden Bots, die jeden Shop im öffentlichen Internet bombardieren, spart bei jeder Seite Kilobytes ein und verhindert, dass sensible Dateien jemals ausgeliefert werden. Dieselbe Datei, unachtsam bearbeitet, liefert auf jeder URL einen 500 Internal Server Error und nimmt Ihren gesamten Shop offline, bis Sie einen FTP-Client erreichen. Die meisten Händler öffnen sie nie. In diesem Leitfaden geht es darum, sie bewusst zu öffnen, genau zu wissen, welche Zeilen man hinzufügt, wo man sie platziert, damit PrestaShop Ihre Arbeit nicht überschreibt, und wie man in sechzig Sekunden wieder online kommt, wenn etwas schiefgeht.

Zuletzt aktualisiert: Juni 2026.

Dies ist der Regeln-und-Konfiguration-Beitrag des Clusters: die konkreten Direktiven, die Sie in die .htaccess einfügen. Die übergeordnete Strategie — was zuerst gehärtet werden sollte, wie man über seine gesamte Angriffsfläche nachdenkt — finden Sie in der vollständigen Sicherheitshärtungs-Checkliste, und die fachjargonfreie Version für nicht-technische Inhaber ist der Leitfaden in verständlicher Sprache. Hier bleiben wir auf Dateiebene.

Was .htaccess ist, und die eine Tatsache, die Ihren Shop rettet

.htaccess („hypertext access“) ist eine verzeichnisbezogene Konfigurationsdatei für den Webserver Apache. PrestaShop schreibt sie für Sie, sobald Sie zum ersten Mal Sprechende URLs unter Shop-Parameter → Datenverkehr & SEO → SEO & URLs aktivieren, und schreibt sie jedes Mal neu, wenn Sie diese Einstellung umschalten oder ein URL-Muster ändern. Diese automatische Generierung ist die Tatsache, die Sie rettet: Wenn Sie die Datei jemals beschädigen, können Sie aus dem Backoffice mit zwei Klicks eine saubere Standardversion neu erzeugen (wird am Ende behandelt).

Ein Vorbehalt, bevor Sie irgendetwas anfassen: .htaccess funktioniert nur unter Apache. Ein wachsender Anteil des PrestaShop-Hostings läuft unter Nginx (oder Apache-hinter-Nginx), wo .htaccess-Dateien vollständig ignoriert werden. Wenn Sie unter Nginx sind, sind die unten stehenden Sicherheits- und Performance-Ideen identisch, aber die Syntax steht in Ihrem Site-/Server-Block, nicht in einer verzeichnisbezogenen Datei — folgen Sie der offiziellen PrestaShop-Nginx-Konfigurationsdokumentation (oder dem von Ihrem Hoster bereitgestellten Beispiel), um die Rewrite-Regeln als Ausgangspunkt zu erhalten. Nicht sicher, unter welchem Sie sind? Eine Zeile mit Server: Apache oder Server: nginx in Ihren Antwort-Headern sagt es Ihnen sofort.

Die goldene Regel: außerhalb der PrestaShop-Markierungen schreiben

Öffnen Sie die Datei und Sie finden den von PrestaShop verwalteten Block, eingeklammert von Kommentar-Markierungen:

Der Markierungskommentar ist eindeutig: PrestaShop behält den Code außerhalb dieses Kommentars, wenn es ihn neu generiert. Also gehören Ihre eigenen Sicherheits- und Performance-Regeln oberhalb der ~~start~~-Markierung oder unterhalb der ~~end~~-Markierung — niemals dazwischen. Diese eine Gewohnheit ist der Unterschied zwischen Regeln, die jeden „SEO-Einstellungen speichern“-Klick überstehen, und Regeln, die nächsten Dienstag unbemerkt verschwinden.

Was der Standardblock von PrestaShop bereits leistet (lassen Sie ihn in Ruhe)

Bevor Sie etwas hinzufügen, lohnt es sich zu wissen, was bereits innerhalb des verwalteten Blocks erledigt wird, damit Sie es nicht duplizieren und Konflikte auslösen:

• URL-Umschreibung — der umfangreiche RewriteRule-Satz, der /123-nike-air-max in etwas verwandelt, das index.php weiterleiten kann. Von PrestaShop verwaltet; niemals von Hand angefasst.
• Options -MultiViews — hindert Apache daran, eine Anfrage an /about per Content-Negotiation in eine verirrte about.html umzuleiten, statt sie vom Router von PrestaShop bearbeiten zu lassen.
• DirectoryIndex index.php — stellt sicher, dass der Front-Controller läuft, wenn ein Verzeichnis angefragt wird.
• RewriteBase — gesetzt auf / bei einer Root-Installation oder /shop/, wenn PrestaShop in einem Unterordner liegt. Stellen Sie das falsch ein und jede sprechende URL liefert einen 404.
• PHP-Wert-Überschreibungen bei manchen Hostern (Speicherlimit, Upload-Größe) — hinzugefügt, wenn Sie php.ini nicht direkt bearbeiten können.

All das ist ab Werk korrekt. Ihre Aufgabe ist es, die Schicht hinzuzufügen, die PrestaShop nicht mitliefert: Härtung und Caching.

Sicherheitsregeln zum Hinzufügen (oberhalb der Markierung)

Die Standarddatei von PrestaShop ist funktional, nicht gehärtet. Dies sind die Regeln, die echte, routinemäßig gescannte Lücken schließen. Fügen Sie sie vor der ~~start~~-Markierung ein.

1. Direkten Zugriff auf sensible Dateien blockieren

Platzieren Sie dies unter Apache 2.4+ oberhalb der von PrestaShop verwalteten Markierung:

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

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

Ein PrestaShop-Verzeichnisbaum enthält Dateien, die niemals an einen Browser ausgeliefert werden sollten: YAML-Konfiguration, Logs, SQL-Dumps, rohe Twig- und Smarty-Templates. Wenn ein Bot GET /app/config/parameters.yml ausführen kann, kann er Ihre Datenbank-Zugangsdaten lesen. Verweigern Sie die gefährlichen Erweiterungen:

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

(Auf älterem Apache-2.2-Hosting tauschen Sie Require all denied gegen Order deny,allow / Deny from all — Ihr Hoster kann Ihnen sagen, welche Apache-Version Sie haben.) PrestaShop legt bereits index.php-Stubs in viele Ordner, aber ein expliziter Erweiterungs-Deny deckt die Dateien ab, die diese Stubs übersehen.

2. Die wertvollen Konfigurationsdateien namentlich abriegeln

Zwei Dateien verdienen einen doppelt abgesicherten benannten Block, weil sie die Kronjuwelen sind: die alte config/settings.inc.php (1.6) und die moderne app/config/parameters.php (1.7–9). Es sind PHP-Dateien, daher gibt Apache sie nicht aus — aber ein falsch konfigurierter Server oder eine .bak-Kopie kann sie preisgeben. Verweigern Sie sie alle:

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

3. Offenlegung von .git und .env blockieren

Wenn Sie mit Git deployen (das sollten Sie), liefert ein durchsuchbares /.git/-Verzeichnis einem Angreifer Ihre gesamte Quellcode-Historie aus — einschließlich Zugangsdaten in alten Commits. Dasselbe gilt für eine verirrte .env:

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

4. Verzeichnisauflistung verhindern

Ohne sie sieht jeder, der einen Browser auf /upload/ oder /download/ richtet, einen anklickbaren Dateiindex — ein Lehrbuchbeispiel für ein Informationsleck. Eine Zeile schaltet es überall ab:

Options -Indexes

5. Sicherheits-Header hinzufügen

HTTP-Antwort-Header weisen den Browser an, seine eigenen Schutzmechanismen einzuschalten. Diese benötigen Apaches mod_headers (fast immer vorhanden); umschließen Sie sie mit einem <IfModule>, damit ein Hoster ohne dieses Modul keinen 500 liefert:

<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 — hindert den Browser daran, den Typ einer Datei zu erraten und einen Upload als Skript auszuführen.
• X-Frame-Options: SAMEORIGIN — blockiert Clickjacking, indem es verhindert, dass Ihr Shop innerhalb des iframes einer anderen Website geladen wird.
• Referrer-Policy — begrenzt, wie viele URL-Daten bei ausgehenden Klicks an Dritte gelangen.
• Permissions-Policy — verweigert standardmäßig Kamera, Mikrofon und Geolokalisierung, damit ein kompromittiertes Skript sie nicht heimlich anfordern kann.

Beachten Sie die bewusste Auslassung: Der alte X-XSS-Protection-Header ist veraltet und wird in aktuellen Browsern ignoriert (oder ist schädlich) — fügen Sie ihn nicht hinzu. Der Header, der als Nächstes hinzuzufügen lohnt, Content-Security-Policy, ist mächtig, aber damit lässt sich leicht ein PrestaShop-Theme kaputtmachen, daher gehört er in eine sorgfältige, getestete Einführung statt in ein Copy-and-paste. CSP ist außerdem Ihre stärkste Verteidigung gegen Karten-Skimmer auf der Zahlungsseite — die Mechanik dieses Angriffs finden Sie in der Anatomie eines Angriffs im Magecart-Stil.

Eine Sache kann .htaccess bewusst nicht gut: Ratenbegrenzung oder Geo-Blocking von missbräuchlichem Datenverkehr im großen Maßstab. Pauschale Deny from-IP-Listen in der .htaccess veralten schnell und stoppen keine verteilten Scanner. Für echte Besucherkontrolle — Bad-Bot-Filterung, IP-Sperren, Länderregeln — erledigen Sie das auf Anwendungs- oder Edge-Ebene: siehe das Blockieren bösartiger Bots und unerwünschten Datenverkehrs und, für Shops, die bereits unter der Last leiden, das Überstehen der ?q=-Crawler-Flut.

Performance-Regeln zum Hinzufügen

Dieselbe Datei ist der Ort, an dem Sie die beiden wirkungsstärksten Frontend-Geschwindigkeitsgewinne einschalten. Auch hier: außerhalb der Markierungen, jeweils mit <IfModule> umschlossen.

Gzip-/Deflate-Komprimierung

Text-Antworten — HTML, CSS, JS, JSON, SVG — komprimieren um etwa 60–80 %, sodass eine PrestaShop-Produktseite, die ~150 KB Markup ausliefert, den Server eher mit 40 KB verlassen kann. Was bedeutet das also für Sie? Schnellerer First Paint, geringere Absprungrate und ein besserer PageSpeed-Wert, ohne eine einzige Template-Änderung:

<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>

Viele Hoster aktivieren die Komprimierung bereits serverweit. Wenn Ihrer das tut, ist der oben mit <IfModule> umschlossene Block harmlos und schlicht redundant — mod_deflate komprimiert bereits komprimierte Ausgaben nicht doppelt. Wenn ein Hoster mod_deflate hinter AllowOverride gesperrt hat, ist der <IfModule>-Schutz das, was einen 500 verhindert; falls Sie nach dem Hinzufügen dennoch einen sehen, entfernen Sie den Block und überlassen Sie die Komprimierung global dem Server.

Browser-Caching (Expires-Header)

Dies weist den Browser eines wiederkehrenden Besuchers an, bereits vorhandene statische Assets wiederzuverwenden, statt sie erneut herunterzuladen — der größte verfügbare Gewinn beim erneuten Besuch. Lange Cache-Lebensdauern sind nur für Assets sicher, die versioniert oder mit einem Fingerprint versehen sind (PrestaShop und viele Themes/Module hängen einen Versions-Query-String an oder ändern Dateinamen, wenn Bundles neu erstellt werden); für alles andere verwenden Sie kürzere Lebensdauern oder bestätigen Sie, dass eine Cache-Busting-Strategie — ein Query-String- oder Dateiversions-Token — tatsächlich aktiv ist, bevor Sie einen langen Expires-Header hinzufügen, sonst kann eine veraltete CSS-/JS-Datei nach einem Update in Browsern hängen bleiben:

<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 und ETags — überlassen Sie sie dem Server

Keep-Alive (Wiederverwendung einer TCP-Verbindung für viele Assets) hilft jeder PrestaShop-Seite, da jede Dutzende Dateien lädt — aber es ist fast immer bereits auf Hoster-Ebene aktiviert, kämpfen Sie also nicht in der .htaccess dagegen an. ETags sind ähnlich: in Ordnung für einen Single-Server-Shop, gelegentlich ein Cache-Busting-Ärgernis bei Cluster- oder CDN-Setups (das CDN verwaltet sie meist für Sie). Die Faustregel: Fügen Sie keine Direktiven für Dinge hinzu, die Ihr Stack bereits erledigt — jede überflüssige Zeile ist eine weitere Chance für einen 500.

Häufige Fehler, die einen Shop offline nehmen

• Bearbeiten innerhalb der Markierungen. Eigene Regeln zwischen ~~start~~ und ~~end~~ werden bei der nächsten Neugenerierung gelöscht. Schreiben Sie immer außerhalb.
• Ungeschützte Komprimierungs- oder Header-Blöcke. Eine doppelte Definition auf einem Hoster, der bereits komprimiert, ist meist nur redundant — aber eine nicht umschlossene Header- oder AddOutputFilterByType-Zeile auf einem Hoster, bei dem das Modul nicht geladen ist, wirft einen 500. Umschließen Sie sie immer mit <IfModule> und entfernen Sie den Block, falls er weiterhin Konflikte verursacht.
• Falsche RewriteBase. Eine Unterordner-Installation (/shop/) mit RewriteBase / liefert bei jeder sprechenden URL einen 404.
• Fehlendes RewriteEngine On. Kopieren Sie Rewrite-Regeln aus einem generischen Leitfaden ohne diese Zeile und alles außer der Startseite liefert einen 404. (Der eigene Block von PrestaShop enthält sie — das trifft Leute, die Drittanbieter-Regeln einfügen.)
• Direktiven, die Ihr Hoster verbietet. Shared Hosts sperren oft php_value, Options und Header auf Serverebene (AllowOverride). Die Verwendung einer gesperrten Direktive liefert einen 500. Prüfen Sie das, bevor Sie etwas hinzufügen.

Wie man sich in unter einer Minute von einer kaputten .htaccess erholt

Die SEO-&-URLs-Liste zeigt jede Seite mit Seitenname, Seitentitel und sprechender URL.

Ein 500 auf jeder Seite nach dem Speichern fühlt sich katastrophal an; tatsächlich ist es eines der am schnellsten zu behebenden Probleme im Hosting, weil die Ursache stets die Datei ist, die Sie gerade angefasst haben. Drei Wege, der schnellste zuerst:

• FTP/SFTP. Verbinden Sie sich, benennen Sie .htaccess in .htaccess.broken um (oder löschen Sie sie). Der Shop kommt sofort zurück; nur sprechende URLs funktionieren nicht mehr, bis Sie sie neu generieren.
• Hosting-Dateimanager. Aktivieren Sie in cPanel oder Ihrem Panel Versteckte Dateien anzeigen (Dotfiles sind standardmäßig verborgen) und benennen oder reparieren Sie die Datei dann auf dieselbe Weise.
• Sauber aus dem Backoffice neu generieren. Sobald der Shop wieder läuft, gehen Sie zu Shop-Parameter → Datenverkehr & SEO → SEO & URLs, schalten Sie Sprechende URLs aus, speichern Sie, dann wieder ein und speichern Sie. PrestaShop schreibt eine frische, korrekte Standarddatei — Ihr Sicherheitsnetz für jede .htaccess-Katastrophe.

Die günstige Versicherung: cp .htaccess .htaccess.backup vor jeder Bearbeitung dauert eine Sekunde und rettet einen Abend. Noch besser: Nehmen Sie Änderungen zuerst auf Staging vor.

Testen, bevor Sie weggehen

• Klicken Sie die kritischen Pfade durch: Startseite, eine Kategorie, ein Produkt, den Warenkorb und den vollständigen Bestellvorgang — eine fehlerhafte Regel kann einen Seitentyp kaputtmachen und andere unberührt lassen.
• Überprüfen Sie die Geschwindigkeitsgewinne: Google PageSpeed Insights kennzeichnet, wenn Komprimierung oder Browser-Caching nicht tatsächlich greift.
• Überprüfen Sie die Header: lassen Sie Ihre Domain durch securityheaders.com laufen, um zu bestätigen, dass jeder Sicherheits-Header gesendet wird.

Häufig gestellte Fragen

Wo genau gehören meine eigenen Regeln in die .htaccess-Datei?

Außerhalb des von PrestaShop verwalteten Blocks — oberhalb der # ~~start~~-Markierung oder unterhalb der # ~~end~~-Markierung, niemals dazwischen. Der Markierungskommentar selbst sagt, dass PrestaShop den Code außerhalb des Blocks behält, wenn es die Datei neu generiert. Alles, was Sie zwischen die Markierungen setzen, wird beim nächsten Speichern der SEO-Einstellungen oder Ändern eines URL-Musters gelöscht.

Ich habe Regeln hinzugefügt und nun liefert jede Seite einen 500. Wie erhole ich mich am schnellsten?

Die Ursache ist stets die Datei, die Sie gerade angefasst haben. Verbinden Sie sich per FTP/SFTP (oder über den Dateimanager Ihres Hosters mit angezeigten versteckten Dateien), benennen Sie .htaccess in .htaccess.broken um, und der Shop kommt sofort zurück — nur sprechende URLs funktionieren nicht mehr, bis Sie sie neu generieren. Bringen Sie dann den Shop wieder hoch und generieren Sie eine saubere Datei aus Shop-Parameter → Datenverkehr & SEO → SEO & URLs neu, indem Sie die sprechenden URLs ausschalten, speichern, einschalten und erneut speichern.

Mein Hoster läuft unter Nginx — bewirken diese .htaccess-Regeln irgendetwas?

Nein. .htaccess ist eine Apache-Funktion und Nginx ignoriert sie vollständig. Dieselben Sicherheits- und Performance-Ideen gelten, aber die Direktiven stehen in Ihrem Server-Block, nicht in einer verzeichnisbezogenen Datei. Folgen Sie der offiziellen PrestaShop-Nginx-Konfiguration (oder dem Beispiel Ihres Hosters) für die Rewrite-Regeln und übersetzen Sie die Deny-/Header-/Komprimierungs-Regeln in location-Blöcke. Prüfen Sie Ihren Server:-Antwort-Header, um zu bestätigen, unter welchem Sie sind.

Verdoppeln sich Komprimierung und Expires-Header mit dem, was mein Hoster bereits tut?

Meist ist es harmlos. mod_deflate komprimiert bereits komprimierte Ausgaben nicht doppelt, ein redundanter Block sitzt also einfach da und tut nichts. Die Gefahr ist eine nicht umschlossene Direktive auf einem Hoster, bei dem das Modul nicht geladen ist — das wirft einen 500. Umschließen Sie Komprimierungs- und Header-Blöcke immer mit <IfModule>, und falls Sie dennoch einen Konflikt sehen, entfernen Sie den Block und überlassen Sie es global dem Server.

Sollte ich hier auch einen Content-Security-Policy-Header hinzufügen?

Nicht als Copy-and-paste. CSP ist Ihre stärkste Verteidigung gegen Karten-Skimmer auf der Zahlungsseite, aber eine zu strenge Richtlinie macht unbemerkt Theme-Skripte, Zahlungs-iframes und Analytics kaputt. Sie gehört in eine sorgfältige, getestete Einführung — bauen Sie sie zuerst im Report-only-Modus auf, beobachten Sie, was sie blockieren würde, und erzwingen Sie sie dann. Werfen Sie keine pauschale CSP-Zeile in die .htaccess und gehen Sie weg.

Wo .htaccess endet und Module beginnen

Richtig gemacht ist die .htaccess eine wirklich starke, kostenlose erste Schicht — sie schließt die Dateioffenlegungs-Lücken, nach denen Scanner suchen, und schaltet die Komprimierung und das Caching ein, die PrestaShop schnell wirken lassen. Aber sie ist ein grobes Werkzeug. Sie kann nicht darüber nachdenken, wer eine Anfrage stellt, kann einen Shop nach einem Einbruch nicht wiederherstellen und kann einen nicht aktualisierbaren Shop nicht gegen bekannte CVEs gepatcht halten. Das sind Aufgaben der Anwendungsebene:

• Feststecken auf einer alten Version, die Sie nicht aktualisieren können? Serverregeln patchen keinen verwundbaren Kern. Virtuelles Patchen schon — siehe fortgeschrittene Härtung für Shops, die Sie noch nicht aktualisieren können.
• Der Schutz der Admin- und Kunden-Logins (2FA, Passwortrichtlinie) liegt außerhalb des .htaccess-Bereichs — hier behandelt.
• Wenn das Schlimmste passiert, hilft Ihnen eine Header-Datei bei der Reaktion nicht — der Leitfaden zur Reaktion auf Datenpannen schon.

Auf der Performance-Seite gilt dieselbe Logik: handgeschriebene Expires- und Deflate-Regeln sind eine solide Grundlage, aber Full Page Caching, intelligente Minifizierung, Bildoptimierung und CDN-Integration sind das, was einen echten Shop von „in Ordnung“ zu schnell bewegt — und die gehören in ein gepflegtes Modul statt in eine ständig wachsende .htaccess. Das ist die Art von Arbeit, die wir bei mypresta.rocks leisten: die technische Tiefe für Sie erledigt, sodass die Geschwindigkeit und die Sorgenfreiheit Einstellungen in Ihrem Backoffice sind und nicht Zeilen, die Sie in einer Datei, die den ganzen Shop lahmlegen kann, exakt richtig hinbekommen müssen.