Riferimento rapido per le intestazioni di sicurezza

Scopri di più sulle intestazioni che possono proteggere il tuo sito e cercare rapidamente i dettagli più importanti.

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
X GitHub

Questo articolo elenca le intestazioni di sicurezza più importanti che puoi utilizzare per proteggere il tuo sito web. Utilizzala per comprendere le funzionalità di sicurezza basate sul web, scoprire come implementarle sul tuo sito web e come riferimento per quando hai bisogno di un promemoria.

Intestazioni di sicurezza consigliate per i siti web che gestiscono dati utente sensibili:
Criterio di sicurezza del contenuto (CSP)
Tipi attendibili
Intestazioni di sicurezza consigliate per tutti i siti web:
X-Content-Type-Options
X-Frame-Options
Cross-Origin Resource Policy (CORP)
Cross-Origin Opener Policy (COOP)
HTTP Strict Transport Security (HSTS)
Intestazioni di sicurezza per i siti web con funzionalità avanzate:
Condivisione delle risorse tra origini (CORS)
Criterio di incorporamento multiorigine (COEP)
Minacce note sul web
Prima di approfondire le intestazioni di sicurezza, scopri le minacce note sul web e perché dovresti utilizzarli.

Prima di approfondire le intestazioni di sicurezza, scopri le minacce note sul web e perché dovresti utilizzarli.

Proteggi il tuo sito dalle vulnerabilità di iniezione

Le vulnerabilità di iniezione si verificano quando i dati non attendibili elaborati dall'applicazione possono influenzarne il comportamento e, in genere, portare all'esecuzione di script controllati da utenti malintenzionati. La vulnerabilità più comune causata dai bug di injection è il cross-site scripting (XSS) nelle sue varie forme, tra cui XSS riflesso, XSS archiviato, XSS basato su DOM e altre varianti.

Una vulnerabilità XSS in genere può concedere a un utente malintenzionato l'accesso completo ai dati utente elaborati dall'applicazione e a qualsiasi altra informazione ospitata nella stessa origine web.

Le difese tradizionali dalle iniezioni includono l'utilizzo coerente dei sistemi di modelli HTML con escape automatico, che evita l'uso di API JavaScript pericolose e una corretta elaborazione dei dati utente ospitando i caricamenti dei file in un dominio separato e purificando l'HTML controllato dagli utenti.

  • Utilizza il Criterio di sicurezza del contenuto (CSP) per controllare quali script possono essere eseguiti dalla tua applicazione per ridurre il rischio di iniezioni.
  • Utilizza TrustedType per applicare la sanitizzazione dei dati trasmessi in API JavaScript pericolose.
  • Utilizza X-Content-Type-Options per impedire al browser di interpretare erroneamente i tipi MIME delle risorse del tuo sito web, il che può portare all'esecuzione di script.

Isolare il sito da altri siti web

L'apertura del web consente ai siti web di interagire tra loro in modi che possono violare le aspettative di sicurezza di un'applicazione. Ciò include l'invio imprevisto di richieste autenticate o l'incorporamento di dati da un'altra applicazione nel documento dell'utente malintenzionato, consentendo all'utente malintenzionato di modificare o leggere i dati dell'applicazione.

Le vulnerabilità comuni che compromettono l'isolamento web includono clickjacking, richiesta di falsificazione di richieste tra siti (CSRF), inclusione di script tra siti (XSSI) e varie fuga di dati tra siti.

Post-Spectre Web Development è un'ottima lettura se ti interessano queste intestazioni.

Crea un sito web efficace e sicuro

Spectre inserisce tutti i dati caricati nello stesso gruppo di contesto di navigazione potenzialmente leggibile nonostante il criterio della stessa origine. I browser limitano le funzionalità che potrebbero sfruttare la vulnerabilità di un ambiente speciale chiamato "isolamento multiorigine". Con l'isolamento multiorigine, puoi utilizzare funzionalità efficaci come SharedArrayBuffer.

