Vai al contenuto
Security audit

Analizzatore di header HTTP per la 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 severita' e mappato su NIS2 art. 24, OWASP Top 10, AGID Linee Guida sicurezza sviluppo software.

Come usare l'analizzatore

  1. 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. 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. 3

    Analizza

    Il tool processa le 12 famiglie di header rilevanti per la sicurezza, ognuna con regole specifiche (CSP non può usare unsafe-inline, HSTS deve avere max-age >= 6 mesi, X-Frame-Options deve essere DENY o SAMEORIGIN, ecc). Output: lista findings classificati per severita' con riferimenti normativi e remediation suggerita.

  4. 4

    Esporta il report

    Bottone 'Copia report' 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 famiglie di 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, directive che NON devono essere presenti (es. CSP unsafe-inline), formato corretto del valore, valori minimi (es. HSTS max-age >= 15768000 = 6 mesi), interazione fra header (es. X-XSS-Protection deprecato in presenza di CSP).

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 PMI 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.

Cosa controlla il linter (sintesi)

HeaderRegolaSeverita'
Content-Security-PolicyPresente, no unsafe-inline, default-src o script-src specificiAlta-Critica
Strict-Transport-SecurityPresente, max-age >= 6 mesi, includeSubDomains, preload (consigliato)Alta
X-Frame-OptionsDENY o SAMEORIGIN (oppure CSP frame-ancestors)Alta
X-Content-Type-OptionsnosniffMedia
Referrer-Policystrict-origin-when-cross-origin (raccomandato), no unsafe-urlMedia
Permissions-PolicyPresente, restringe API non usateMedia
Cross-Origin-Opener-Policysame-origin per pagine sensibiliMedia
Cross-Origin-Embedder-Policyrequire-corp se applicabileBassa
Cross-Origin-Resource-Policysame-origin/same-siteBassa
Server / X-Powered-ByNon esporre versione (info disclosure)Info-Bassa
X-XSS-ProtectionDeprecato: rimuovere se CSP presenteBassa
Cache-Controlno-store su risposte sensibili (dashboard, API auth)Variabile

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

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 PMI 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 sui controlli rilevanti (CSP +30, HSTS +20, X-Frame-Options +10, Referrer-Policy +5, Permissions-Policy +5, COOP/COEP/CORP +10, niente info disclosure +5, Cache-Control sensibile +5, niente header deprecati +10 = 100). 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)?
Solo Cache-Control quando c'e' indicazione di pagina sensibile (header che esprimono intent di privacy o di sessione tipo Set-Cookie). Content-Type viene controllato solo per X-Content-Type-Options: nosniff richiesto. 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 vulnerabilita' (XS-Leaks) ed era mantenuta solo per legacy IE/Edge. Mozilla raccomanda di rimuoverlo. 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). E' 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 <script nonce="...">.

Vuoi un hardening HTTP fatto da chi conosce davvero la materia?

Questo tool è un linter di triage. Per audit professionali (target in scope dichiarato, threat modeling, deploy graduale, monitoring CSP report-uri, hardening completo Apache/Nginx) lavoro su VPS unmanaged dei principali provider europei e su infrastrutture aziendali on-prem.

Hardening HTTP professionale

Vuoi una stima realistica per il tuo progetto?

Wizard di 7 domande, 2 minuti, gratuito. Output: range di giorni-uomo, range di prezzo orientativo e raccomandazione di ingaggio. Tariffa di riferimento 300 euro al giorno. Pensato per progetti backend custom, integrazioni, audit di sicurezza o automazione AI.

Calcola il preventivo