PrestaShop .htaccess : les règles de sécurité et de performance indispensables

Le fichier .htaccess est à la fois le plus puissant — et le plus discrètement dangereux — d’une installation PrestaShop. Quelques lignes bien placées bloquent les robots qui scannent les fichiers et pilonnent chaque boutique exposée sur Internet, allègent chaque page de quelques kilo-octets et empêchent la diffusion de fichiers sensibles. Le même fichier, modifié sans précaution, renvoie une 500 Internal Server Error sur toutes les URL et met toute votre boutique hors ligne jusqu’à ce que vous puissiez accéder à un client FTP. La plupart des marchands ne l’ouvrent jamais. Ce guide vous montre comment l’ouvrir volontairement, savoir exactement quelles lignes ajouter, où les placer pour que PrestaShop n’écrase pas votre travail, et comment remettre la boutique en ligne en soixante secondes si quelque chose se passe mal.

Dernière mise à jour : juin 2026.

Cet article est le volet règles et configuration de cette série : les directives concrètes à coller dans .htaccess. La stratégie plus large — ce qu’il faut durcir en premier, comment penser toute votre surface d’attaque — se trouve dans la checklist complète de durcissement de la sécurité, et la version sans jargon pour les propriétaires non techniques est le guide en langage clair. Ici, nous restons au niveau du fichier.

Ce qu’est .htaccess, et le fait qui sauve votre boutique

.htaccess ("hypertext access") est un fichier de configuration par répertoire pour le serveur web Apache. PrestaShop le crée pour vous la première fois que vous activez les URL simplifiées dans Paramètres de la boutique → Trafic & SEO → SEO & URLs, puis le réécrit chaque fois que vous activez/désactivez ce réglage ou modifiez un schéma d’URL. Cette génération automatique est précisément ce qui vous protège : si vous cassez un jour le fichier, vous pouvez régénérer un fichier par défaut propre depuis le back-office en deux clics (nous y revenons à la fin).

Une mise en garde avant de toucher quoi que ce soit : .htaccess ne fonctionne que sur Apache. Une part croissante des hébergements PrestaShop fonctionne sous Nginx (ou Apache derrière Nginx), où les fichiers .htaccess sont totalement ignorés. Si vous êtes sur Nginx, les principes de sécurité et de performance ci-dessous sont identiques, mais la syntaxe se place dans votre bloc site/serveur, pas dans un fichier par répertoire — partez de la documentation officielle de configuration Nginx pour PrestaShop (ou de l’exemple fourni par votre hébergeur) pour les règles de réécriture. Vous ne savez pas sur quoi vous êtes ? Une ligne Server: Apache ou Server: nginx dans vos en-têtes de réponse vous le dira immédiatement.

La règle d’or : écrivez en dehors des marqueurs PrestaShop

Ouvrez le fichier et vous trouverez le bloc géré par PrestaShop encadré par des marqueurs de commentaire :

Le commentaire du marqueur est explicite : PrestaShop conserve le code en dehors de ce commentaire lorsqu’il régénère le fichier. Vos règles personnalisées de sécurité et de performance doivent donc être placées au-dessus du marqueur ~~start~~ ou sous le marqueur ~~end~~ — jamais entre les deux. Cette seule habitude fait la différence entre des règles qui survivent à chaque clic sur « enregistrer les paramètres SEO » et des règles qui disparaissent silencieusement mardi prochain.

Ce que le bloc par défaut de PrestaShop fait déjà (n’y touchez pas)

Avant d’ajouter quoi que ce soit, il est utile de savoir ce qui est déjà pris en charge dans le bloc géré, afin de ne pas le dupliquer et provoquer des conflits :

