.htaccess PrestaShop: regole, reindirizzamenti e recupero

Cosa faremmo noi

Partiremmo dal file generato funzionante e da un problema specifico da risolvere, invece di incollare una sostituzione completa. La soluzione giusta dipende dalla versione di PrestaShop esistente, dai livelli di hosting, dai moduli, dalle integrazioni di pagamento ed ERP, dal tema, dai download pubblici e dai file memorizzati. Includi nell'inventario ogni dominio del negozio, sottocartella, lingua e mercato: una regola che funziona per il front office predefinito può fallire per un altro percorso usato dai clienti.

Esegui la modifica su una copia di staging che riproduca i moduli server, i permessi di override e le politiche proxy pertinenti, con dati rappresentativi e tema e integrazioni effettivi. Isolala da pagamenti reali, email ai clienti ed esportazioni per l'evasione degli ordini. Prova modifica, rigenerazione e recupero prima di un passaggio in produzione pianificato. Tieni pronti un accesso indipendente all'hosting e un file privato sicuramente funzionante, concorda chi può ripristinarlo e applica la modifica revisionata alla configurazione propria del negozio in produzione, invece di caricare il blocco generato con i domini dello staging.

Scegli l'azione successiva in base ai riscontri

Se desideri una valutazione dell'esposizione, PrestaShop Security Audit & Hardening Report offre un'analisi e un piano di intervento; l'implementazione viene definita separatamente.

Verifica quale server elabora la richiesta

.htaccess è una configurazione per cartella in stile Apache. Apache e server compatibili, comprese installazioni LiteSpeed appropriate, possono elaborarlo. Direttive supportate e permessi di override dipendono dalla configurazione del server.

L'header di risposta Server è un indizio, non una prova di questa topologia. Un proxy può nasconderlo o sostituirlo. Chiedi al tuo host quale livello serve PHP, immagini, download ed errori e quale applica le regole di accesso.

Verifica permessi di override e moduli caricati prima di aggiungere direttive. Consulta la guida Apache a .htaccess, il riferimento di configurazione LiteSpeed e la documentazione del proxy Nginx per i rispettivi modelli di configurazione.

Conserva il blocco generato ed esaminane il contenuto

PrestaShop genera regole di riscrittura specifiche del negozio tramite le impostazioni SEO & URLs. Nelle versioni moderne, apri Parametri negozio > Traffico & SEO > SEO & URLs. Conserva un backup privato prima di salvare impostazioni o modificare il file.

# ~~start~~
# PrestaShop-managed content
# ~~end~~

Le righe complete dei marcatori includono commenti esplicativi. Mantieni intatte le righe originali. Il core normalmente sostituisce la sezione gestita e conserva il testo personalizzato prima e dopo. Le regole interne alla sezione possono scomparire durante la rigenerazione. Quelle esterne, comprese quelle errate, possono sopravvivere.

Posiziona le regole personalizzate fuori dai marcatori secondo l'ordine di elaborazione. Un reindirizzamento anticipato dei contenuti deve normalmente precedere la regola onnicomprensiva del front controller: tenerlo fuori dal blocco alla fine può conservarlo senza renderlo efficace. Le direttive su cartelle/file seguono proprie regole di ambito e fusione.

Con marcatori mancanti o malformati, il generatore può conservare i vecchi contenuti come testo personalizzato anziché sostituirli come previsto. Non usare un file danneggiato come base per un recupero che dovrebbe essere pulito.

Cosa genera il core

• Gestione di dominio del negozio e URI fisico, route delle immagini, route del webservice e instradamento del front controller.
• Controlli sulle risorse esistenti per servire i file e le cartelle reali appropriati.
• Un valore di ambiente REWRITEBASE, ad esempio tramite [E=REWRITEBASE:/shop/], derivato dall'URI fisico del negozio. È diverso da una direttiva letterale RewriteBase.
• Gestione condizionale di MultiViews, regole MIME/font e routing dei documenti di errore.
• Regole di sicurezza dipendenti dalla versione. PrestaShop 9 include protezioni contro la visualizzazione degli elenchi delle cartelle e contro l’accesso ai file sensibili.
• Direttive condizionali Expires, ETag e compressione quando l'ottimizzazione Apache è attiva.

