Il file .htaccess è il file più potente, e più silenziosamente pericoloso, di un’installazione PrestaShop. Poche righe inserite nel punto giusto bloccano i bot che scansionano i file e martellano ogni negozio esposto su internet, riducono di qualche kilobyte ogni pagina e impediscono che file sensibili vengano mai serviti. Lo stesso file, modificato con leggerezza, restituisce un 500 Internal Server Error su ogni URL e mette offline l’intero negozio finché non riesci ad accedere via FTP. La maggior parte dei commercianti non lo apre mai. Questa guida serve proprio ad aprirlo con criterio, sapere esattamente quali righe aggiungere, dove inserirle perché PrestaShop non sovrascriva il tuo lavoro e come tornare online in sessanta secondi se qualcosa va storto.
Ultimo aggiornamento: giugno 2026.
Questo è l’articolo del cluster dedicato a regole e configurazione: le direttive concrete da incollare in .htaccess. La strategia più ampia, cosa mettere in sicurezza per primo, come ragionare sull’intera superficie d’attacco, è nella checklist completa per l’hardening della sicurezza, mentre la versione senza gergo per titolari non tecnici è la guida in linguaggio semplice. Qui restiamo al livello del file.
Che cos’è .htaccess, e il fatto che salva il tuo negozio
.htaccess ("hypertext access") è un file di configurazione per directory del server web Apache. PrestaShop lo scrive per te la prima volta che abiliti gli URL semplificati in Parametri negozio → Traffico & SEO → SEO & URL, e lo riscrive ogni volta che attivi o disattivi quell’impostazione o modifichi un pattern URL. Questa generazione automatica è il fatto che ti salva: se rompi il file, puoi rigenerare un default pulito dal back office in due clic (lo vediamo alla fine).
Una precisazione prima di toccare qualunque cosa: .htaccess funziona solo su Apache. Una quota crescente di hosting PrestaShop usa Nginx (o Apache dietro Nginx), dove i file .htaccess vengono ignorati del tutto. Se sei su Nginx, le idee di sicurezza e prestazioni qui sotto sono identiche, ma la sintassi vive nel tuo blocco site/server, non in un file per directory, parti dalla documentazione ufficiale di configurazione Nginx per PrestaShop (o dall’esempio fornito dal tuo hosting) per le regole di riscrittura. Non sai quale server stai usando? Una riga come Server: Apache o Server: nginx negli header di risposta te lo dice subito.
La regola d’oro: scrivi fuori dai marker di PrestaShop
Apri il file e troverai il blocco gestito da PrestaShop racchiuso tra commenti marker:
| Cosa vedi | Cosa significa |
|---|---|
# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again | Tutto ciò che va da qui a ~~end~~ appartiene a PrestaShop. Riscritture degli URL semplificati, MultiViews e regole del front controller vivono tutte qui dentro. Non modificare mai questo blocco a mano, PrestaShop lo sovrascrive alla prossima rigenerazione e le tue modifiche spariscono. |
# ~~end~~ Do not remove this comment | Fine del blocco gestito. |
Il commento marker è esplicito: PrestaShop mantiene il codice fuori da questo commento quando rigenera il file. Quindi le tue regole personalizzate di sicurezza e prestazioni vanno sopra il marker ~~start~~ o sotto il marker ~~end~~, mai tra i due. Questa singola abitudine fa la differenza tra regole che sopravvivono a ogni clic su "salva impostazioni SEO" e regole che spariscono in silenzio martedì prossimo.
Cosa fa già il blocco predefinito di PrestaShop (lascialo com’è)
Prima di aggiungere qualsiasi cosa, vale la pena sapere cosa viene già gestito dentro il blocco controllato da PrestaShop, così eviti duplicazioni e conflitti:
- Riscrittura degli URL, il grande set di
RewriteRuleche trasforma/123-nike-air-maxin qualcosa cheindex.phppuò instradare. È gestito da PrestaShop; non va mai toccato a mano. Options -MultiViews, impedisce ad Apache di fare content negotiation su una richiesta per/aboute servirla come un eventualeabout.html, invece di lasciare che sia il router di PrestaShop a gestirla.DirectoryIndex index.php, assicura che il front controller venga eseguito quando viene richiesta una directory.- RewriteBase, impostato a
/per un’installazione nella root, oppure a/shop/se PrestaShop vive in una sottocartella. Sbaglialo e ogni URL semplificato restituirà 404. - Override dei valori PHP su alcuni hosting (limite di memoria, dimensione upload), aggiunti quando non puoi modificare direttamente
php.ini.
Tutto questo è corretto così com’è. Il tuo compito è aggiungere lo strato che PrestaShop non include: hardening e cache.
Regole di sicurezza da aggiungere (sopra il marker)
Il file predefinito di PrestaShop è funzionale, non rafforzato. Queste sono le regole che chiudono falle reali e regolarmente scansionate. Incollale prima del marker ~~start~~.
1. Blocca l’accesso diretto ai file sensibili
Inserisci questo sopra il marker gestito da PrestaShop su 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>Un albero PrestaShop contiene file che non dovrebbero mai essere serviti a un browser: configurazioni YAML, log, dump SQL, template Twig e Smarty grezzi. Se un bot può fare GET /app/config/parameters.yml, può leggere le credenziali del tuo database. Nega le estensioni pericolose:
<FilesMatch "\.(yml|yaml|log|tpl|twig|sql|md|dist|neon|ini)$">
Require all denied
</FilesMatch>(Su hosting più vecchi con Apache 2.2, sostituisci Require all denied con Order deny,allow / Deny from all. Il tuo hosting può dirti quale versione di Apache stai usando.) PrestaShop inserisce già stub index.php in molte cartelle, ma un deny esplicito sulle estensioni copre i file che quegli stub non intercettano.
2. Blocca per nome i file di configurazione più preziosi
Due file meritano un blocco nominale con cintura e bretelle perché sono i gioielli della corona: il legacy config/settings.inc.php (1.6) e il moderno app/config/parameters.php (1.7–9). Sono file PHP, quindi Apache non dovrebbe stamparli, ma un server configurato male o una copia .bak possono esporli. Nega tutto il gruppo:
<FilesMatch "(parameters\.(php|yml)|settings\.inc\.php|.*\.bak)$">
Require all denied
</FilesMatch>3. Blocca l’esposizione di .git e .env
Se distribuisci con Git (dovresti), una directory /.git/ navigabile consegna a un attaccante l’intera cronologia del sorgente, comprese credenziali finite in vecchi commit. Stessa storia per un file .env lasciato in giro:
RedirectMatch 404 /\.git
<FilesMatch "^\.env">
Require all denied
</FilesMatch>4. Impedisci il listing delle directory
Senza questa regola, chiunque punti il browser su /upload/ o /download/ vede un indice cliccabile dei file, una fuga di informazioni da manuale. Una riga lo disattiva ovunque:
Options -Indexes
5. Aggiungi gli header di sicurezza
Gli header di risposta HTTP dicono al browser di attivare le proprie difese. Richiedono il mod_headers di Apache (quasi sempre presente); racchiudili in un <IfModule> così un hosting che ne è privo non genera un 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, impedisce al browser di indovinare il tipo di un file ed eseguire un upload come script.
- X-Frame-Options: SAMEORIGIN, blocca il clickjacking rifiutando il caricamento del tuo negozio dentro l’iframe di un altro sito.
- Referrer-Policy, limita la quantità di dati URL che trapelano verso terze parti sui clic in uscita.
- Permissions-Policy, nega per impostazione predefinita camera, microfono e geolocalizzazione, così uno script compromesso non può richiederli in silenzio.
Nota l’omissione intenzionale: il vecchio header X-XSS-Protection è deprecato e ignorato (o dannoso) nei browser attuali, non aggiungerlo. L’header che vale la pena aggiungere dopo, Content-Security-Policy, è potente ma può rompere facilmente un tema PrestaShop, quindi appartiene a un rollout prudente e testato, non a un copia-incolla. CSP è anche la tua difesa più forte contro gli skimmer di carte nelle pagine di pagamento. La meccanica di quell’attacco è spiegata nell’anatomia di un attacco in stile Magecart.
Una cosa che .htaccess volutamente non fa bene: limitare il ritmo delle richieste o bloccare traffico abusivo per area geografica su larga scala. Liste IP generiche con Deny from in .htaccess invecchiano in fretta e non fermano gli scanner distribuiti. Per un vero controllo dei visitatori, filtro dei bot malevoli, ban IP, regole per Paese, gestiscilo a livello applicativo o edge: vedi come bloccare bot malevoli e traffico indesiderato e, per i negozi già sotto pressione, come sopravvivere al flood dei crawler su ?q=.
Regole di prestazioni da aggiungere
Lo stesso file è il punto in cui attivi i due interventi front-end con il miglior rapporto impatto/sforzo. Anche qui: fuori dai marker, ciascuno racchiuso in <IfModule>.
Compressione Gzip / Deflate
Le risposte testuali, HTML, CSS, JS, JSON, SVG, si comprimono di circa il 60–80%, quindi una pagina prodotto PrestaShop che invia ~150 KB di markup può uscire dal server intorno ai 40 KB. Cosa significa concretamente per te? First paint più rapido, meno abbandoni e un punteggio PageSpeed migliore, senza modificare un solo template:
<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>Molti hosting abilitano già la compressione a livello server. Se il tuo lo fa, il blocco sopra racchiuso in <IfModule> è innocuo e semplicemente ridondante, mod_deflate non comprime due volte un output già compresso. Se un hosting ha bloccato mod_deflate dietro AllowOverride, la guardia <IfModule> è ciò che evita un 500; se dopo averlo aggiunto ne vedi comunque uno, rimuovi il blocco e lascia che sia il server a gestire globalmente la compressione.
Cache del browser (header Expires)
Questa regola dice al browser di un visitatore di ritorno di riutilizzare gli asset statici che ha già, invece di scaricarli di nuovo, il maggior vantaggio disponibile per le visite ripetute. Durate di cache lunghe sono sicure solo per asset versionati o fingerprinted (PrestaShop e molti temi/moduli aggiungono una query string di versione o cambiano i nomi dei file quando i bundle vengono ricostruiti); per tutto ciò che non lo è, usa durate più brevi o verifica che una strategia di cache busting, una query string o un token di versione file, sia davvero attiva prima di aggiungere un header Expires lungo, altrimenti un file CSS/JS obsoleto può restare nei browser dopo un aggiornamento:
<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>| Asset | Durata suggerita | Perché |
|---|---|---|
| Immagini (jpg/png/webp) | 1 anno | Cambiano raramente; una nuova immagine riceve comunque un nuovo nome file. |
| Font (woff2) | 1 anno | Di fatto non cambiano mai. |
| CSS / JS | 1 mese | Sicuro quando sono versionati/cache-busted; accorcia o verifica il busting se non lo sono. |
| HTML | Non mettere in cache | Prezzi, disponibilità e contenuti del carrello cambiano continuamente. |
Keep-Alive ed ETag, lasciali al server
Keep-Alive (riutilizzare una connessione TCP per molti asset) aiuta ogni pagina PrestaShop, visto che ciascuna carica decine di file, ma quasi sempre è già attivo a livello hosting, quindi non combatterlo in .htaccess. Gli ETag sono simili: vanno bene per un negozio su server singolo, ma a volte sono un fastidio per il cache busting su cluster o configurazioni CDN (di solito è la CDN a gestirli per te). La regola pratica: non aggiungere direttive per cose che il tuo stack gestisce già. Ogni riga ridondante è un’altra possibilità di generare un 500.
Errori comuni che mettono offline un negozio
- Modificare dentro i marker. Le regole personalizzate tra
~~start~~e~~end~~vengono cancellate alla rigenerazione successiva. Scrivi sempre fuori. - Blocchi di compressione o header non protetti. Una definizione duplicata su un hosting che comprime già di solito è solo ridondante, ma una riga non racchiusa
HeaderoAddOutputFilterByTypesu un hosting in cui il modulo non è caricato genera un 500. Racchiudi sempre in<IfModule>, e rimuovi il blocco se continua a creare conflitti. - RewriteBase errato. Un’installazione in sottocartella (
/shop/) conRewriteBase /restituisce 404 su ogni URL semplificato. RewriteEngine Onmancante. Copia regole di rewrite da una guida generica senza questa riga e tutto tranne la homepage restituisce 404. (Il blocco di PrestaShop la include già, questo problema colpisce chi incolla regole di terze parti.)- Direttive vietate dal tuo hosting. Gli hosting condivisi spesso bloccano
php_value,OptionseHeadera livello server (AllowOverride). Usare una direttiva bloccata restituisce 500. Controlla prima di aggiungere.
Come recuperare un .htaccess rotto in meno di un minuto
L'elenco SEO e URL mostra ogni pagina con il nome, il titolo e l'URL semplificato.
Un 500 su ogni pagina dopo un salvataggio sembra catastrofico; in realtà è uno dei problemi di hosting più rapidi da risolvere, perché la causa è sempre il file che hai appena toccato. Tre strade, dalla più veloce:
- FTP/SFTP. Collegati, rinomina
.htaccessin.htaccess.broken(oppure eliminalo). Il negozio torna subito online; smettono di funzionare solo gli URL semplificati finché non rigeneri il file. - File Manager dell’hosting. In cPanel o nel tuo pannello, abilita Mostra file nascosti (i dotfile sono nascosti per impostazione predefinita), poi rinomina o correggi il file nello stesso modo.
- Rigenera un file pulito dal back office. Quando il negozio è di nuovo online, vai in Parametri negozio → Traffico & SEO → SEO & URL, disattiva gli URL semplificati, salva, poi riattivali e salva di nuovo. PrestaShop scrive un file predefinito nuovo e corretto, la tua rete di sicurezza per qualunque disastro .htaccess.
L’assicurazione a costo zero: cp .htaccess .htaccess.backup prima di qualsiasi modifica richiede un secondo e salva una serata. Meglio ancora, fai prima le modifiche su staging.
Testa prima di andartene
- Clicca i percorsi critici: homepage, una categoria, un prodotto, carrello e l’intero pagamento. Una regola sbagliata può rompere un tipo di pagina e lasciarne intatti altri.
- Verifica i miglioramenti di velocità: Google PageSpeed Insights segnalerà se compressione o cache del browser non stanno davvero funzionando.
- Verifica gli header: esegui un controllo del tuo dominio su securityheaders.com per confermare che ogni header di sicurezza venga inviato.
Domande frequenti
Dove vanno esattamente le mie regole personalizzate nel file .htaccess?
Fuori dal blocco gestito da PrestaShop, sopra il marker # ~~start~~ o sotto il marker # ~~end~~, mai tra i due. Lo stesso commento marker dice che PrestaShop mantiene il codice fuori dal blocco quando rigenera il file. Tutto ciò che inserisci tra i marker viene cancellato la volta successiva in cui salvi le impostazioni SEO o cambi un pattern URL.
Ho aggiunto regole e ora ogni pagina restituisce un 500. Qual è il recupero più veloce?
La causa è sempre il file che hai appena toccato. Collegati via FTP/SFTP (o usa il File Manager del tuo hosting con i file nascosti visibili), rinomina .htaccess in .htaccess.broken e il negozio torna subito online, smettono di funzionare solo gli URL semplificati finché non rigeneri. Poi riporta il negozio in piena operatività e rigenera un file pulito da Parametri negozio → Traffico & SEO → SEO & URL disattivando gli URL semplificati, salvando, riattivandoli e salvando di nuovo.
Il mio hosting usa Nginx. Queste regole .htaccess fanno qualcosa?
No. .htaccess è una funzione di Apache e Nginx lo ignora completamente. Le stesse idee di sicurezza e prestazioni valgono comunque, ma le direttive vivono nel blocco server, non in un file per directory. Parti dalla configurazione ufficiale Nginx per PrestaShop (o dall’esempio del tuo hosting) per le regole di riscrittura, e traduci le regole deny/header/compression in blocchi location. Controlla l’header di risposta Server: per confermare su quale server sei.
Aggiungere compressione e header Expires rischia di duplicare ciò che fa già il mio hosting?
Di solito è innocuo. mod_deflate non comprime due volte un output già compresso, quindi un blocco ridondante resta lì senza fare nulla. Il pericolo è una direttiva non racchiusa su un hosting in cui il modulo non è caricato, quella genera un 500. Racchiudi sempre i blocchi di compressione e header in <IfModule>, e se vedi ancora un conflitto, rimuovi il blocco e lascia che il server lo gestisca globalmente.
Dovrei aggiungere qui anche un header Content-Security-Policy?
Non con un copia-incolla. CSP è la tua difesa più forte contro gli skimmer di carte nelle pagine di pagamento, ma una policy troppo rigida rompe in silenzio script del tema, iframe dei pagamenti e analytics. Va inserita con un rollout attento e testato, prima costruiscila in modalità report-only, osserva cosa bloccherebbe, poi applicala. Non buttare una riga CSP generica in .htaccess per poi andartene.
Dove finisce .htaccess e iniziano i moduli
Fatto bene, .htaccess è un primo livello gratuito davvero solido, chiude le falle di esposizione dei file cercate dagli scanner e attiva compressione e cache che fanno percepire PrestaShop più veloce. Ma è uno strumento poco fine. Non può ragionare su chi sta facendo una richiesta, non può recuperare un negozio dopo una violazione e non può mantenere patchato contro CVE note un negozio che non puoi aggiornare. Questi sono compiti del livello applicativo:
- Bloccato su una vecchia versione che non puoi aggiornare? Le regole server non patchano un core vulnerabile. Il virtual patching sì, vedi l’hardening avanzato per negozi che non puoi ancora aggiornare.
- Proteggere login admin e clienti (2FA, policy password) è fuori dall’ambito di .htaccess, lo trattiamo qui.
- Se succede il peggio, un file di header non ti aiuterà a rispondere, lo farà il playbook di risposta a una violazione.
Per il lato prestazioni vale la stessa logica: regole Expires e Deflate scritte a mano sono una buona base, ma cache full page, minificazione intelligente, ottimizzazione delle immagini e integrazione CDN sono ciò che porta un negozio reale da "va bene" a veloce, e queste cose appartengono a un modulo mantenuto, non a un .htaccess sempre più lungo. È il tipo di lavoro che costruiamo in mypresta.rocks: la complessità tecnica gestita per te, così velocità e tranquillità diventano impostazioni nel tuo back office, non righe da scrivere con precisione assoluta in un file che può mettere offline l’intero negozio.
