Header di sicurezza HTTP: CSP, HSTS, Permissions-Policy e configurazione completa

Non sono un firewall e non riparano autorizzazioni difettose, API vulnerabili, SQL injection, credenziali trapelate o dipendenze obsolete. Gli header di sicurezza sono un livello di difesa in profondità: riducono la superficie di attacco del browser e limitano ciò che può accadere dopo che un'altra debolezza è già stata sfruttata.

Nel 2026 è utile distinguere tre categorie:

1. Header di base che hanno senso per la maggior parte dei siti web.
2. Header dipendenti dall'architettura che possono compromettere OAuth, pagamenti, CDN, iframe o la distribuzione di PDF se copiati senza analisi.
3. Header obsoleti che non dovrebbero essere abilitati solo per migliorare il punteggio di uno scanner datato.

TL;DR: inizia con una Content Security Policy progettata con cura, HSTS dopo che HTTPS è pienamente implementato, X-Content-Type-Options: nosniff, un Referrer-Policy esplicito e un Permissions-Policy moderato. Usa frame-ancestors di CSP come controllo anti-framing principale e mantieni X-Frame-Options solo come livello di compatibilità. Implementa COOP, COEP e CORP solo dopo aver esaminato le integrazioni cross-origin. Rimuovi o disabilita X-XSS-Protection, Expect-CT, HPKP e il vecchio header Report-To.

Raccomandazioni e compatibilità verificate l'ultima volta il 23 luglio 2026.

I principali header in sintesi

Header	Raccomandazione tipica	Cosa limita	Usare ovunque?
Content-Security-Policy	policy specifica per l'applicazione, preferibilmente basata su nonce o hash	XSS, injection, origini di risorse non approvate e framing	sì per HTML, dopo i test
Strict-Transport-Security	max-age=31536000; includeSubDomains; aggiungi preload solo dopo una verifica	downgrade a HTTP e aggiramento degli errori di certificato	sì quando l'intero dominio è pronto per HTTPS
X-Content-Type-Options	nosniff	MIME sniffing e alcune confusioni di MIME	sì
Referrer-Policy	strict-origin-when-cross-origin o più restrittivo	fuga del percorso e della query dell'URL	sì
Permissions-Policy	disabilita funzionalità non utilizzate come camera=(), microphone=(), geolocation=()	uso di API del browser selezionate da parte di documenti e frame	di solito, dopo aver testato le funzionalità
CSP frame-ancestors	'none', 'self' o origini esplicite	clickjacking e framing indesiderato	sì per i documenti HTML
X-Frame-Options	DENY o SAMEORIGIN per compatibilità	framing nelle implementazioni più datate	spesso, insieme a frame-ancestors
Cross-Origin-Opener-Policy	spesso same-origin, a meno che non servano relazioni tramite popup	alcuni XS-Leaks e l'accesso a window.opener	dipende dall'architettura
Cross-Origin-Embedder-Policy	require-corp o credentialless, solo in modo deliberato	incorporamento di risorse cross-origin senza permesso	no, non automaticamente
Cross-Origin-Resource-Policy	same-origin, same-site o cross-origin per ciascuna risorsa	letture cross-origin no-CORS indesiderate	dipende dalla risorsa
Cache-Control	no-store per risposte altamente sensibili; private per contenuti personalizzati	archiviazione nelle cache del browser e intermediarie	per le risposte sensibili
Set-Cookie	Secure; HttpOnly; SameSite=Lax/Strict secondo necessità	furto e invio cross-site improprio dei cookie	per i cookie di sessione
Reporting-Endpoints	endpoint per i report di CSP/COOP/COEP	osservabilità delle policy	opzionale
X-XSS-Protection	ometti o imposta a 0	filtro XSS legacy	non abilitare
Expect-CT	rimuovi	meccanismo di Certificate Transparency obsoleto	no
Public-Key-Pins	non usare	certificate pinning ormai storico	no