Non presumere che il generatore imposti DirectoryIndex o limiti PHP di memoria/caricamento. Sono impostazioni separate dell'host. Analizza il risultato generato e le politiche esistenti a livello server prima di aggiungere duplicati.

Aggiungi accanto a ogni gruppo di regole personalizzate un commento che ne indichi scopo, ambito e responsabile della manutenzione. Conserva motivazione e risultato atteso della richiesta nel registro privato delle modifiche, così uno sviluppatore successivo potrà distinguere un'esigenza attiva da una soluzione temporanea abbandonata. Registra anche i moduli o gli strumenti di hosting che scrivono il file, oltre alla persona che lo modifica.

Aggiungi solo le protezioni mancanti per l'accesso ai file

Impedisci l'accesso diretto a segreti, metadati del controllo versione, dump del database e copie di backup. Non conservare backup nella radice pubblica dei documenti. Un file index.php segnaposto o la disattivazione degli elenchi delle cartelle non protegge un URL di file noto.

Per Apache 2.4 con supporto di autorizzazione e permessi necessari, ecco una regola di esempio per nomi di file da adattare all'esposizione effettiva:

<FilesMatch "^(composer\.(json|lock)|package(-lock)?\.json|parameters\.(php|yml)|settings\.inc\.php|\.env.*)$">
    Require all denied
</FilesMatch>

Nega anche l'accesso alla cartella Git al livello che serve i file, compresi i file al suo interno. Un esempio a livello radice per un'installazione Apache con .htaccess è:

RedirectMatch 404 (^|/)\.git(?:/|$)

Esamina altre estensioni sensibili come YAML, log, dump SQL, template e file di backup. Un divieto generale per estensione può bloccare anche allegati pubblici previsti: adegua le regole all'esposizione reale e prova i download legittimi. I file di configurazione PHP non devono essere scaricabili nemmeno se il gestore PHP è configurato male o viene aggiunto un suffisso di backup.

Options -Indexes impedisce gli elenchi automatici delle cartelle dove consentito. PrestaShop 9 lo genera già, quindi non aggiungerlo solo per duplicare il valore predefinito. Una direttiva Options o Require non consentita può causare un errore; usa la configurazione supportata dal server invece di aggiungere eccezioni sempre più permissive.

Apache 2.2 usava una sintassi di autorizzazione diversa ed è obsoleto. Non mescolare ricette legacy Order/Deny con una configurazione moderna senza comprenderne compatibilità ed ereditarietà. Su Nginx o un proxy che serve direttamente i file, applica protezioni equivalenti anche lì.

Un rifiuto su una pagina PHP non prova che un download sia protetto

Supponi che Nginx serva i file statici mentre Apache gestisce il front office. Aggiungi una regola di divieto in Apache e il negozio continua a funzionare, ma questo non dice nulla su un backup servito direttamente da Nginx. Su una copia di staging isolata, inserisci un file fittizio innocuo che corrisponda alla protezione prevista in una posizione di test concordata, richiedi il suo esatto URL pubblico con GET e conferma che il contenuto non venga restituito. Se viene restituito, chiedi all'host di seguire la richiesta e applicare la protezione mancante al livello che serve il file. Poi rimuovi il file fittizio e testa anche un allegato che deve essere pubblico.

Imposta gli header di risposta verificando la compatibilità

Esamina gli header già forniti da host, proxy, core ed estensioni di sicurezza. Evita valori in conflitto o duplicati. Questo esempio Apache richiede mod_headers e il permesso di usare le direttive:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

nosniff limita il MIME sniffing; non impedisce ogni attacco tramite file caricati. Una politica referrer limita le informazioni di provenienza in uscita ma non sostituisce la necessità di tenere i segreti fuori dagli URL.

Valuta X-Frame-Options: SAMEORIGIN rispetto a esigenze legittime di incorporamento e demo. Una Permissions-Policy che nega fotocamera, microfono e geolocalizzazione può incidere sulle funzionalità che usano queste capacità. Abilita solo politiche adatte al negozio.

