Generatore .htaccess

Cos'è un .htaccess?

Il file .htaccess è un file di configurazione per i server web Apache. Permette di definire reindirizzamenti URL, header di sicurezza, regole di cache e altro · senza modificare la configurazione principale del server.

Domande frequenti

Dove posizionare il file .htaccess?

Posizionalo nella directory radice del tuo sito (generalmente public_html o www). Le regole si applicano a questa directory e a tutte le sue sottodirectory.

Funzionerà con Nginx?

No. .htaccess è specifico di Apache. Nginx usa la propria sintassi di configurazione in nginx.conf o nei file di config del sito.

.htaccess può rallentare il mio sito?

Apache verifica il .htaccess a ogni richiesta, quindi i file molto grandi possono aggiungere costi. Per i siti ad alto traffico, spostare le regole nella config Apache principale è più rapido.

Cos'è davvero .htaccess

Un file .htaccess è il file di configurazione per-directory di Apache. Il nome è comunemente inteso come una contrazione di «hypertext access» (accesso ipertestuale), che riflette l'uso primario originale del file di limitare l'accesso ai documenti ipertestuali. Mettine uno in qualsiasi directory e le direttive si applicano a quella directory e a ogni sottodirectory al suo interno. Il file non ha nome prima del punto (è un dot-file Unix, nascosto per impostazione predefinita) e deve chiamarsi esattamente .htaccess (minuscolo, punto iniziale) affinché Apache lo trovi con l'impostazione predefinita AccessFileName.

C'è un costo reale in termini di prestazioni. La documentazione di Apache è esplicita: «se AllowOverride è impostato per consentire l'uso dei file .htaccess, Apache cercherà i file .htaccess in ogni directory. Quindi, consentire i file .htaccess causa un calo di prestazioni, che tu li usi davvero oppure no.» L'albero delle directory viene percorso a ogni richiesta HTTP. Per una richiesta a /var/www/html/foo/bar/baz.html, Apache verifica con stat /.htaccess, poi /var/.htaccess, poi /var/www/.htaccess, poi /var/www/html/.htaccess, e così via, anche quando nessuno di quei file esiste. La raccomandazione di Apache stessa è di usare i blocchi <Directory> della configurazione principale dove possibile (analizzati una sola volta all'avvio), e riservare .htaccess agli ambienti di hosting dove non hai accesso alla configurazione principale.

Quando ti serve (e quando no)

Apache elenca due casi d'uso legittimi per .htaccess: i provider di hosting che danno agli utenti un controllo limitato senza pieno accesso alla configurazione del server, e i casi in cui le direttive devono differire tra sottodirectory dove chi effettua il deploy controlla solo il file system. Al di fuori di questi, la documentazione raccomanda esplicitamente di spostare le regole nei blocchi <Directory> della configurazione principale.

nginx (il secondo server web più diffuso) non supporta affatto .htaccess; rifiuta deliberatamente i file di configurazione per-directory per ragioni di prestazioni, e tutta la configurazione risiede in nginx.conf e negli eventuali file di sito inclusi. Se il tuo progetto è su nginx, l'output di questo generatore non ti aiuterà, ti serviranno blocchi server / location nel file di configurazione di nginx. Caddy usa la propria sintassi Caddyfile con HTTPS automatico tramite Let's Encrypt come impostazione predefinita. LiteSpeed e OpenLiteSpeed supportano .htaccess per compatibilità con Apache. IIS usa web.config.

La riscrittura degli URL e il pattern HTTPS canonico

La maggior parte del lavoro non banale con .htaccess usa mod_rewrite, il motore di riscrittura degli URL basato su regole di Apache, costruito sulle espressioni regolari estese POSIX. La forma di base è RewriteRule pattern substitution [flags], opzionalmente preceduta da una o più condizioni RewriteCond. Il blocco standard per forzare l'HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

I flag [L,R=301] significano «questa è l'ultima regola di questo giro» e «rispondi con HTTP 301 Moved Permanently.» Un 301 è la scelta giusta per i reindirizzamenti permanenti, i motori di ricerca trasmettono il valore dei link e i browser memorizzano in cache in modo aggressivo. Usa 302 (Found) solo per reindirizzamenti genuinamente temporanei, quando non vuoi che lo spostamento venga messo in cache.