Criptare il traffico verso il tuo sito

I problemi di crittografia si verificano quando un'applicazione non cripta completamente i dati in transito, consentendo a utenti malintenzionati di intercettare le interazioni dell'utente con l'applicazione.

Nei seguenti casi può verificarsi una crittografia insufficiente: non utilizzare HTTPS, contenuti misti, impostare i cookie senza l'attributo Secure (o __Secure prefisso) o una logica di convalida CORS rigorosa.

Criterio di sicurezza del contenuto (CSP)

Cross-Site Scripting (XSS) è un attacco in cui una vulnerabilità in un sito web consente di inserire ed eseguire uno script dannoso.

Content-Security-Policy fornisce un livello aggiuntivo per mitigare gli attacchi XSS limitando gli script che possono essere eseguiti dalla pagina.

Ti consigliamo di abilitare il criterio CSP rigido utilizzando uno dei seguenti approcci:

  • Se esegui il rendering delle pagine HTML sul server, utilizza un CSP rigoroso nonce-based.
  • Se il codice HTML deve essere pubblicato in modo statico o memorizzato nella cache, ad esempio nel caso di un'applicazione a pagina singola, utilizza un CSP rigoroso basato su hash.

Esempio di utilizzo: un CSP basato su nonce

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
Come utilizzare CSP