OWASP considera gli header di risposta come preziosi controlli di hardening, sottolineando al contempo che ogni valore deve corrispondere al tipo di risposta e all'architettura dell'applicazione.

Un punto di partenza minimo

Questo è un modello di partenza, non una soluzione universale da copiare e incollare:

Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; font-src 'self'; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: DENY

Questa policy blocca script e stili inline, origini di risorse non elencate, framing, form inviati ad altre origini, l'accesso a camera/microfono/geolocalizzazione e la navigazione HTTP dopo che HSTS è stato memorizzato.

Se il sito utilizza font esterni, analytics, mappe, widget di pagamento, OAuth, tag manager, API di terze parti o codice inline, la policy deve essere adattata.

1. Content-Security-Policy: l'header più potente e più difficile

Content-Security-Policy definisce da dove il browser può caricare script, stili, immagini, font, frame e connessioni di rete. Una CSP corretta può ridurre notevolmente l'impatto di XSS e injection di dati, ma non sostituisce la validazione dell'input, la codifica dell'output e le API DOM sicure.

Direttive fondamentali

Direttiva	Scopo	Valore iniziale comune
default-src	fallback per i tipi di risorsa privi di una direttiva dedicata	'self'
script-src	script consentiti	nonce o hash, facoltativamente 'self'
style-src	stili consentiti	'self', nonce o hash
img-src	immagini	'self' data: https:
font-src	font	'self' e origini CDN esplicite
connect-src	Fetch, XHR, WebSocket ed EventSource	la tua API ed endpoint espliciti
frame-src	frame incorporati dalla pagina	solo le origini necessarie
frame-ancestors	quali pagine padre possono incorporare questa pagina	'none' o 'self'
form-action	destinazioni valide per i form	'self' o endpoint espliciti
base-uri	URL <base> consentiti	'self' o 'none'
object-src	plugin <object> ed <embed>	'none'
upgrade-insecure-requests	riscrive le sottorisorse HTTP in HTTPS	nessun valore

Allowlist rispetto a una CSP rigorosa

Un'allowlist di domini può diventare fragile. Una CDN attendibile può ospitare molti file non correlati e un loader di terze parti può caricare dinamicamente ulteriori dipendenze. web.dev raccomanda una CSP rigorosa basata su nonce o hash; strict-dynamic permette agli script caricati da uno script attendibile di ereditarne la fiducia.

Esempio di policy basata su nonce:

Content-Security-Policy:
  default-src 'self';
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'none';
  form-action 'self';
  script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic';
  style-src 'self' 'nonce-{RANDOM_NONCE}';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  upgrade-insecure-requests

HTML corrispondente:

<script nonce="{RANDOM_NONCE}">
  window.__APP_CONFIG__ = { apiUrl: "https://api.example.com" };
</script>

Un nonce deve essere imprevedibile, univoco per ogni risposta HTML, presente nell'header e negli elementi attendibili, e generato dal server. Un nonce costante memorizzato nella configurazione non fornisce la protezione prevista. Per le pagine statiche che non possono generare un nuovo valore a ogni richiesta, gli hash possono risultare più pratici.

Evita unsafe-inline e unsafe-eval

'unsafe-inline' in script-src consente il JavaScript inline e indebolisce notevolmente la protezione da XSS. 'unsafe-eval' abilita API che eseguono stringhe come codice, tra cui eval() e il costruttore Function.

Non aggiungerli solo per silenziare le violazioni nella console. Piuttosto:

1. sposta il codice inline in file esterni;
2. usa un nonce o un hash;
3. individua la dipendenza che richiede eval;
4. cerca una diversa configurazione di build o della libreria.

Trusted Types

Una policy come:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy

può richiedere valori tipizzati in determinati sink di DOM XSS come innerHTML. Da febbraio 2026, require-trusted-types-for è disponibile nei principali browser attuali, sebbene le versioni più datate possano non supportarlo.