• Réécriture d’URL — le grand ensemble de RewriteRule qui transforme /123-nike-air-max en quelque chose que index.php peut router. Géré par PrestaShop ; à ne jamais modifier à la main.
• Options -MultiViews — empêche Apache de négocier le contenu d’une requête pour /about vers un éventuel about.html au lieu de laisser le routeur de PrestaShop la traiter.
• DirectoryIndex index.php — garantit que le contrôleur frontal s’exécute lorsqu’un répertoire est demandé.
• RewriteBase — défini sur / pour une installation à la racine, ou /shop/ si PrestaShop se trouve dans un sous-dossier. Si cette valeur est mauvaise, toutes les URL simplifiées renvoient une 404.
• Surcharges de valeurs PHP chez certains hébergeurs (limite mémoire, taille d’envoi) — ajoutées lorsque vous ne pouvez pas modifier directement php.ini.

Tout cela est correct dès l’installation. Votre rôle consiste à ajouter la couche que PrestaShop ne fournit pas : le durcissement et la mise en cache.

Règles de sécurité à ajouter (au-dessus du marqueur)

Le fichier par défaut de PrestaShop est fonctionnel, pas durci. Voici les règles qui ferment de vraies failles régulièrement scannées. Collez-les avant le marqueur ~~start~~.

1. Bloquer l’accès direct aux fichiers sensibles

Placez ceci au-dessus du marqueur géré par PrestaShop sur 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>

Une arborescence PrestaShop contient des fichiers qui ne doivent jamais être servis à un navigateur : configuration YAML, journaux, exports SQL, modèles Twig et Smarty bruts. Si un robot peut faire un GET /app/config/parameters.yml, il peut lire vos identifiants de base de données. Refusez les extensions dangereuses :

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

(Sur les anciens hébergements Apache 2.2, remplacez Require all denied par Order deny,allow / Deny from all — votre hébergeur pourra vous confirmer la version d’Apache utilisée.) PrestaShop dépose déjà des fichiers index.php factices dans de nombreux dossiers, mais un refus explicite par extension couvre les fichiers que ces garde-fous ne protègent pas.

2. Verrouiller par nom les fichiers de configuration à haute valeur

Deux fichiers méritent un bloc nommé en plus, par sécurité renforcée, car ce sont les joyaux de la couronne : l’ancien config/settings.inc.php (1.6) et le moderne app/config/parameters.php (1.7–9). Ce sont des fichiers PHP, donc Apache ne les affichera pas — mais un serveur mal configuré ou une copie .bak peut les exposer. Refusez tout le lot :

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

3. Bloquer l’exposition de .git et .env

Si vous déployez avec Git (ce que vous devriez faire), un répertoire /.git/ consultable donne à un attaquant tout votre historique source — y compris les identifiants présents dans d’anciens commits. Même problème avec un fichier .env oublié :

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

4. Empêcher le listing des répertoires

Sans cela, toute personne qui ouvre /upload/ ou /download/ dans son navigateur voit un index de fichiers cliquable — une fuite d’information classique. Une seule ligne le ferme partout :

Options -Indexes

5. Ajouter des en-têtes de sécurité

Les en-têtes de réponse HTTP indiquent au navigateur d’activer ses propres défenses. Ceux-ci nécessitent le module Apache mod_headers (presque toujours présent) ; encadrez-les dans un <IfModule> afin qu’un hébergeur qui ne l’a pas activé ne renvoie pas une 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 — empêche le navigateur de deviner le type d’un fichier et d’exécuter un téléversement comme un script.
• X-Frame-Options: SAMEORIGIN — bloque le détournement de clic en refusant que votre boutique se charge dans l’iframe d’un autre site.
• Referrer-Policy — limite la quantité de données d’URL transmises à des tiers lors des clics sortants.
• Permissions-Policy — refuse par défaut la caméra, le micro et la géolocalisation, afin qu’un script compromis ne puisse pas les demander discrètement.