Introduci Content-Security-Policy con un inventario consapevole, osservazione in modalità report-only e prove di pagamenti/tema prima dell'applicazione vincolante. Controlla script, frame di pagamento, consenso, analisi e strumenti amministrativi. Non usare l'header deprecato X-XSS-Protection come sostituto dei controlli attuali.

Una condizione IfModule salta un blocco quando manca un modulo; non concede il permesso di override né dimostra che un header di sicurezza sia attivo. Controlla risposte normali, reindirizzate, di errore e tramite proxy.

Configura compressione e cache statica

Controlla prima Content-Encoding e dimensione trasferita effettivi. Host, ottimizzazione Apache, Nginx o CDN potrebbero già comprimere le risposte. Il risparmio della compressione del testo dipende da contenuto e trasporto; non aspettarti una percentuale fissa per ogni pagina prodotto.

Se manca la compressione in un'installazione Apache, ecco un esempio mirato:

<IfModule mod_deflate.c>
    <IfModule mod_filter.c>
        AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml
        AddOutputFilterByType DEFLATE application/javascript application/json image/svg+xml
    </IfModule>
</IfModule>

WOFF2 e i formati immagine comuni sono già compressi; non presumere che un ulteriore filtro di compressione li aiuti. Controlla tipi di contenuto, filtri esistenti, header Vary e codifiche accettate dal browser. Lascia che il livello che serve i contenuti gestisca la compressione in modo coerente.

Scegli la durata della cache del browser in base a come cambiano le risorse. Un anno può andare bene per immagini/font immutabili con impronta nel nome; un mese per CSS/JavaScript con versione. Le risorse senza versione richiedono una durata inferiore o una strategia affidabile di invalidazione. Sostituire un'immagine non garantisce un nuovo URL. Se il personale sostituisce un foglio di stile del tema allo stesso indirizzo e i clienti di ritorno vedono ancora il vecchio layout, esamina l'uso della cache del browser e la versione della risorsa, non solo il file su disco. Svuotare la CDN non elimina una copia ancora valida già presente nel browser del cliente. Correggi il processo di gestione delle versioni prima di prolungare la durata di quella risorsa.

Questo esempio prudente imposta la scadenza solo per i tipi statici elencati e non contiene un valore predefinito per altre risposte:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 day"
    ExpiresByType image/png "access plus 1 day"
    ExpiresByType image/webp "access plus 1 day"
    ExpiresByType font/woff2 "access plus 1 day"
    ExpiresByType text/css "access plus 1 hour"
    ExpiresByType application/javascript "access plus 1 hour"
</IfModule>

ExpiresDefault si applica oltre i tipi elencati e può influire involontariamente sui contenuti dinamici. Esamina separatamente risposte di prodotto, carrello, checkout, account e pagamento, inclusi gli header Cache-Control ed Expires. Cache del browser e cache condivisa delle pagine complete sono politiche separate. Consulta il riferimento Apache di mod_expires.

Mantieni riutilizzo delle connessioni e politica ETag coerenti con l'intera installazione server/CDN. Non c'è un beneficio universale nell'aggiungere una direttiva Keep-Alive o rimuovere gli ETag. Le regole generate esistenti potrebbero già gestirli.

Progetta reindirizzamenti mirati e conserva il routing

Usa un 301 per un trasferimento permanente e un 302 per uno temporaneo quando questi significati corrispondono alla richiesta. Un 410 è una risposta Gone, non un reindirizzamento a una pagina sostitutiva. Prova con un reindirizzamento temporaneo prima di applicare una regola permanente ampiamente memorizzata nella cache.

Ad esempio, questa regola Apache relativa al negozio reindirizza solo richieste GET o HEAD per un vecchio percorso editoriale verso il suo sostituto. Presuppone che .htaccess sia nella radice del negozio:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(?:GET|HEAD)$
RewriteRule ^old-size-guide/?$ new-size-guide [R=302,L]

Inseriscila prima delle regole generate del dispatcher e provala nell'URI di base effettivo. Verifica se sia appropriato conservare la query string originale. Le riscritture interne possono rientrare nell'elaborazione per cartella, quindi una regola non deve intercettare la propria destinazione o il percorso del front controller.