Dietro un bilanciatore di carico o un reverse proxy che termina il TLS, il server di origine vede semplice HTTP anche quando il browser dell'utente è su HTTPS, una regola RewriteCond %{HTTPS} off ingenua reindirizza allora all'infinito. La soluzione è controllare invece l'header inoltrato: RewriteCond %{HTTP:X-Forwarded-Proto} !https. La modalità «Flexible SSL» di Cloudflare (la CDN parla HTTP con l'origine mentre l'utente usa HTTPS) è la causa più comune di questa trappola di loop di reindirizzamento.

Scegli tra canonicalizzazione con www e senza www con un pattern simile. Scegli un solo hostname canonico per la SEO (evita problemi di contenuti duplicati) e per l'ambito dei cookie (un sottodominio www riceve cookie diversi rispetto al dominio apex per impostazione predefinita).

Compressione e caching

mod_deflate comprime con gzip le risposte testuali, riducendo drasticamente la dimensione di trasferimento su testo/HTML/CSS/JS. Racchiudi il blocco in <IfModule mod_deflate.c> così da non mandare in crash il sito sui server dove il modulo non è caricato. Brotli (mod_brotli) è il sostituto moderno e usa lo stesso pattern.

mod_expires imposta gli header Expires e Cache-Control: max-age. La sintassi molto usata «access plus 1 year» significa che la risorsa può essere messa in cache per un anno dal momento in cui l'utente l'ha recuperata. Un max-age lungo è corretto per i nomi di file delle risorse con hash (app.abc123.js); un max-age più breve è corretto per l'HTML e per qualsiasi cosa mutabile. Per un controllo più fine, Header set Cache-Control "public, max-age=31536000, immutable" sui file con hash è la pratica migliore moderna.

Header di sicurezza da conoscere

• X-Frame-Options: SAMEORIGIN: impedisce che la pagina venga incorporata in un <iframe> su altre origini. In gran parte soppiantato da frame-ancestors della CSP.
• Content-Security-Policy: la moderna difesa primaria contro XSS e clickjacking. Un punto di partenza: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'. Restringila col tempo.
• Strict-Transport-Security (HSTS), dice al browser di parlare solo HTTPS con il tuo dominio. max-age=31536000; includeSubDomains è la base tipica. Aggiungi preload solo quando sei sicuro che l'HTTPS sia permanente, una volta precaricato nell'elenco HSTS del browser, la rimozione è difficile.
• X-Content-Type-Options: nosniff: impedisce ai browser di mettere in dubbio l'header Content-Type. L'header ha un solo valore.
• Referrer-Policy: strict-origin-when-cross-origin: il valore predefinito moderno; invia l'URL completo alle richieste della stessa origine, solo l'origine alle richieste di origine diversa, e nulla in caso di downgrade da HTTPS a HTTP.
• Permissions-Policy: controlla le funzionalità del browser come fotocamera, microfono, geolocalizzazione. Ha sostituito il più vecchio header Feature-Policy.
• X-XSS-Protection: in gran parte deprecato. Il filtro è stato rimosso da Chrome e non è mai esistito in Firefox; la sicurezza moderna si affida alla CSP. Molte vecchie guide lo includono ancora per il vecchio IE, si può tranquillamente omettere sui nuovi siti.

Nascondi ciò che non dovrebbe essere servito

Due righe singole di rafforzamento della sicurezza si ripagano da sole:

• Options -Indexes: disabilita gli elenchi di directory generati automaticamente quando non c'è un index.html. Molte distribuzioni vengono fornite con l'indicizzazione delle directory attiva per impostazione predefinita; una directory dispersa e non protetta non dovrebbe far trapelare il suo contenuto sul web.
• Blocca i dot-file e i metadati del controllo di versione. Un blocco <FilesMatch "^(\.htaccess|\.htpasswd|\.env|\.git.*)$"> con Require all denied impedisce agli aggressori di scaricare .env (che spesso contiene password di database e chiavi API) o .git/config (che espone gli URL remoti e talvolta le credenziali). I report sulle minacce di Akamai e SANS documentano l'esposizione di .env come una delle fughe di dati a livello applicativo più comuni degli anni 2020.

Apache 2.4 ha sostituito la più vecchia sintassi Order Allow,Deny con la più pulita famiglia di direttive Require, Require all granted, Require all denied, Require ip 192.0.2.0/24, Require not ip 198.51.100.5. La vecchia sintassi funziona ancora per retrocompatibilità ma è documentata come deprecata.

Insidie comuni