Trusted Types è una difesa avanzata. L'applicazione deve definire policy di trasformazione sicure e i framework e le dipendenze devono essere compatibili. Aggiungere solo l'header non è sufficiente.

Inizia con Report-Only

Un rollout più sicuro inizia con:

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/security/csp-reports"

Content-Security-Policy-Report-Only segnala le violazioni senza bloccare le risorse, consentendo di individuare origini mancanti e flussi interrotti prima dell'applicazione. Reporting-Endpoints sostituisce l'header deprecato Report-To e dovrebbe essere preferito nelle implementazioni attuali.

Un endpoint di reporting dovrebbe applicare limiti sulla dimensione del payload, rate limiting, logging sicuro, codifica dell'output e un periodo di conservazione breve e specifico per lo scopo. I report CSP possono contenere URL e dettagli sulle risorse.

2. Strict-Transport-Security: HTTPS senza possibilità di downgrade

HSTS indica al browser che un host deve essere contattato solo tramite HTTPS. Una volta memorizzato, il browser aggiorna a HTTPS i futuri tentativi in HTTP e impedisce agli utenti di aggirare alcuni errori di certificato.

Strict-Transport-Security: max-age=31536000; includeSubDomains

• max-age=31536000 memorizza la policy per un anno.
• includeSubDomains copre i sottodomini.
• preload indica l'intenzione di entrare nella lista di preload dei browser.

Non iniziare con preload

Un'implementazione errata di HSTS può bloccare l'accesso agli utenti legittimi. Un vecchio sottodominio solo HTTP, un certificato scaduto o un servizio di terze parti sotto il tuo dominio possono rendere pericolosi includeSubDomains e un max-age lungo.

Un rollout prudente può usare:

5 minutes → 1 day → 1 week → 1 month → 1 year

A ogni fase testa il dominio apex, i sottodomini attivi, i certificati wildcard e SAN, i servizi legacy, i pannelli di amministrazione, le API e gli endpoint dei partner.

Il preload di HSTS richiede un certificato valido, redirect da HTTP a HTTPS, un max-age sufficientemente lungo, includeSubDomains e il token preload. La rimozione può richiedere settimane perché la lista viene distribuita all'interno dei browser.

3. X-Content-Type-Options: ferma il MIME guessing

X-Content-Type-Options: nosniff

Questo indica al browser di rispettare il Content-Type dichiarato invece di reinterpretare una risposta come un altro tipo. Script e stili possono essere bloccati quando il loro tipo MIME non corrisponde a quello previsto.

Non sostituisce una corretta configurazione del server. Le risposte necessitano comunque di valori accurati:

Content-Type: text/html; charset=utf-8
Content-Type: text/css; charset=utf-8
Content-Type: application/javascript; charset=utf-8
Content-Type: application/json; charset=utf-8
Content-Type: image/avif

Questo è particolarmente importante per i caricamenti degli utenti, gli endpoint di download, i file generati dinamicamente, l'object storage, le CDN e le risposte di errore che potrebbero restituire HTML invece di JSON.

4. Referrer-Policy: riduci la fuga di URL

Referrer-Policy controlla quanta parte dell'URL della pagina corrente può essere inviata nell'header Referer quando si richiede un'altra risorsa.

Un valore predefinito ragionevole è:

Referrer-Policy: strict-origin-when-cross-origin

Invia l'URL completo per le richieste same-origin, solo l'origine per le richieste HTTPS cross-origin e nessun referrer in caso di downgrade da HTTPS a HTTP.

Alternative più restrittive includono:

Referrer-Policy: no-referrer

oppure:

Referrer-Policy: same-origin

La scelta può influire su analytics, sistemi di affiliazione e provider di pagamento. Segreti, token, indirizzi email e dati personali non dovrebbero comunque essere inseriti negli URL.

5. Protezione dal clickjacking: frame-ancestors e X-Frame-Options

Il controllo più flessibile è CSP:

Content-Security-Policy: frame-ancestors 'none'

oppure:

Content-Security-Policy: frame-ancestors 'self' https://portal.partner.example