Notez l’omission volontaire : l’ancien en-tête X-XSS-Protection est obsolète et ignoré (voire nuisible) dans les navigateurs actuels — ne l’ajoutez pas. L’en-tête qu’il vaut la peine d’ajouter ensuite, Content-Security-Policy, est puissant mais peut facilement casser un thème PrestaShop ; il doit donc faire l’objet d’un déploiement prudent et testé, pas d’un copier-coller. CSP est aussi votre défense la plus forte contre les skimmers de cartes sur les pages de paiement — les mécanismes de cette attaque sont expliqués dans l’anatomie d’une attaque de type Magecart.

Une chose que .htaccess ne sait volontairement pas bien faire : limiter le débit ou bloquer géographiquement un trafic abusif à grande échelle. Les listes d’IP en Deny from dans .htaccess vieillissent vite et n’arrêtent pas les scanners distribués. Pour un vrai contrôle des visiteurs — filtrage des mauvais robots, bannissements d’IP, règles par pays — traitez-le au niveau de l’application ou de la périphérie : voir comment bloquer les mauvais robots et le trafic indésirable et, pour les boutiques déjà sous pression, comment survivre à l’inondation de robots ?q=.

Règles de performance à ajouter

Le même fichier permet d’activer les deux gains de vitesse front-end les plus rentables. Là encore : en dehors des marqueurs, et chaque bloc encadré par <IfModule>.

Compression Gzip / Deflate

Les réponses textuelles — HTML, CSS, JS, JSON, SVG — se compressent d’environ 60 à 80 %, si bien qu’une page produit PrestaShop qui envoie environ 150 Ko de balisage peut quitter le serveur autour de 40 Ko. Concrètement, qu’est-ce que cela change pour vous ? Un premier affichage plus rapide, moins de rebond et un meilleur score PageSpeed, sans modifier le moindre modèle :

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

De nombreux hébergeurs activent déjà la compression à l’échelle du serveur. Si c’est le cas du vôtre, le bloc ci-dessus, protégé par <IfModule>, est inoffensif et simplement redondant — mod_deflate ne recompressera pas une sortie déjà compressée. Si un hébergeur a verrouillé mod_deflate derrière AllowOverride, la garde <IfModule> évite une 500 ; si vous en voyez malgré tout une après l’ajout, supprimez le bloc et laissez le serveur gérer la compression globalement.

Cache navigateur (en-têtes Expires)

Cela indique au navigateur d’un visiteur qui revient de réutiliser les ressources statiques qu’il possède déjà au lieu de les télécharger à nouveau — le plus gros gain possible pour les visites répétées. Les longues durées de cache ne sont sûres que pour les ressources versionnées ou empreintées (PrestaShop et de nombreux thèmes/modules ajoutent une chaîne de version dans l’URL ou changent les noms de fichiers lorsque les bundles sont reconstruits) ; pour tout ce qui ne l’est pas, utilisez des durées plus courtes ou vérifiez qu’une stratégie de purge du cache — une chaîne de requête ou un jeton de version de fichier — est réellement active avant d’ajouter un long en-tête Expires, sinon un ancien fichier CSS/JS peut rester dans les navigateurs après une mise à jour :

<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 et ETags — laissez-les au serveur

Keep-Alive (réutiliser une même connexion TCP pour de nombreuses ressources) aide chaque page PrestaShop, puisqu’elles chargent toutes des dizaines de fichiers — mais il est presque toujours déjà activé au niveau de l’hébergeur, donc inutile de le combattre dans .htaccess. Les ETags sont comparables : très bien pour une boutique sur un seul serveur, parfois gênants pour l’invalidation du cache sur des configurations en cluster ou avec CDN (le CDN les gère généralement pour vous). La règle pratique : n’ajoutez pas de directives pour des choses que votre pile traite déjà — chaque ligne redondante est une nouvelle occasion de produire une 500.

Erreurs courantes qui mettent une boutique hors ligne

