La sicurezza web inizia dal codice HTML. Sebbene le vulnerabilità più gravi spesso risiedano nel codice server-side, l’HTML offre diversi meccanismi di difesa che possono prevenire attacchi comuni come il Cross-Site Scripting (XSS), il clickjacking e l’iniezione di contenuti malevoli. In questa guida esploreremo la Content Security Policy, il Subresource Integrity e le altre best practice di sicurezza implementabili tramite HTML e header HTTP correlati.
Minacce Comuni alla Sicurezza HTML
Il Cross-Site Scripting (XSS) è la vulnerabilità web più diffusa e consiste nell’iniezione di script malevoli nel codice HTML di una pagina. Un attaccante può sfruttare un campo di input non sanitizzato per inserire codice JavaScript che viene eseguito nel browser degli altri utenti, rubando cookie di sessione, credenziali o dati personali. L’XSS può essere di tre tipi: reflected (lo script è nella URL), stored (lo script è salvato nel database) e DOM-based (lo script manipola il DOM direttamente).
Il clickjacking è un attacco in cui una pagina malevola incorpora il sito vittima in un <iframe> trasparente sovrapposto a elementi cliccabili ingannevoli. L’utente crede di cliccare su un pulsante della pagina malevola, ma in realtà interagisce con il sito incorporato, eseguendo azioni non intenzionali come acquisti, trasferimenti di denaro o modifiche alle impostazioni dell’account.
L’iniezione di contenuti include attacchi come il data exfiltration tramite tag HTML (ad esempio, un tag <img> con un src malevolo che invia dati a un server esterno) e l’inserimento di form fasulli che raccolgono credenziali. Anche i mixed content (risorse HTTP caricate su una pagina HTTPS) rappresentano un rischio, poiché le risorse non cifrate possono essere intercettate e modificate da un attaccante man-in-the-middle.
Content Security Policy: La Difesa Principale
La Content Security Policy (CSP) è il meccanismo di difesa più potente disponibile. Si tratta di un insieme di regole che indicano al browser quali risorse sono autorizzate a caricare e da quali origini. CSP può essere implementata tramite un header HTTP o tramite un meta tag HTML:
<!-- Implementazione via meta tag -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://cdn.esempio.it; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none';">Le direttive CSP principali controllano diversi tipi di risorse: default-src è il fallback per tutte le direttive non specificate, script-src controlla da dove possono essere caricati gli script JavaScript, style-src controlla i fogli di stile, img-src le immagini, font-src i font, connect-src le connessioni AJAX/WebSocket, frame-src gli iframe incorporati nella pagina e frame-ancestors chi può incorporare la nostra pagina in un iframe.
I valori per ogni direttiva possono essere: 'self' (solo dalla stessa origine), 'none' (bloccato completamente), URL specifici (come https://cdn.esempio.it), 'unsafe-inline' (permette script/stili inline — da evitare se possibile) e 'unsafe-eval' (permette eval() — da evitare assolutamente).
Nonce e Hash per Script Inline Sicuri
Il dilemma principale della CSP è che bloccare gli script inline ('unsafe-inline' non specificato) è la difesa più efficace contro XSS, ma molti siti legittimi utilizzano script inline per funzionalità essenziali. La soluzione sono i nonce e gli hash.
Un nonce (number used once) è un token casuale generato dal server per ogni richiesta. Il server inserisce lo stesso nonce sia nella policy CSP sia nello script inline:
<!-- Header CSP: script-src 'nonce-abc123random' -->
<script nonce="abc123random">
// Questo script è autorizzato perché ha il nonce corretto
console.log('Script sicuro');
</script>Solo gli script con il nonce corretto vengono eseguiti. Un attaccante che inietta uno script non conosce il nonce (che cambia a ogni richiesta), quindi il suo script viene bloccato. L’alternativa è l’hash: si calcola l’hash SHA-256 del contenuto dello script e lo si inserisce nella policy. Il browser calcola l’hash dello script nella pagina e lo confronta con quelli autorizzati.
Per iniziare con CSP senza rischiare di rompere il sito, si può utilizzare la modalità report-only che registra le violazioni senza bloccarle effettivamente, tramite l’header Content-Security-Policy-Report-Only. Questo permette di identificare tutte le risorse che verrebbero bloccate e di configurare la policy correttamente prima di attivarla.
Subresource Integrity e Risorse Esterne
Quando il nostro sito carica risorse da CDN o server esterni (librerie JavaScript, fogli di stile), c’è il rischio che queste risorse vengano compromesse. Il Subresource Integrity (SRI) protegge da questo scenario verificando l’integrità del file scaricato tramite un hash crittografico:
<script src="https://cdn.jsdelivr.net/npm/libreria@1.0.0/lib.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAh6VgnYDnC+"
crossorigin="anonymous"></script>
<link rel="stylesheet" href="https://cdn.example.com/style.css"
integrity="sha384-hash-del-file-css-qui"
crossorigin="anonymous">Se il file sul CDN viene modificato (ad esempio, da un attaccante che ha compromesso il CDN), l’hash non corrisponderà e il browser bloccherà il caricamento della risorsa. L’attributo crossorigin="anonymous" è necessario per abilitare il controllo CORS sulle risorse cross-origin. Gli hash SRI possono essere generati con strumenti online come srihash.org o tramite la command line.
Iframe, Referrer Policy e Altre Protezioni
L’attributo sandbox sul tag <iframe> limita drasticamente le capacità del contenuto incorporato. Un iframe con sandbox attivo non può eseguire script, inviare form, aprire popup o accedere allo storage del genitore. Si possono riattivare selettivamente le capacità necessarie:
<!-- Iframe completamente sandboxed -->
<iframe src="widget.html" sandbox></iframe>
<!-- Iframe con permessi specifici -->
<iframe src="form.html" sandbox="allow-scripts allow-forms allow-same-origin"></iframe>La Referrer Policy controlla quante informazioni sull’URL di provenienza vengono inviate quando l’utente naviga verso un’altra pagina o quando il browser carica risorse esterne. Può essere configurata tramite il meta tag <meta name="referrer" content="strict-origin-when-cross-origin"> o tramite l’attributo referrerpolicy sui singoli link e risorse. La policy strict-origin-when-cross-origin è il valore predefinito nei browser moderni e offre un buon equilibrio tra funzionalità e privacy.
L’header X-Frame-Options, sebbene in fase di deprecazione a favore della direttiva CSP frame-ancestors, è ancora utile per la retrocompatibilità. Il valore DENY impedisce completamente l’incorporamento della pagina in iframe, mentre SAMEORIGIN permette l’incorporamento solo dallo stesso dominio. Per una panoramica completa su come strutturare le pagine HTML in modo sicuro e ottimizzato, consultate la nostra guida dedicata.
La sicurezza web è un processo continuo che richiede attenzione costante. Implementare CSP, SRI e le altre protezioni HTML descritte in questa guida è un passo fondamentale per proteggere il vostro sito e i vostri utenti dalle minacce più comuni del web moderno.
Hai bisogno di aiuto con la sicurezza del tuo sito web? G Tech Group offre servizi di sviluppo web professionale e consulenza tecnica. Contattaci a su*****@********up.it o via WhatsApp al 0465 84 62 45.