frame-ancestors definisce quali pagine padre possono incorporare un documento in <frame>, <iframe>, <object> o <embed>.

Per compatibilità, aggiungi:

X-Frame-Options: DENY

oppure:

X-Frame-Options: SAMEORIGIN

MDN raccomanda frame-ancestors per le implementazioni moderne perché è più espressivo. ALLOW-FROM è obsoleto e può indurre i browser attuali a ignorare l'header. X-Frame-Options deve essere un header HTTP; una versione <meta http-equiv> non ha alcun effetto.

6. Permissions-Policy: disabilita le funzionalità che il sito non usa

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

L'header controlla l'accesso da parte di un documento e dei suoi frame a determinate funzionalità del browser, tra cui camera, microfono e geolocalizzazione.

Consenti l'origine corrente:

Permissions-Policy: geolocation=(self), camera=(), microphone=()

Oppure consenti un'origine esplicita:

Permissions-Policy: geolocation=(self "https://maps.example")

Non copiare un elenco enorme di ogni direttiva conosciuta. Le singole direttive hanno un supporto diverso nei browser e alcune restano sperimentali. Individua le funzionalità utilizzate dall'applicazione, poi disabilita esplicitamente quelle pertinenti non utilizzate.

7. COOP, COEP e CORP: l'isolamento cross-origin non è un'impostazione predefinita universale

Questi header sono correlati ma risolvono problemi diversi.

Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy: same-origin

COOP controlla se i documenti aperti tramite navigazione o window.open() condividono un gruppo di contesti di navigazione. same-origin separa il documento dagli opener cross-origin e mitiga alcuni XS-Leaks.

Può compromettere i popup OAuth, le finestre di pagamento e le integrazioni che si basano su window.opener. In alcuni casi è più appropriato questo:

Cross-Origin-Opener-Policy: same-origin-allow-popups

Cross-Origin-Embedder-Policy

Cross-Origin-Embedder-Policy: require-corp

COEP richiede che le risorse cross-origin no-cors concedano il permesso tramite CORP o vengano recuperate con CORS. Header mancanti possono bloccare immagini, font, script, frame e altri asset di terze parti.

Un'alternativa è:

Cross-Origin-Embedder-Policy: credentialless

Questo consente alcune risorse no-cors senza CORP esplicito, rimuovendo al contempo le credenziali come i cookie.

Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy: same-origin

CORP è una policy sulla risorsa stessa e può usare:

• same-origin,
• same-site,
• cross-origin.

Non sostituisce CORS. MDN documenta inoltre un problema di Chrome relativo al rendering parziale dei PDF con alcune implementazioni di CORP, quindi l'header non dovrebbe essere applicato globalmente senza test.

La coppia:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

abilita l'isolamento cross-origin richiesto da determinate API avanzate, incluso l'accesso completo a SharedArrayBuffer. Non implementarla solo per il punteggio di uno scanner.

8. Cookie sicuri e caching

Set-Cookie e Cache-Control non sono sempre elencati tra gli header di sicurezza, ma proteggono direttamente le sessioni e i dati sensibili.

Cookie di sessione

Set-Cookie: __Host-session=RANDOM_VALUE; Path=/; Secure; HttpOnly; SameSite=Lax

• Secure limita la trasmissione a HTTPS.
• HttpOnly impedisce l'accesso da JavaScript.
• SameSite limita l'invio cross-site.
• __Host- richiede Secure, Path=/ e nessun Domain, vincolando il cookie più strettamente all'host.

SameSite=Strict è più efficace ma può interrompere i ritorni dai provider di login o di pagamento. SameSite=None richiede Secure e dovrebbe essere usato solo per un cookie realmente cross-site.

Risposte sensibili

Cache-Control: no-store

Questo chiede alle cache private e condivise di non memorizzare la risposta. I contenuti personalizzati che possono essere memorizzati nella cache del browser ma non dagli intermediari possono usare:

Cache-Control: private, no-cache