• Modifier à l’intérieur des marqueurs. Les règles personnalisées entre ~~start~~ et ~~end~~ sont effacées à la prochaine régénération. Écrivez toujours en dehors.
• Blocs de compression ou d’en-têtes non protégés. Une définition en double chez un hébergeur qui compresse déjà est généralement seulement redondante — mais une ligne non encadrée Header ou AddOutputFilterByType chez un hébergeur où le module n’est pas chargé déclenche une 500. Encadrez toujours avec <IfModule>, et supprimez le bloc s’il entre encore en conflit.
• Mauvais RewriteBase. Une installation en sous-dossier (/shop/) avec RewriteBase / renvoie une 404 sur toutes les URL simplifiées.
• RewriteEngine On manquant. Copiez des règles de réécriture depuis un guide générique sans cette ligne, et tout sauf la page d’accueil renvoie une 404. (Le bloc propre à PrestaShop l’inclut — cela piège les personnes qui collent des règles tierces.)
• Directives interdites par votre hébergeur. Les hébergements mutualisés verrouillent souvent php_value, Options et Header au niveau du serveur (AllowOverride). Utiliser une directive verrouillée renvoie une 500. Vérifiez avant d’ajouter.

Comment récupérer un .htaccess cassé en moins d’une minute

La liste SEO et URL affiche chaque page avec son nom, son titre et son URL simplifiée.

Une 500 sur toutes les pages après un enregistrement semble catastrophique ; c’est en réalité l’un des problèmes d’hébergement les plus rapides à corriger, car la cause est toujours le fichier que vous venez de toucher. Trois solutions, de la plus rapide à la moins rapide :

• FTP/SFTP. Connectez-vous, renommez .htaccess en .htaccess.broken (ou supprimez-le). La boutique revient instantanément ; seules les URL simplifiées cessent de fonctionner jusqu’à la régénération.
• Gestionnaire de fichiers de l’hébergement. Dans cPanel ou votre panneau, activez Show Hidden Files (les fichiers commençant par un point sont masqués par défaut), puis renommez ou corrigez le fichier de la même manière.
• Régénération propre depuis le back-office. Une fois la boutique de nouveau accessible, allez dans Paramètres de la boutique → Trafic & SEO → SEO & URLs, désactivez les URL simplifiées, enregistrez, réactivez-les, puis enregistrez encore. PrestaShop écrit un nouveau fichier par défaut, propre et correct — votre filet de sécurité pour toute catastrophe .htaccess.

L’assurance bon marché : cp .htaccess .htaccess.backup avant toute modification prend une seconde et vous évite une soirée perdue. Mieux encore, faites d’abord les changements sur un environnement de préproduction.

Testez avant de passer à autre chose

• Cliquez les parcours critiques : page d’accueil, catégorie, produit, panier et tunnel de commande complet — une mauvaise règle peut casser un type de page et laisser les autres fonctionner.
• Vérifiez les gains de vitesse : Google PageSpeed Insights signalera si la compression ou le cache navigateur ne s’active pas réellement.
• Vérifiez les en-têtes : passez votre domaine dans securityheaders.com pour confirmer que chaque en-tête de sécurité est bien envoyé.

Questions fréquentes

Où placer exactement mes règles personnalisées dans le fichier .htaccess ?

En dehors du bloc géré par PrestaShop — au-dessus du marqueur # ~~start~~ ou sous le marqueur # ~~end~~, jamais entre les deux. Le commentaire du marqueur lui-même indique que PrestaShop conserve le code en dehors du bloc lorsqu’il régénère le fichier. Tout ce que vous placez entre les marqueurs sera effacé la prochaine fois que vous enregistrerez les paramètres SEO ou modifierez un schéma d’URL.

J’ai ajouté des règles et toutes les pages renvoient maintenant une 500. Comment récupérer au plus vite ?