Per un esempio di verifica in sottocartella, supponi che il negozio sia installato in /shop/. Richiedi /shop/old-size-guide e conferma che l'esempio porti alla destinazione prevista /shop/new-size-guide, senza uscire verso la radice del dominio o acquisire un secondo prefisso /shop/. Ripeti con una barra finale e con una query string innocua, controllando che la query venga conservata come previsto. Richiedi anche direttamente la destinazione: deve mostrare la pagina sostitutiva anziché tornare all'indirizzo dismesso. Cambia lo stato temporaneo solo dopo il superamento di queste verifiche e l'approvazione della mappatura come permanente. Un browser può conservare un reindirizzamento permanente in cache anche dopo il ripristino del file server, quindi il solo ripristino del file potrebbe non ripristinare il comportamento precedente.

Usa il routing linguistico nativo invece di un reindirizzamento generico onnicomprensivo dei prefissi di lingua. Ogni politica di routing personalizzata necessaria deve considerare sottocartella del negozio, cartella amministrativa effettivamente rinominata, risorse esistenti, API, route semplificate dei moduli, endpoint PHP, metodi e tutte le lingue attive. Non reindirizzare richieste POST di pagamento o di invio dei moduli con una regola di contenuto non verificata.

Per le migrazioni dei contenuti, confronta il supporto del modulo installato per corrispondenze esatte/per percorso/per prefisso, gestione di 301/302/410 e report dei reindirizzamenti con la pagina di aiuto di SEO Revolution. Le regole server restano utili per le politiche da applicare prima dell'avvio di PrestaShop.

Controlla destinazione finale, stato e lunghezza della catena. Un reindirizzamento non garantisce il mantenimento del posizionamento nei motori di ricerca. Conserva mappature utili ed evita cicli o reindirizzamenti inutili di ogni pagina rimossa alla homepage.

Recupera in sicurezza un .htaccess non funzionante

Un nuovo 500 dopo una modifica rende quella modifica un buon punto di partenza, ma possono coincidere altri guasti. Leggi il log degli errori del server web per cercare errori di sintassi, moduli mancanti o direttive vietate.

1. Usa SFTP, SSH o il gestore file dell'hosting, attivando la visualizzazione dei file nascosti se necessario. Conserva una copia privata datata del file guasto per la diagnosi.
2. Limita temporaneamente l'accesso pubblico su host/proxy prima di sostituire o rimuovere .htaccess. Rimuoverlo può eliminare restrizioni di accesso oltre alle riscritture.
3. Ripristina un backup noto e funzionante, se disponibile. Se devi ripartire da zero, sposta il file guasto fuori dalla radice pubblica e crea un nuovo .htaccess scrivibile con proprietà e permessi appropriati.
4. Raggiungi il back office tramite una route funzionante e salva le impostazioni SEO & URLs/URL semplificati per rigenerare le regole specifiche del negozio. Se necessario, disattiva e riattiva consapevolmente l'impostazione URL semplificati e ripristina il valore finale previsto.
5. Controlla che la generazione sia riuscita e che il file contenga dominio/URI di base corretti e un solo blocco gestito intatto.
6. Confronta il backup e ripristina solo le regole personalizzate comprese, un gruppo alla volta. Ripeti le prove dopo ogni gruppo.
7. Svuota le cache applicative pertinenti e, se persistono errori o reindirizzamenti memorizzati, la cache proxy/CDN applicabile.

Rigenerare semplicemente sopra il file guasto può conservare la regola personalizzata errata fuori dai marcatori. Uno snippet contenente solo RewriteEngine On abilita la riscrittura ma non ripristina le regole PrestaShop di immagini, dispatcher o webservice.

Se la generazione fallisce, controlla accesso in scrittura, URI fisico configurato, supporto di riscrittura Apache e politica di override. Non risolvere i permessi rendendo tutto il negozio scrivibile da chiunque. Se il file cambia nuovamente dopo la generazione, esamina moduli che usano l'hook di creazione htaccess e automazioni del pannello hosting.

Su Nginx/PHP-FPM puro, correggi la configurazione Nginx, esegui nginx -t e ricarica solo dopo la convalida. Ripristinare .htaccess non corregge le route di quel server.

Verifica i confini del blocco generato e le route critiche

Usa lo staging per verificare il comportamento dei marcatori prima di farvi affidamento. Conserva un originale recuperabile e non introdurre regole volutamente invalide in produzione.