MDN raccomanda di contrassegnare esplicitamente le risposte personalizzate come private per evitare un caching condiviso accidentale.

9. Riduci la divulgazione della tecnologia

Header come:

Server: nginx/1.24.0
X-Powered-By: PHP/8.4
X-AspNet-Version: 4.0.30319

facilitano il fingerprinting. Rimuoverli non nasconde lo stack a un attaccante determinato, ma evita la divulgazione diretta della versione.

• rimuovi X-Powered-By;
• disabilita gli header di versione del framework;
• limita i dettagli in Server;
• non pubblicare una versione volutamente falsa;
• non confondere l'oscurità con l'applicazione delle patch.

OWASP raccomanda di rimuovere X-Powered-By e di limitare Server, pur osservando che le tecnologie possono comunque essere dedotte in altri modi.

10. Header obsoleti e consigli fuorvianti

X-XSS-Protection

Non abilitare:

X-XSS-Protection: 1; mode=block

OWASP avverte che i filtri XSS legacy possono creare vulnerabilità in pagine altrimenti sicure. Ometti l'header o disabilitalo esplicitamente:

X-XSS-Protection: 0

Usa invece CSP, la codifica dell'output e API sicure.

Expect-CT

Expect-CT è di fatto obsoleto perché i client attuali richiedono la Certificate Transparency per i certificati moderni. MDN lo descrive come ampiamente obsoleto da giugno 2021.

Public-Key-Pins

HPKP non dovrebbe essere implementato. Un pin errato potrebbe bloccare l'accesso agli utenti per lungo tempo e l'header è stato rimosso dai browser moderni. Preferisci un TLS corretto, il rinnovo automatico, CAA, il monitoraggio dei certificati e un preload HSTS esaminato con cura.

Report-To

Il vecchio:

Report-To: { ... }

è deprecato. Usa:

Reporting-Endpoints: csp="https://example.com/reports/csp"

Access-Control-Allow-Origin: *

CORS non è un insieme di header di hardening da aggiungere globalmente. Access-Control-Allow-Origin allenta la Same-Origin Policy. Le risposte API con credenziali non possono combinare in sicurezza il wildcard * con l'accesso cross-origin autenticato. Consenti solo le origini necessarie e validale lato server.

11. Esempi di configurazione del server

Nginx

add_header Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header X-Frame-Options "DENY" always;

always è importante perché mantiene gli header nelle risposte di errore e con status non standard.

Apache

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set X-Frame-Options "DENY"
</IfModule>

PHP

<?php

header("Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests");
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("X-Content-Type-Options: nosniff");
header("Referrer-Policy: strict-origin-when-cross-origin");
header("Permissions-Policy: camera=(), microphone=(), geolocation=()");
header("X-Frame-Options: DENY");

Gli header devono essere inviati prima del corpo della risposta. Genera un nonce crittograficamente casuale separatamente per ogni richiesta.

Node.js / Express