La cause est toujours le fichier que vous venez de toucher. Connectez-vous en FTP/SFTP (ou via le gestionnaire de fichiers de votre hébergeur avec les fichiers cachés affichés), renommez .htaccess en .htaccess.broken, et la boutique revient instantanément — seules les URL simplifiées cessent de fonctionner jusqu’à la régénération. Ensuite, remettez la boutique en ligne et régénérez un fichier propre depuis Paramètres de la boutique → Trafic & SEO → SEO & URLs en désactivant les URL simplifiées, en enregistrant, puis en les réactivant et en enregistrant de nouveau.

Mon hébergeur utilise Nginx — ces règles .htaccess servent-elles à quelque chose ?

Non. .htaccess est une fonctionnalité Apache et Nginx l’ignore entièrement. Les mêmes principes de sécurité et de performance s’appliquent, mais les directives se placent dans votre bloc serveur, pas dans un fichier par répertoire. Suivez la configuration Nginx officielle de PrestaShop (ou l’exemple fourni par votre hébergeur) pour les règles de réécriture, et traduisez les règles de refus/en-têtes/compression en blocs location. Vérifiez l’en-tête de réponse Server: pour confirmer sur lequel vous êtes.

L’ajout de la compression et des en-têtes Expires fera-t-il doublon avec ce que mon hébergeur fait déjà ?

En général, c’est inoffensif. mod_deflate ne recompresse pas une sortie déjà compressée, donc un bloc redondant reste simplement sans effet. Le danger vient d’une directive non encadrée chez un hébergeur où le module n’est pas chargé — cela déclenche une 500. Encadrez toujours les blocs de compression et d’en-têtes avec <IfModule>, et si vous constatez encore un conflit, supprimez le bloc et laissez le serveur s’en charger globalement.

Dois-je aussi ajouter ici un en-tête Content-Security-Policy ?

Pas en copier-coller. CSP est votre meilleure défense contre les skimmers de cartes sur les pages de paiement, mais une politique trop stricte casse silencieusement les scripts du thème, les iframes de paiement et l’analytics. Elle doit être déployée prudemment et testée — commencez en mode report-only, observez ce qui serait bloqué, puis appliquez-la. Ne collez pas une ligne CSP générique dans .htaccess avant de passer à autre chose.

Là où .htaccess s’arrête et où les modules commencent

Bien utilisé, .htaccess est une première couche gratuite réellement solide — il ferme les failles d’exposition de fichiers que les scanners recherchent et active la compression et le cache qui donnent à PrestaShop une sensation de rapidité. Mais c’est un instrument brut. Il ne peut pas raisonner sur qui effectue une requête, ne peut pas remettre une boutique sur pied après une compromission, et ne peut pas maintenir une boutique impossible à mettre à niveau protégée contre des CVE connues. Ce sont des tâches de la couche applicative :

• Bloqué sur une ancienne version que vous ne pouvez pas mettre à niveau ? Les règles serveur ne corrigeront pas un cœur vulnérable. Le patching virtuel, si — voir le durcissement avancé pour les boutiques que vous ne pouvez pas encore mettre à niveau.
• Protéger les connexions administrateur et client (2FA, politique de mot de passe) dépasse le périmètre de .htaccess — c’est couvert ici.
• Si le pire arrive, un fichier d’en-têtes ne vous aidera pas à réagir — le plan de réponse à une violation de données, oui.

Côté performance, la même logique s’applique : des règles Expires et Deflate écrites à la main constituent une bonne base, mais le cache pleine page, la minification intelligente, l’optimisation des images et l’intégration CDN sont ce qui fait passer une vraie boutique de « correcte » à rapide — et cela relève d’un module maintenu plutôt que d’un .htaccess toujours plus long. C’est le type de travail que nous réalisons chez mypresta.rocks : la profondeur technique est prise en charge pour vous, afin que la vitesse et la tranquillité d’esprit soient des réglages dans votre back-office, pas des lignes à écrire parfaitement dans un fichier capable de mettre toute la boutique hors ligne.