# Conformità NIS2 art. 24, OWASP e AGID per response header > Analizzatore online di response header HTTP: CSP, HSTS, X-Frame, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP. Mapping NIS2 art. 24, OWASP, AGID. Strumento gratuito nel browser (nessun upload): https://www.mauriziofonte.it/strumenti/analizzatore-header-sicurezza Incolla i **response header** di una pagina web (cURL, browser DevTools, web archive) e ottieni un audit security-first dei controlli di hardening: **Content-Security-Policy**, **Strict-Transport-Security**, **X-Frame-Options**, **Referrer-Policy**, **Permissions-Policy**, **COOP/COEP/CORP**, anti-fingerprinting. Ogni finding è classificato per severità e mappato su NIS2 art. 24, OWASP Top 10, AGID Linee Guida sicurezza sviluppo software. ## Come usare l'analizzatore 1. **Recupera i response header** - Da terminale: `curl -sI https://www.tuosito.it`. Da browser: DevTools (F12) > Network > clicca la prima request del documento > pannello Headers > sezione Response Headers > copia. Da web archive: anche solo le righe rilevanti vanno bene. 2. **Incolla nel tool** - Una header per riga, formato standard `Header-Name: value`. Sono accettati anche output cURL grezzi (la prima riga `HTTP/2 200` è filtrata automaticamente). Case-insensitive sui nomi degli header. 3. **Analizza** - Il tool controlla 12 header rilevanti per la sicurezza, ognuno con regole specifiche (la CSP non deve lasciare script inline o sorgenti aperte a qualunque host, HSTS deve avere max-age di almeno 180 giorni, X-Frame-Options deve essere DENY o SAMEORIGIN, ecc). Se incolli l'output di `curl -IL` con più risposte, valuta solo l'ultima, quella della pagina finale. Output: lista findings classificati per severità con riferimenti normativi e remediation suggerita. 4. **Esporta il report** - Il bottone Copia produce un riepilogo testuale incollabile in mail interna, ticket Jira, documento di audit. Per l'export PDF usa la funzione 'Stampa' del browser (la pagina ha CSS print-ottimizzato che nasconde nav e CTA). ## Perché un audit degli header serve davvero **Defense in depth.** I response header HTTP sono il livello più sottile e più facile da configurare delle difese applicative: si emettono dal web server o dal middleware applicativo, costano zero performance, hanno impatto immediato. CSP da sola previene la grande maggioranza degli XSS reflected e DOM-based, HSTS chiude la finestra di downgrade attack su TLS, X-Frame-Options impedisce il clickjacking, Permissions-Policy chiude le API browser non utilizzate (camera, microfono, geolocalizzazione, USB) togliendo superfici di attacco. **Cosa controlla davvero questo tool.** 12 header, da quelli essenziali (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) a quelli moderni (COOP/COEP/CORP per cross-origin isolation), con regole specifiche per ognuno: directive che devono essere presenti, sorgenti che NON devono esserci (es. CSP `unsafe-inline`, `*`, `https:`), formato corretto del valore, valori minimi (es. HSTS `max-age >= 15552000` = 180 giorni, la soglia del Mozilla HTTP Observatory), interazione fra header (es. `frame-ancestors` della CSP accettato al posto di X-Frame-Options, `'unsafe-inline'` ignorato dal browser quando la stessa direttiva ha un nonce o un hash). Cache-Control non viene valutato: dagli header non si capisce se una risposta è sensibile. **Mapping normativo italiano + europeo.** Ogni finding cita il riferimento applicabile: NIS2 D.Lgs. 138/2024 art. 24 c.2 lett. e (sicurezza acquisizione/sviluppo/manutenzione), AGID Linee Guida Sicurezza dello Sviluppo del Software 43/2026, OWASP Top 10 e ASVS, Mozilla Web Security Cheatsheet. Per i tool che servono aziende in scope NIS2 questo è il punto di partenza dell'audit applicativo. **Privacy by design.** Niente upload, niente fetch remoto. L'analisi è interamente: il browser parsa i tuoi header, li valuta contro le regole locali, mostra i findings. Il sito di cui stai facendo audit non viene mai contattato dal nostro server. Comodo per audit di sistemi interni, ambienti di staging non accessibili dall'esterno, intranet aziendali. ## Glossario - **Content-Security-Policy**: Direttiva HTTP che istruisce il browser su quali sorgenti (script, style, immagini, frame, ecc) sono autorizzate a essere caricate. Difesa primaria contro XSS reflected/stored/DOM-based. Definita da W3C CSP Level 3 (2024). - **HSTS**: Strict-Transport-Security, RFC 6797. Forza il browser a usare solo HTTPS per il dominio per `max-age` secondi. Con `preload` il dominio entra nella lista di Chrome/Firefox/Safari (sottomissione manuale via hstspreload.org). - **Clickjacking**: Attacco in cui una pagina vittima viene caricata in iframe trasparente sopra un'altra pagina, e i click utente vanno alla vittima inconsapevolmente. Difesa: X-Frame-Options o CSP frame-ancestors. - **Cross-origin isolation**: Combinazione di COOP=same-origin + COEP=require-corp che abilita API browser sensibili (SharedArrayBuffer, performance.now() ad alta risoluzione) impedendo ad altri origin di leggere i tuoi dati. Necessario per WASM threads, advanced timing. - **Permissions-Policy**: Header W3C che disabilita feature browser non usate dalla pagina (camera, microfono, geolocation, payment, USB, fullscreen, ecc). Riduce la superficie di attacco e protegge anche dai sub-frame. - **OWASP ASVS**: Application Security Verification Standard di OWASP (v4.0.3, 2023). Definisce 14 categorie di controlli applicativi su 3 livelli (L1-L3). I requisiti sui security header vivono nella categoria V14 'Configuration'. - **AGID 43/2026**: Linee Guida AGID per la sicurezza dello sviluppo del software, applicate a tutta la PA italiana e raccomandate alle aziende in scope NIS2. Contengono requisiti diretti sui security header (par. 5.2). ## Domande frequenti sull'analizzatore ### Posso analizzare un sito senza incollare gli header (passando solo l'URL)? No, e per scelta. Un fetch cross-origin lato browser viene bloccato dalle policy CORS della pagina target nella maggior parte dei casi. Per evitare di costruire un proxy server-side (con relativi costi e privacy concerns), il tool richiede di incollare gli header. Workflow: `curl -sI https://target.it > out.txt`, copia `out.txt`, incolla nel tool. ### Il punteggio di hardening è una metrica standard? No, è una metrica indicativa di triage: somma pesata dei controlli soddisfatti (CSP +30, HSTS +20, X-Frame-Options o frame-ancestors +10, COOP +10, X-Content-Type-Options +5, Referrer-Policy +5, Permissions-Policy +5, header Server senza versione +5, niente X-Powered-By +5, X-XSS-Protection assente o a 0 +5 = 100). Una CSP debole vale metà punti, così come un HSTS con max-age sotto i 180 giorni. COEP e CORP producono finding ma non spostano il punteggio. Per benchmark di settore con scoring normalizzato e monitoring continuo esistono servizi commerciali dedicati. Questo tool serve a fare il triage rapido prima di un audit di sicurezza approfondito. ### L'analizzatore controlla anche header non legati alla sicurezza (Content-Type, Cache-Control)? No. Cache-Control conta per la sicurezza solo sulle risposte sensibili (area riservata, API autenticate), e dagli header non si capisce se una risposta lo è: per questo il tool non lo valuta. Su quelle risposte verifica a mano che ci sia `no-store`. Content-Type viene controllato solo attraverso `X-Content-Type-Options: nosniff`. Per audit completi di Content-Type, Vary, Accept-Ranges servono tool dedicati di performance/CDN debugging, non security audit. ### Perché X-XSS-Protection è classificato come deprecato? L'header è stato deprecato da Chrome (2019), Firefox (mai supportato seriamente), Safari. La sua euristica XSS lato browser introduceva vulnerabilità (XS-Leaks) ed era mantenuta solo per legacy IE/Edge. OWASP raccomanda `X-XSS-Protection: 0`, che spegne il filtro dove esiste ancora: il tool considera corretti sia il valore 0 sia l'assenza dell'header, e segnala solo il valore 1. La difesa XSS moderna è Content-Security-Policy con `script-src` stretto, niente `unsafe-inline`, idealmente con `nonce` o `hash` sui script inline necessari. ### CSP con unsafe-inline mi serve per il sito legacy che ha tanti onclick. Come faccio? Tre strategie graduali. (1) Refactor verso event handlers in JS esterno (rimuovi onclick=, mettiti in addEventListener nel JS). È la soluzione pulita ma costosa. (2) CSP con `'unsafe-inline'` più `'nonce-RANDOM'`: il browser accetta inline script con nonce specifico, e dato il nonce ad attaccante richiede compromissione già avvenuta lato server. Compromise pragmatico. (3) CSP con `'unsafe-hashes'` per gli inline event handlers (Level 3, 2024+). Browser support più ridotto ma migliora con il tempo. ### L'header Server: nginx/1.24.0 è davvero pericoloso? Non direttamente exploitabile, ma concept di defense in depth: l'attaccante che enumera la versione esatta può cercare exploit pubblici per quella build. Le distro stable (Debian, RHEL) backportano le patch quindi `nginx/1.18.0` Debian buster non ha le stesse vuln di `nginx/1.18.0` upstream, ma l'attaccante automatizzato non lo sa: vede 1.18.0 e prova exploit. Costo di nascondere: `server_tokens off` in nginx, due righe. Beneficio: marginale ma gratuito. Sotto NIS2 art. 24 (igiene cyber) è ragionevole farlo. ### Devo settare COOP=same-origin se il mio sito non usa SharedArrayBuffer? Non è obbligatorio, ma è una buona idea. Anche senza SharedArrayBuffer, COOP previene attacchi specifici in cui un'altra finestra (popup di phishing, pagina aperta da utente) può interagire con la tua via `window.opener`. `same-origin` isola la tua window completamente, Così che gli script di altri origin non possano leggere il tuo state. Costo: zero impatto su utente, marginale su feature richieste. ### Permissions-Policy ha sostituito Feature-Policy? Si. Feature-Policy era il nome originale (2018-2020). Permissions-Policy è il nome standardizzato (2020+) e con sintassi più chiara. Browser moderni supportano entrambi, ma se servi Permissions-Policy puoi rimuovere Feature-Policy. Sintassi base: `Permissions-Policy: camera=(), microphone=(), geolocation=()` = vieta tutto. `geolocation=(self)` = solo origine corrente. ### Come faccio HSTS preload per il mio dominio? (1) Setta header HSTS con `max-age=63072000; includeSubDomains; preload` su tutti i sotto-domini. (2) Verifica che funzioni con `curl -I` e con il check di hstspreload.org. (3) Sottoponi il dominio sul portale Chromium `hstspreload.org`. Inclusione: settimane-mesi. Rimozione: difficile, quindi siano sicuri prima di sottoporre. Impatto: tutti i subdomain HTTP non funzionano più senza certificato. ### Che strumenti uso lato server per emettere gli header? Apache: `Header set X-Frame-Options DENY`, `Header set Content-Security-Policy "..."`, in `.htaccess` o config virtual host. Nginx: `add_header X-Frame-Options DENY always;` nel server block. PHP middleware (Symfony, Laravel, Slim): `response->header('X-Frame-Options', 'DENY')` oppure middleware globale dedicato. Per CSP con `nonce`: il middleware genera nonce per request, lo emette nell'header, lo inietta nei tag `