app.use((req, res, next) => {
  res.setHeader(
    "Content-Security-Policy",
    "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  );
  res.setHeader(
    "Strict-Transport-Security",
    "max-age=31536000; includeSubDomains"
  );
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
  res.setHeader(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=()"
  );
  res.setHeader("X-Frame-Options", "DENY");
  res.removeHeader("X-Powered-By");
  next();
});

Un sito che usa CDN, WebSocket, OAuth, pagamenti o mappe avrà bisogno di una CSP più ampia ma comunque esplicita.

12. Un processo di rollout che evita le interruzioni

Inventario

Elenca tutte le origini di script, stili, font e immagini; gli endpoint API e WebSocket; gli iframe; i popup OAuth/di pagamento; le risorse CDN; i caricamenti degli utenti; i sottodomini HSTS e le funzionalità del browser utilizzate dall'applicazione.

Osserva

• esegui la CSP in Report-Only;
• raccogli i report e le violazioni della console del browser;
• testa ogni percorso utente critico;
• includi i dispositivi mobili e i browser supportati;
• ispeziona le pagine di errore, i redirect e gli asset statici.

Applica gradualmente

• inizia con object-src, base-uri, frame-ancestors e form-action;
• passa alle risorse statiche;
• applica per ultimo uno script-src rigoroso;
• aumenta gradualmente il max-age di HSTS;
• testa COOP/COEP separatamente rispetto alle integrazioni con popup e cross-origin.

Monitora le regressioni

I test CI dovrebbero recuperare URL rappresentativi, rilevare header duplicati o in conflitto, confermare i tipi MIME, rilevare la rimozione accidentale di CSP/HSTS ed eseguire flussi end-to-end di login e pagamento.

13. Come testare gli header

Controlla direttamente la risposta:

curl -I https://example.com/

Segui i redirect:

curl -IL https://example.com/

Ispeziona una risorsa specifica:

curl -I https://example.com/assets/app.js

Verifica gli header sulla homepage, sul login e sulle risposte 404 e 500; conferma che la CSP non sia duplicata con policy in conflitto; assicurati che HSTS venga inviato solo tramite HTTPS; controlla i tipi MIME; e verifica che una CDN o un reverse proxy non abbia rimosso gli header.

Il gratuito Security Headers Inspector di POLPROG verifica HSTS, CSP, la protezione dal framing e altri controlli. Usa il DNS & SSL Inspector per i controlli su certificati e DNS, e Website Health Check per una revisione più ampia di SEO, prestazioni, accessibilità e sicurezza.

Checklist di implementazione

CSP

• default-src restrittivo.
• object-src 'none'.
• base-uri limitato.
• frame-ancestors corrisponde al modello di incorporamento reale.
• form-action limita le destinazioni dei form.
• Il codice inline usa un nonce o un hash quando necessario.
• Il nonce è univoco per ogni risposta.
• Nessun 'unsafe-inline' ingiustificato.
• Nessun 'unsafe-eval' ingiustificato.
• Policy testata prima in Report-Only.
• L'endpoint di report ha rate limit e conservazione limitata.

HTTPS e HSTS

• Ogni pagina e risorsa funziona tramite HTTPS.
• HTTP reindirizza direttamente a HTTPS.
• I certificati sono monitorati.
• Tutti i sottodomini sono inventariati.
• max-age aumentato per fasi.
• includeSubDomains è sicuro.
• preload aggiunto solo dopo aver esaminato le conseguenze.

Altri controlli

• X-Content-Type-Options: nosniff.
• Content-Type corretto su ogni risposta.
• Referrer-Policy esplicito.
• Permissions-Policy disabilita le funzionalità non utilizzate.
• Nessun ALLOW-FROM in X-Frame-Options.
• COOP non compromette OAuth o i pagamenti.
• COEP non blocca gli asset di terze parti necessari.
• CORP corrisponde al modello di condivisione di ogni risorsa.
• I cookie di sessione usano Secure, HttpOnly e un SameSite appropriato.
• Le risposte sensibili usano un Cache-Control corretto.
• Gli header di versione della tecnologia sono rimossi.
• X-XSS-Protection è assente o disabilitato.
• Expect-CT, HPKP e il vecchio Report-To sono rimossi.

Verdetto

Per la maggior parte dei siti web aziendali e delle applicazioni web, l'ordine corretto è:

1. HTTPS corretto, tipi MIME e cookie sicuri.
2. Una CSP specifica per l'applicazione, implementata tramite Report-Only.
3. HSTS implementato per fasi.
4. nosniff, Referrer-Policy, Permissions-Policy e protezione dal framing.
5. COOP, COEP e CORP solo quando il modello cross-origin è compreso.
6. Rimozione degli header obsoleti e di quelli che divulgano informazioni.

Il miglior insieme di header di sicurezza non è il più lungo. È la policy più piccola che corrisponde con precisione all'applicazione, supera i test dei percorsi critici e rimane monitorata dopo ogni implementazione.