{"id":164063,"date":"2025-11-25T09:00:00","date_gmt":"2025-11-25T08:00:00","guid":{"rendered":"https:\/\/gtechgroup.it\/blog\/sicurezza-web-html-content-security-policy\/"},"modified":"2025-11-25T09:00:00","modified_gmt":"2025-11-25T08:00:00","slug":"sicurezza-web-html-content-security-policy","status":"publish","type":"post","link":"https:\/\/nuovosito.gtechgroup.it\/blog\/sicurezza-web-html-content-security-policy\/","title":{"rendered":"Sicurezza Web e HTML: Content Security Policy e Best Practice"},"content":{"rendered":"

La sicurezza web inizia dal codice HTML. Sebbene le vulnerabilit\u00e0 pi\u00f9 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)<\/strong>, 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.<\/p>\n

Minacce Comuni alla Sicurezza HTML<\/h2>\n

Il Cross-Site Scripting (XSS)<\/strong> \u00e8 la vulnerabilit\u00e0 web pi\u00f9 diffusa e consiste nell’iniezione di script malevoli nel codice HTML di una pagina. Un attaccante pu\u00f2 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\u00f2 essere di tre tipi: reflected (lo script \u00e8 nella URL), stored (lo script \u00e8 salvato nel database) e DOM-based (lo script manipola il DOM direttamente).<\/p>\n

Il clickjacking<\/strong> \u00e8 un attacco in cui una pagina malevola incorpora il sito vittima in un <iframe><\/code> trasparente sovrapposto a elementi cliccabili ingannevoli. L’utente crede di cliccare su un pulsante della pagina malevola, ma in realt\u00e0 interagisce con il sito incorporato, eseguendo azioni non intenzionali come acquisti, trasferimenti di denaro o modifiche alle impostazioni dell’account.<\/p>\n

L’iniezione di contenuti<\/strong> include attacchi come il data exfiltration tramite tag HTML (ad esempio, un tag <img><\/code> con un src malevolo che invia dati a un server esterno) e l’inserimento di form fasulli che raccolgono credenziali. Anche i mixed content<\/strong> (risorse HTTP caricate su una pagina HTTPS) rappresentano un rischio, poich\u00e9 le risorse non cifrate possono essere intercettate e modificate da un attaccante man-in-the-middle.<\/p>\n

Content Security Policy: La Difesa Principale<\/h2>\n

La Content Security Policy (CSP)<\/strong> \u00e8 il meccanismo di difesa pi\u00f9 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\u00f2 essere implementata tramite un header HTTP o tramite un meta tag HTML:<\/p>\n

<!-- Implementazione via meta tag -->\n<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';\"><\/code><\/pre>\n
Le direttive CSP<\/strong> principali controllano diversi tipi di risorse: default-src<\/code> \u00e8 il fallback per tutte le direttive non specificate, script-src<\/code> controlla da dove possono essere caricati gli script JavaScript, style-src<\/code> controlla i fogli di stile, img-src<\/code> le immagini, font-src<\/code> i font, connect-src<\/code> le connessioni AJAX\/WebSocket, frame-src<\/code> gli iframe incorporati nella pagina e frame-ancestors<\/code> chi pu\u00f2 incorporare la nostra pagina in un iframe.<\/p>\n
I valori per ogni direttiva possono essere: 'self'<\/code> (solo dalla stessa origine), 'none'<\/code> (bloccato completamente), URL specifici (come https:\/\/cdn.esempio.it<\/code>), 'unsafe-inline'<\/code> (permette script\/stili inline \u2014 da evitare se possibile) e 'unsafe-eval'<\/code> (permette eval() \u2014 da evitare assolutamente).<\/p>\n
Nonce e Hash per Script Inline Sicuri<\/h2>\n
Il dilemma principale della CSP \u00e8 che bloccare gli script inline ('unsafe-inline'<\/code> non specificato) \u00e8 la difesa pi\u00f9 efficace contro XSS, ma molti siti legittimi utilizzano script inline per funzionalit\u00e0 essenziali. La soluzione sono i nonce<\/strong> e gli hash<\/strong>.<\/p>\n
Un nonce<\/strong> (number used once) \u00e8 un token casuale generato dal server per ogni richiesta. Il server inserisce lo stesso nonce sia nella policy CSP sia nello script inline:<\/p>\n
<!-- Header CSP: script-src 'nonce-abc123random' -->\n<script nonce=\"abc123random\">\n  \/\/ Questo script \u00e8 autorizzato perch\u00e9 ha il nonce corretto\n  console.log('Script sicuro');\n<\/script><\/code><\/pre>\n
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 \u00e8 l’hash<\/strong>: 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.<\/p>\n
Per iniziare con CSP senza rischiare di rompere il sito, si pu\u00f2 utilizzare la modalit\u00e0 report-only<\/strong> che registra le violazioni senza bloccarle effettivamente, tramite l’header Content-Security-Policy-Report-Only<\/code>. Questo permette di identificare tutte le risorse che verrebbero bloccate e di configurare la policy correttamente prima di attivarla.<\/p>\n
Subresource Integrity e Risorse Esterne<\/h2>\n
Quando il nostro sito carica risorse da CDN o server esterni (librerie JavaScript, fogli di stile), c’\u00e8 il rischio che queste risorse vengano compromesse. Il Subresource Integrity (SRI)<\/strong> protegge da questo scenario verificando l’integrit\u00e0 del file scaricato tramite un hash crittografico:<\/p>\n
<script src=\"https:\/\/cdn.jsdelivr.net\/npm\/libreria@1.0.0\/lib.min.js\"\n        integrity=\"sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K\/uxAh6VgnYDnC+\"\n        crossorigin=\"anonymous\"><\/script>\n\n<link rel=\"stylesheet\" href=\"https:\/\/cdn.example.com\/style.css\"\n      integrity=\"sha384-hash-del-file-css-qui\"\n      crossorigin=\"anonymous\"><\/code><\/pre>\n
Se il file sul CDN viene modificato (ad esempio, da un attaccante che ha compromesso il CDN), l’hash non corrisponder\u00e0 e il browser bloccher\u00e0 il caricamento<\/strong> della risorsa. L’attributo crossorigin=\"anonymous\"<\/code> \u00e8 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.<\/p>\n
Iframe, Referrer Policy e Altre Protezioni<\/h2>\n
L’attributo sandbox<\/code> sul tag <iframe><\/code> limita drasticamente le capacit\u00e0 del contenuto incorporato. Un iframe con sandbox attivo non pu\u00f2 eseguire script, inviare form, aprire popup o accedere allo storage del genitore. Si possono riattivare selettivamente le capacit\u00e0 necessarie:<\/p>\n
<!-- Iframe completamente sandboxed -->\n<iframe src=\"widget.html\" sandbox><\/iframe>\n\n<!-- Iframe con permessi specifici -->\n<iframe src=\"form.html\" sandbox=\"allow-scripts allow-forms allow-same-origin\"><\/iframe><\/code><\/pre>\n
La Referrer Policy<\/strong> 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\u00f2 essere configurata tramite il meta tag <meta name=\"referrer\" content=\"strict-origin-when-cross-origin\"><\/code> o tramite l’attributo referrerpolicy<\/code> sui singoli link e risorse. La policy strict-origin-when-cross-origin<\/code> \u00e8 il valore predefinito nei browser moderni e offre un buon equilibrio tra funzionalit\u00e0 e privacy.<\/p>\n
L’header X-Frame-Options<\/strong>, sebbene in fase di deprecazione a favore della direttiva CSP frame-ancestors<\/code>, \u00e8 ancora utile per la retrocompatibilit\u00e0. Il valore DENY<\/code> impedisce completamente l’incorporamento della pagina in iframe, mentre SAMEORIGIN<\/code> permette l’incorporamento solo dallo stesso dominio. Per una panoramica completa su come strutturare le pagine HTML<\/a> in modo sicuro e ottimizzato, consultate la nostra guida dedicata.<\/p>\n
La sicurezza web \u00e8 un processo continuo che richiede attenzione costante. Implementare CSP, SRI e le altre protezioni HTML descritte in questa guida \u00e8 un passo fondamentale per proteggere il vostro sito e i vostri utenti dalle minacce pi\u00f9 comuni del web moderno.<\/p>\n
Hai bisogno di aiuto con la sicurezza del tuo sito web? G Tech Group<\/strong> offre servizi di sviluppo web professionale e consulenza tecnica. Contattaci a support@gtechgroup.it<\/strong> o via WhatsApp al 0465 84 62 45<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"
La sicurezza web inizia dal codice HTML. Sebbene le vulnerabilit\u00e0 pi\u00f9 gravi spesso risiedano nel codice server-side, l’HTML offre diversi meccanismi di difesa che possono…<\/p>\n","protected":false},"author":2,"featured_media":164243,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1246],"tags":[786,787],"class_list":["post-164063","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-html","tag-sicurezza-web","tag-sviluppo-web"],"_links":{"self":[{"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/posts\/164063","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/comments?post=164063"}],"version-history":[{"count":0,"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/posts\/164063\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/media\/164243"}],"wp:attachment":[{"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/media?parent=164063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/categories?post=164063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nuovosito.gtechgroup.it\/blog\/wp-json\/wp\/v2\/tags?post=164063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}