1. Utilizza un criterio CSP rigido nonce {: #nonce-based-csp}

Se esegui il rendering delle pagine HTML sul server, utilizza un CSP rigoroso nonce-based.

Genera un nuovo valore nonce dello script per ogni richiesta lato server e imposta la seguente intestazione:

file di configurazione del server

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Nel codice HTML, per caricare gli script, imposta l'attributo nonce di tutti i tag <script> sulla stessa stringa {RANDOM1}.

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Google Foto è un buon esempio di CSP rigoroso basato sul nonce. Utilizza DevTools per vedere come viene utilizzato.

2. Utilizza un CSP rigoroso basato su hash {: #hash-based-csp}

Se il codice HTML deve essere pubblicato in modo statico o memorizzato nella cache, ad esempio se stai creando un'applicazione a pagina singola, utilizza un CSP rigoroso basato su hash.

file di configurazione del server

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

Poiché la maggior parte dei browser non supporta l'hashing degli script esterni, devi incorporare i tuoi script in HTML.

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

Per caricare script esterni, leggi "Carica gli script con origine dinamica" nella sezione Opzione B: intestazione della risposta CSP basata su hash.

CSP Evaluator è un buon strumento per valutare il tuo CSP, ma allo stesso tempo un buon esempio di CSP rigoroso basato sul nonce. Utilizza DevTools per vedere come viene utilizzato.

Browser supportati

Altri aspetti da considerare sui CSP

Scopri di più

Tipi attendibili

XSS basato su DOM è un attacco tramite il quale i dati dannosi vengono trasmessi in un sink che supporta l'esecuzione di codice dinamico come eval() o .innerHTML.

I tipi attendibili forniscono gli strumenti per scrivere, esaminare la sicurezza e gestire le applicazioni prive di DOM XSS. Possono essere attivati tramite CSP e rendere sicuro il codice JavaScript per impostazione predefinita, limitando le API web pericolose ad accettare solo un oggetto speciale: un tipo attendibile.

Per creare questi oggetti, puoi definire criteri di sicurezza in cui le regole di sicurezza (come l'escape o la sanitizzazione) vengano applicate in modo coerente prima che i dati vengano scritti nel DOM. Queste norme sono quindi le uniche posizioni nel codice che potrebbero introdurre DOM XSS.

Esempi di utilizzo

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
Come utilizzare i tipi attendibili

  1. Applica i tipi attendibili per i sink DOM pericolosi Intestazione CSP e TrustedType: 

    Content-Security-Policy: require-trusted-types-for 'script'

    Attualmente 'script' è l'unico valore accettabile per l'istruzione require-trusted-types-for.

    Naturalmente, puoi combinare Tipi attendibili con altre direttive CSP:

Unione di un CSP non basato sull'ceo dall'alto con i tipi attendibili: 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;




<aside class="note"><b>Nota. </b> Puoi limitare i nomi delle norme per i tipi attendibili consentiti impostando un'ulteriore direttiva <code>Trusted-types</code> (ad esempio, <code>Trusted-types myPolicy</code>). Tuttavia, non si tratta di un requisito.  </aside>


    
  
  1. 
    
    Definisci un criterio
    
    
    Norme:
    
   
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}

    
    
  
    2. 
  
  2. 
    
    Applica il criterio
    
    
    Utilizza il criterio durante la scrittura di dati nel DOM:
    
   
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;

    
    
    Con require-trusted-types-for 'script', è obbligatorio utilizzare un tipo attendibile. L'utilizzo di un'API DOM pericolosa con una stringa comporterà un errore.
    
  
    3. 



Browser supportati



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Scopri di più

X-Content-Type-Options

Quando un documento HTML dannoso viene pubblicato dal tuo dominio (ad esempio, se un'immagine caricata su un servizio fotografico contiene markup HTML valido), alcuni browser lo considerano come un documento attivo e gli consentono di eseguire script nel contesto dell'applicazione, generando un bug di cross-site scripting.

X-Content-Type-Options: nosniff lo impedisce indicando al browser che il tipo MIME impostato nell'intestazione Content-Type per una determinata risposta è corretto. Questa intestazione è consigliata per tutte le risorse.

Esempio di utilizzo

X-Content-Type-Options: nosniff
Come utilizzare X-Content-Type-Options

La funzionalità X-Content-Type-Options: nosniff è consigliata per tutte le risorse pubblicate dal tuo server insieme all'intestazione Content-Type corretta.

X-Content-Type-Options: nosniff

Intestazioni di esempio inviate con un codice HTML di un documento

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

Browser supportati

Supporto dei browser

  • 64
  • 12
  • 50
  • 11

Fonte

Scopri di più

Opzioni X-Frame

Se un sito web dannoso può incorporare il tuo sito come iframe, gli utenti malintenzionati potrebbero attivare azioni indesiderate da parte dell'utente con il clickjacking. Inoltre, in alcuni casi gli attacchi di tipo Spectre offrono ai siti web dannosi la possibilità di ottenere informazioni sui contenuti di un documento incorporato.

X-Frame-Options indica se un browser deve essere autorizzato o meno a visualizzare una pagina in <frame>, <iframe>, <embed> o <object>. Si consiglia di inviare questa intestazione per tutti i documenti per indicare se è consentita l'incorporamento in altri documenti.

Esempio di utilizzo

X-Frame-Options: DENY
Come utilizzare X-Frame-Options

Tutti i documenti che non sono progettati per essere incorporati devono utilizzare l'intestazione X-Frame-Options.

Puoi provare in che modo le configurazioni seguenti influiscono sul caricamento di un iframe in questa demo. Modifica il menu a discesa X-Frame-Options e fai clic sul pulsante Ricarica iframe.

Protegge il tuo sito web dall'incorporamento da parte di altri siti web.

Negare l'incorporamento in altri documenti.

X-Frame-Options: DENY 
X-Frame-Options: DENY

Impedisce l'incorporamento del tuo sito web da parte di siti web multiorigine

Consenti l'incorporamento solo da documenti della stessa origine.

X-Frame-Options: SAMEORIGIN

Browser supportati

Supporto dei browser

  • 4
  • 12
  • 4
  • 4

Fonte

Scopri di più

Criterio delle risorse multiorigine (CORP)

Un utente malintenzionato può incorporare risorse di un'altra origine, ad esempio del tuo sito, per apprendere informazioni al riguardo sfruttando le fuga di notizie tra siti basate sul web.

Cross-Origin-Resource-Policy riduce questo rischio indicando l'insieme di siti web da cui può essere caricato. L'intestazione accetta uno dei tre valori seguenti: same-origin, same-site e cross-origin. Consigliamo di inviare questa intestazione per tutte le risorse per indicare se consentono il caricamento da parte di altri siti web.

Esempio di utilizzo

Cross-Origin-Resource-Policy: same-origin
Come utilizzare CORP

Ti consigliamo di pubblicare tutte le risorse con una delle tre intestazioni seguenti.

Puoi provare in che modo le configurazioni seguenti influiscono sul caricamento delle risorse in un ambiente Cross-Origin-Embedder-Policy: require-corp in questa demo. Modifica il menu a discesa Cross-Origin-Resource-Policy e fai clic sul pulsante Ricarica l'iframe o Ricarica l'immagine per vedere l'effetto.

Consenti il caricamento delle risorse cross-origin

Ti consigliamo di applicare cross-origin alle risorse da parte dei servizi simili a CDN (poiché di solito vengono caricate da pagine multiorigine), a meno che non vengano già pubblicate tramite CORS, con un effetto simile.

Criteri delle risorse multiorigine: multiorigine 
Cross-Origin-Resource-Policy: cross-origin

Limita le risorse da caricare da same-origin

same-origin deve essere applicato alle risorse che devono essere caricate solo da pagine della stessa origine. Devi applicarlo alle risorse che includono informazioni sensibili sull'utente o le risposte di un'API che deve essere chiamata solo dalla stessa origine.

Tieni presente che le risorse con questa intestazione possono comunque essere caricate direttamente, ad esempio passando all'URL in una nuova finestra del browser. Il criterio delle risorse multiorigine protegge solo la risorsa dall'incorporamento da altri siti web.

Criteri delle risorse multiorigine: same-origin 
Cross-Origin-Resource-Policy: same-origin

Limita le risorse da caricare da same-site

Ti consigliamo di applicare same-site a risorse simili a quelle precedenti, ma che devono essere caricate da altri sottodomini del tuo sito.

Criteri delle risorse multiorigine: same-site 
Cross-Origin-Resource-Policy: same-site

Browser supportati

Supporto dei browser

  • 73
  • 79
  • 74
  • 12

Fonte

Scopri di più

Politica di apertura multiorigine (COOP)

Il sito web di un utente malintenzionato può aprire un altro sito in una finestra popup per ottenere informazioni al riguardo sfruttando le fuga di notizie tra siti basate sul web. In alcuni casi, ciò potrebbe anche consentire lo sfruttamento di attacchi side-channel basati su Spectre.

L'intestazione Cross-Origin-Opener-Policy consente a un documento di isolarsi dalle finestre multiorigine aperte tramite window.open() o da un link con target="_blank" senza rel="noopener". Di conseguenza, qualsiasi elemento di apertura multiorigine del documento non avrà alcun riferimento al documento e non potrà interagire con il documento.

Esempio di utilizzo

Cross-Origin-Opener-Policy: same-origin-allow-popups
Come utilizzare COOP

Puoi provare in che modo le configurazioni seguenti influiscono sulla comunicazione con una finestra popup multiorigine in questa demo. Modifica il menu a discesa Cross-Origin-Opener-Policy sia per il documento che per la finestra popup, fai clic sul pulsante Apri un popup, quindi su Invia un postMessage per vedere se il messaggio è stato effettivamente recapitato.

Isolare un documento dalle finestre multiorigine

L'impostazione same-origin consente di isolare il documento dalle finestre dei documenti multiorigine.

Criteri di apertura multiorigine: same-origin 
Cross-Origin-Opener-Policy: same-origin

Isola un documento dalle finestre multiorigine, ma consenti i popup

L'impostazione di same-origin-allow-popups consente a un documento di conservare un riferimento alle sue finestre popup, a meno che non imposti COOP con same-origin o same-origin-allow-popups. Ciò significa che same-origin-allow-popups può comunque proteggere il documento dai riferimenti quando viene aperto come finestra popup, ma consentirgli di comunicare con i propri popup.

Criteri di apertura multiorigine: same-origin-allow-popups 
Cross-Origin-Opener-Policy: same-origin-allow-popups

Consenti il riferimento a un documento nelle finestre multiorigine

unsafe-none è il valore predefinito, ma puoi indicare esplicitamente che questo documento può essere aperto da una finestra multiorigine e mantenere l'accesso reciproco.

Criterio di apertura multiorigine: non sicuro-nessuno 
Cross-Origin-Opener-Policy: unsafe-none

Pattern di segnalazione incompatibili con COOP

Puoi ricevere report quando COOP impedisce le interazioni tra finestre con l'API di reporting.

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP supporta anche la modalità di solo report, che ti consente di ricevere report senza bloccare effettivamente la comunicazione tra documenti multiorigine.

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

Browser supportati

Supporto dei browser

  • 83
  • 83
  • 79
  • 15.2

Fonte

Scopri di più

Condivisione delle risorse tra origini (CORS)

A differenza degli altri elementi in questo articolo, la condivisione delle risorse tra origini (CORS) non è un'intestazione, ma un meccanismo browser che richiede e consente l'accesso alle risorse multiorigine.

Per impostazione predefinita, i browser applicano il criterio della stessa origine per impedire a una pagina web di accedere alle risorse multiorigine. Ad esempio, quando viene caricata un'immagine multiorigine, anche se viene visualizzata visivamente sulla pagina web, il codice JavaScript nella pagina non ha accesso ai dati dell'immagine. Il provider di risorse può ridurre le limitazioni e consentire ad altri siti web di leggere la risorsa attivando con CORS.

Esempio di utilizzo

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Come utilizzare CORS

Prima di scoprire come configurare CORS, è utile comprendere la distinzione tra i tipi di richieste. A seconda dei dettagli, una richiesta verrà classificata come richiesta semplice o richiesta preflight.

Criteri per una richiesta semplice:

  • Il metodo è GET, HEAD o POST.
  • Le intestazioni personalizzate includono solo Accept, Accept-Language, Content-Language e Content-Type.
  • Content-Type è application/x-www-form-urlencoded, multipart/form-data o text/plain.

Tutto il resto è classificato come richiesta preflight. Per ulteriori dettagli, consulta Condivisione delle risorse tra origini (CORS) - HTTP | MDN.

Richiesta semplice

Quando una richiesta soddisfa i semplici criteri della richiesta, il browser invia una richiesta multiorigine con un'intestazione Origin che indica l'origine richiedente.

Intestazione di richiesta di esempio

Get / HTTP/1.1
Origin: https://example.com

Intestazione di esempio della risposta

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com indica che https://example.com può accedere ai contenuti della risposta. Le risorse pensate per essere leggibili da qualsiasi sito possono impostare questa intestazione su *, nel qual caso il browser richiederà solo che la richiesta venga effettuata senza credenziali.
  • Access-Control-Allow-Credentials: true indica che le richieste che contengono credenziali (cookie) sono autorizzate a caricare la risorsa. In caso contrario, le richieste autenticate verranno rifiutate anche se l'origine richiedente è presente nell'intestazione Access-Control-Allow-Origin.

Puoi provare come la semplice richiesta influisce sul caricamento delle risorse in un ambiente Cross-Origin-Embedder-Policy: require-corp in questa demo. Fai clic sulla casella di controllo Condivisione delle risorse tra origini e sul pulsante Ricarica l'immagine per vedere l'effetto.

Richieste preflight

Una richiesta preflight è preceduta da una richiesta OPTIONS per verificare se è possibile inviare la richiesta successiva.

Intestazione di richiesta di esempio

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST consente di effettuare la seguente richiesta con il metodo POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type consente al richiedente di impostare le intestazioni HTTP X-PINGOTHER e Content-Type nella richiesta successiva.

Intestazioni di risposta di esempio

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS indica che le richieste successive possono essere effettuate con i metodi POST, GET e OPTIONS.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type indica che le richieste successive possono includere le intestazioni X-PINGOTHER e Content-Type.
  • Access-Control-Max-Age: 86400 indica che il risultato della richiesta preflight può essere memorizzato nella cache per 86.400 secondi.

Browser supportati

Supporto dei browser

  • 4
  • 12
  • 3,5
  • 4

Fonte

Scopri di più

Politica sull'incorporamento multiorigine (COEP)

Per ridurre la capacità degli attacchi basati su Spectre di sottrarre risorse multiorigine, funzionalità come SharedArrayBuffer o performance.measureUserAgentSpecificMemory() sono disattivate per impostazione predefinita.

Cross-Origin-Embedder-Policy: require-corp impedisce a documenti e worker di caricare risorse multiorigine come immagini, script, fogli di stile, iframe e altro, a meno che per queste risorse non venga esplicitamente attivato il caricamento tramite intestazioni CORS o CORP. Il COEP può essere combinato conCross-Origin-Opener-Policy per attivare l'isolamento multiorigine per un documento.

Utilizza Cross-Origin-Embedder-Policy: require-corp per attivare l'isolamento multiorigine per il tuo documento.

Esempio di utilizzo

Cross-Origin-Embedder-Policy: require-corp
Come utilizzare COEP

Esempi di utilizzo

COEP utilizza un singolo valore pari a require-corp. Se invii questa intestazione, puoi indicare al browser di bloccare il caricamento delle risorse che non vengono attivate tramite CORS o CORP.

Come funziona COEP

Puoi provare in che modo le configurazioni seguenti influiscono sul caricamento delle risorse in questa demo. Modifica il menu a discesa Cross-Origin-Embedder-Policy, il menu a discesa Cross-Origin-Resource-Policy, la casella di controllo Solo report e così via per vedere come influiscono sul caricamento delle risorse. Inoltre, apri la demo dell'endpoint di reporting per vedere se le risorse bloccate vengono segnalate.

Attivare l'isolamento multiorigine

Abilita l'isolamento multiorigine inviando Cross-Origin-Embedder-Policy: require-corp insieme a Cross-Origin-Opener-Policy: same-origin. 

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

Segnala risorse incompatibili con il COEP

Puoi ricevere report sulle risorse bloccate a causa della COEP con l'API di reporting.

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

Il COEP supporta anche la modalità di solo report in modo da poter ricevere i report senza bloccare effettivamente il caricamento delle risorse.

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

Browser supportati

Supporto dei browser

  • 83
  • 83
  • 79
  • 15.2

Fonte

Scopri di più

HSTS (HTTP Strict Transport Security)

Le comunicazioni tramite una semplice connessione HTTP non vengono criptate, rendendo i dati trasferiti accessibili alle intercettazioni a livello di rete.

L'intestazione Strict-Transport-Security indica al browser che non dovrebbe mai caricare il sito tramite HTTP e utilizzare invece HTTPS. Dopo la configurazione, il browser utilizzerà HTTPS invece di HTTP per accedere al dominio senza un reindirizzamento per una durata definita nell'intestazione.

Esempio di utilizzo

Strict-Transport-Security: max-age=31536000
Come utilizzare HSTS

Tutti i siti web che passano da HTTP a HTTPS devono rispondere con un'intestazione Strict-Transport-Security alla ricezione di una richiesta con HTTP. 

Strict-Transport-Security: max-age=31536000

Browser supportati

Supporto dei browser

  • 4
  • 12
  • 4
  • 7

Fonte

Scopri di più

Per approfondire