Un sito può utilizzare HTTPS e rimanere comunque poco protetto sul lato browser. Tra il server e lo schermo dell’utente, gli header HTTP trasmettono istruzioni che limitano alcuni comportamenti rischiosi: caricamento di script esterni, incorporamento del sito in un iframe, interpretazione errata di un file o accesso a funzioni sensibili del browser. Queste protezioni sono poco visibili, ma meritano di essere incluse nell’audit tecnico di un sito WordPress, di un’applicazione PHP o di un CRM aziendale su misura.

A cosa servono gli header di sicurezza HTTP?

Un header di risposta è un’informazione inviata dal server insieme alla pagina. Alcuni header indicano al browser cosa deve autorizzare o rifiutare. Possono ridurre l’impatto di attacchi come l’iniezione di script, il clickjacking o lo sfruttamento di un contenuto il cui tipo è stato dichiarato in modo errato. OWASP li presenta come un utile rafforzamento della sicurezza, non come un sostituto di codice sviluppato correttamente, aggiornato e verificato.

Le protezioni più utili da verificare

  • Content-Security-Policy (CSP) definisce le fonti autorizzate per script, stili, immagini, font e altre risorse. Una policy ben progettata limita in particolare lo sfruttamento di alcune vulnerabilità XSS. Deve però essere adattata al sito.
  • Strict-Transport-Security (HSTS) chiede al browser di utilizzare automaticamente HTTPS nelle visite successive. Deve essere inviato esclusivamente tramite HTTPS. L’opzione includeSubDomains deve essere attivata soltanto se tutti i sottodomini interessati possono funzionare stabilmente in HTTPS.
  • X-Content-Type-Options: nosniff impedisce al browser di dedurre un tipo di contenuto diverso da quello dichiarato dal server. Questo riduce alcuni scenari nei quali un file può essere interpretato come codice eseguibile.
  • frame-ancestors, all’interno della CSP, controlla quali siti possono incorporare una pagina. X-Frame-Options resta utile per la compatibilità con alcuni browser meno recenti, mentre frame-ancestors offre un controllo più moderno.
  • Referrer-Policy limita le informazioni sull’origine trasmesse quando un visitatore segue un link. Permissions-Policy può disattivare o limitare funzioni come fotocamera, microfono o geolocalizzazione quando non sono necessarie.

Perché copiare una configurazione pronta può danneggiare il sito

Una CSP troppo restrittiva può bloccare uno strumento di analisi, una mappa, un video, un pagamento online, un captcha o uno script aggiunto da WordPress. Al contrario, una policy piena di eccezioni come unsafe-inline perde parte della propria efficacia. Il metodo corretto consiste nel censire le risorse realmente utilizzate e testare prima la policy con Content-Security-Policy-Report-Only. Questa modalità segnala le violazioni senza bloccare immediatamente gli elementi coinvolti.

Anche HSTS richiede prudenza. Una durata lunga, includeSubDomains o l’inserimento in una lista di preload possono rendere inaccessibile un sottodominio se il certificato o la configurazione HTTPS non sono pronti. È preferibile iniziare con una durata limitata, controllare l’intero dominio e rafforzare poi la regola in modo progressivo.

Come effettuare un controllo concreto

Il primo controllo può essere eseguito nella scheda Rete degli strumenti di sviluppo del browser oppure con un comando che visualizza gli header HTTP. Occorre testare la home page, l’area di amministrazione, i moduli, l’area clienti e, quando presente, il percorso di pagamento.

  • Rilevare gli header già presenti e individuare duplicati o contraddizioni.
  • Censire i domini esterni caricati dal sito.
  • Preparare le regole in un ambiente di staging o in modalità report.
  • Testare moduli, statistiche, mappe, video, accessi e pagamenti.
  • Distribuire gradualmente e monitorare gli errori dopo la pubblicazione.

Su WordPress, un plugin può aggiungere alcuni header, ma una configurazione a livello di server, reverse proxy o CDN è spesso più coerente. L’aspetto principale è evitare che livelli diversi inviino regole differenti. In un’applicazione PHP su misura, gli header devono essere inseriti in una configurazione condivisa, in modo da coprire tutte le risposte, comprese le pagine di errore.

Una piccola impostazione che richiede un vero metodo

Gli header di sicurezza non rendono un sito invulnerabile. Aggiungono un utile livello di difesa attorno al codice, agli aggiornamenti, ai backup, ai controlli degli accessi e al monitoraggio. Per una PMI o un professionista di Nizza, Cannes o Monaco, l’obiettivo non è accumulare regole tecniche, ma proteggere i percorsi importanti: richieste di contatto, prenotazioni, pagamenti, accesso clienti e strumenti interni.

Punti da verificare prima della pubblicazione

Rileggere le raccomandazioni OWASP e MDN al momento della pubblicazione, verificare la compatibilità attuale di Permissions-Policy e CSP, confermare che tutti i sottodomini supportino HTTPS prima di attivare HSTS con includeSubDomains o preload e adattare ogni regola ai servizi esterni realmente utilizzati dal sito.