• mod_rewrite deve essere abilitato a livello di server. Su Debian/Ubuntu: sudo a2enmod rewrite && sudo systemctl restart apache2. Senza di esso, ogni RewriteRule viene saltata silenziosamente.
• AllowOverride conta. Se la configurazione principale ha AllowOverride None per la tua <Directory>, ogni direttiva nel tuo .htaccess viene ignorata silenziosamente. AllowOverride All permette tutto; AllowOverride FileInfo AuthConfig permette solo la riscrittura e l'autenticazione, il che è sufficiente per la maggior parte dei casi d'uso.
• Un singolo errore di battitura rompe l'intero sito. Apache restituisce un errore 500 Internal Server Error per ogni richiesta all'albero di directory interessato finché il file non viene corretto. Prova sempre prima in staging; tieni una copia di backup chiamata .htaccess.bak; tieni pronto l'accesso SSH/FTP così da poter rinominare da remoto un file danneggiato. Controlla /var/log/apache2/error.log per i messaggi di sintassi.
• Loop di reindirizzamento infiniti. I browser limitano le catene di reindirizzamento a circa 20 salti e mostrano ERR_TOO_MANY_REDIRECTS. Le cause più comuni: una regola di reindirizzamento HTTPS in esecuzione su un server dietro un proxy che termina il TLS (usa %{HTTP:X-Forwarded-Proto}); regole www e HTTPS nell'ordine sbagliato che causano doppi reindirizzamenti; la modalità Flexible SSL di Cloudflare.
• Il flag [L] riesegue il motore di riscrittura dall'inizio con l'URL riscritto. Se poi una regola successiva corrisponde, il comportamento può essere sorprendente. Usa [END] (Apache 2.3.9+) quando vuoi davvero un arresto netto.
• Il contesto per-directory rimuove la barra iniziale. In .htaccess, RewriteRule ^index\.html$ home.html corrisponde; RewriteRule ^/index\.html$ no. Questo inganna chiunque copi una regola da un esempio di configurazione principale.
• Alcune direttive sono vietate in .htaccess: <VirtualHost>, <Directory>, <Location>, Listen, ServerName sono solo per la configurazione principale. Il file per-directory si applica già implicitamente alla propria directory.

Altre domande

Dove va messo esattamente il file?

Nella directory di cui vuoi controllare il contenuto. La maggior parte degli utenti di hosting condiviso lo mette nella document root del proprio sito, public_html/, www/ o htdocs/ a seconda dell'host. Apache poi percorre l'albero delle directory applicando le regole a quella directory e a ogni sottodirectory al suo interno.

301 o 302, quale reindirizzamento dovrei usare?

301 Moved Permanently per gli spostamenti permanenti. I motori di ricerca trasferiscono il valore dei link al nuovo URL; i browser memorizzano il reindirizzamento in cache in modo aggressivo. Usalo per i casi «abbiamo spostato questa pagina per sempre». 302 Found per i reindirizzamenti temporanei, il browser non mette in cache e i motori di ricerca non trasferiscono il posizionamento. Usa 302 solo quando lo spostamento è davvero temporaneo; impostare 302 invece di 301 come predefinito è uno degli autogol SEO più comuni.

Come proteggo una directory con password?

Crea un file .htpasswd con l'utility da riga di comando htpasswd (memorizza righe username:bcrypt-hash) e conservalo al di fuori della tua web root. Poi in .htaccess: AuthType Basic, AuthName "Restricted Area", AuthUserFile /full/path/to/.htpasswd, Require valid-user. Il browser mostra un prompt di autenticazione Basic di sistema a chiunque visiti la directory. Questo è il classico pattern di Apache; per un'autenticazione seria valuta invece un sistema di login a livello applicativo.

Funzionerà su WordPress?

WordPress include un proprio blocco .htaccess (tra i marcatori # BEGIN WordPress e # END WordPress) che gestisce i permalink. WordPress sovrascriverà qualsiasi cosa all'interno di quei marcatori quando salvi le impostazioni dei permalink. Aggiungi le tue regole al di fuori dei marcatori WordPress (tipicamente sopra di essi) così da farle sopravvivere alla rigenerazione automatica.

Viene inviato qualcosa a un server?

No. Il generatore è JavaScript che assembla blocchi di direttive in base alle tue caselle di controllo; l'output viene costruito nel tuo browser. Nulla riguardo al tuo dominio o alle opzioni scelte lascia la pagina; lo strumento funziona offline una volta caricato.

Strumenti correlati