1. Inserisci commenti innocui etichettati sopra e sotto il blocco gestito esistente.
2. Rigenera dal back office, poi confronta il risultato. Entrambi i commenti esterni devono restare e la sezione generata deve essere sostituita.
3. Rigenera di nuovo e verifica che ci sia una coppia di marcatori e nessun gruppo di regole personalizzate duplicato.
4. Per una prova di recupero, conserva privatamente la copia del file guasto, rigenera in un file nuovo e verifica il ripristino delle regole di riscrittura e accesso necessarie.
5. Ripristina progressivamente i gruppi personalizzati approvati e verifica che il risultato sopravviva a un'altra rigenerazione.

Marcatori malformati o duplicati richiedono una correzione manuale partendo da una base nota e funzionante. Il meccanismo di conservazione non è un parser che convalida l'intento delle regole personalizzate.

Ispeziona gli header di risposta nel pannello Network del browser. Per le verifiche da riga di comando, imposta SHOP_URL sull'origine reale del negozio e usa curl --head --location --max-redirs 5 "$SHOP_URL". Testa percorsi noti e risposte GET oltre a HEAD, perché le route possono comportarsi diversamente secondo il metodo. Conserva un registro prima e dopo di ogni percorso, metodo, stato, destinazione e header di risposta pertinente testato, insieme al risultato atteso. Per un file fittizio protetto, verifica il corpo della risposta oltre allo stato: il contenuto non deve essere restituito e il risultato deve corrispondere al rifiuto previsto. Non includere segreti reali e dati dei clienti nelle evidenze.

Le regole sui file integrano aggiornamenti e autenticazione. Per i limiti al traffico consulta la guida alla protezione dai bot; per controlli più ampi sull'installazione usa la guida alla sicurezza e la guida alle prestazioni.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Quale livello gestisce ogni richiesta interessata e quali differenze tra staging e produzione restano da testare?
• Quale esigenza giustifica ogni regola personalizzata, dove viene inserita e quale politica generata o dell'host potrebbe sovrapporsi?
• Chi può rigenerare il file e quali moduli, attività di distribuzione o strumenti del pannello hosting possono modificarlo in seguito?
• Dove sono i risultati delle richieste, comprese le lingue interessate, le callback di pagamento, i download e il percorso amministrativo?
• Chi monitorerà il passaggio pianificato, quali errori richiedono un ripristino e come ripristinerà l'accesso se il back office è irraggiungibile?

Concorda le condizioni di arresto prima del rilascio. Un checkout, una callback, un download legittimo o una route amministrativa che non funziona dopo la modifica è un motivo per fermarsi e ripristinare la configurazione approvata. Un punteggio migliore per gli header non compensa un percorso di acquisto interrotto.

Domande dei gestori dei negozi

Posso copiare il file da un altro negozio?

Usalo per capire una regola, non come base generata. Domini, URI fisici, route delle immagini e requisiti dei moduli possono differire. Rigenera il file per il tuo negozio e trasferisci solo la modifica personalizzata che hai compreso.

E se posso modificare i file solo dal back office?

Predisponi un accesso SFTP o al gestore file dell'hosting funzionante prima della modifica. Una configurazione errata del server web può rendere irraggiungibile l'editor, quindi il solo accesso al back office non è una soluzione di recupero.

Ogni risposta deve avere gli stessi header e la stessa politica di cache?

Definisci i risultati attesi per ogni tipo di risposta e livello che la serve. Una pagina privata dell'account, un font statico e una callback di pagamento hanno esigenze diverse; una scansione della homepage non può convalidarle tutte.

Se trovo un backup reale esposto, basta una regola di divieto?

Conserva una copia privata e i log di accesso pertinenti, rimuovi il file dall'archiviazione pubblica e svuota le eventuali copie in cache su CDN o proxy. Ricontrolla l'URL pubblico attraverso la normale catena di distribuzione. Chiedi al responsabile della sicurezza di valutare eventuali accessi e se le credenziali esposte vadano sostituite. Chiudere l'URL non chiarisce se il file sia già stato scaricato; segui la guida alla risposta alle violazioni se sospetti una compromissione.