Riferimento rapido per le intestazioni di sicurezza

Scopri di più sulle intestazioni che possono mantenere sicuro 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 del tuo sito web. Usalo per comprendere le funzionalità di sicurezza basate sul web e scoprire come implementarle sul tuo sito web e usarle come riferimento 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 di fiducia
Intestazioni di sicurezza consigliate per tutti i siti web:
X-Content-Type-Options
X-Frame-Options
Criteri delle risorse tra origini (CORP)
Criterio di apertura multiorigine (COOP)
HTTP Strict Transport Security (HSTS)
Intestazioni di sicurezza per i siti web con funzionalità avanzate:
Condivisione delle risorse tra origini (CORS)
Norme sull'incorporamento multiorigine (COEP)
Minacce note sul web
Prima di approfondire le intestazioni di sicurezza, scopri le minacce note sul web e perché dovresti utilizzare queste intestazioni di sicurezza.

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

Proteggi il tuo sito dalle vulnerabilità di inserimento

Le vulnerabilità di injection si verificano quando dati non attendibili elaborati dal tuo un'applicazione può influenzare il suo comportamento e, di solito, portare all'esecuzione di script controllati dall'aggressore. La vulnerabilità più comune causata dall'inserimento di dati I bug sono cross-site di scripting (XSS) in nelle sue varie forme, tra cui riflette XSS, XSS archiviati, Basato su DOM XSS e le altre varianti.

Generalmente, una vulnerabilità XSS può garantire a un utente malintenzionato l'accesso completo ai dati utente trattati dall'applicazione e da eventuali altre informazioni ospitate nello stesso sito web origine.

Le difese tradizionali contro le iniezioni includono un uso coerente dell'evasione automatica sistemi basati su modelli HTML, evitando l'uso di JavaScript pericoloso API ed elaborando correttamente i dati utente tramite l'hosting i caricamenti di file in un dominio separato e la sanificazione del codice HTML controllato dagli utenti.

  • Utilizza il Criterio di sicurezza del contenuto (CSP) per stabilire quali script possono essere eseguite dall'applicazione per ridurre il rischio di iniezioni.
  • Usa i tipi attendibili per applicare la sanificazione dei dati trasmessi a minacce pericolose API JavaScript.
  • Utilizza X-Content-Type-Options per impedire al browser di interpretare erroneamente i tipi MIME delle risorse del sito web, il che può comportare dell'esecuzione dello script.

Isolare il sito da altri siti web

L'apertura del web consente ai siti web di interagire tra loro in modo da può violare le aspettative di sicurezza di un'applicazione. Questo include inaspettatamente effettuare richieste autenticate o incorporare dati da un'altra applicazione il documento dell'aggressore, consentendogli di modificare o leggere i dati dell'applicazione.

Le vulnerabilità più comuni che compromettono l'isolamento web includono: clickjacking, cross-site richiesta di falsificazione (CSRF), cross-site l'inclusione di script (XSSI) e vari fuga di dati tra siti.

Post-Spectre sul web Sviluppo è un'ottima lettura se ti interessano queste intestazioni.

Crea un sito web efficace in modo 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 potrebbe sfruttare la vulnerabilità che si cela dietro un ambiente speciale chiamato "isolamento multiorigine". Con l'isolamento multiorigine, puoi usano funzionalità potenti come SharedArrayBuffer.

Cripta il traffico verso il tuo sito

I problemi di crittografia si verificano quando un'applicazione non cripta completamente i dati in il trasporto pubblico, consentendo agli aggressori di intercettare le interazioni dell'utente con l'applicazione.

Una crittografia insufficiente può verificarsi nei seguenti casi: non si utilizza HTTPS, contenuti misti, impostando cookie senza Secure attributo (o __Secure prefisso), oppure convalida CORS lenta della logica.

Criterio di sicurezza del contenuto (CSP)

Cross-Site Scripting (XSS) è un attacco una vulnerabilità di un sito web per cui è possibile iniettare uno script dannoso eseguito.

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

Ti consigliamo di abilitare un criterio CSP rigoroso utilizzando uno dei seguenti approcci:

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

Esempio di utilizzo: un CSP nonce basato su

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

1. Utilizza un CSP rigoroso nonce basato su {: #nonce-based-csp}

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

Genera un nuovo valore nonce dello script per ogni richiesta sul 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';

Per caricare gli script in HTML, imposta l'attributo nonce di tutti Tag <script> alla 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 CSP rigoroso nonce basato su Nonce esempio. Utilizza DevTools per scoprire come vengono utilizzati.

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 creando un'applicazione a pagina singola, usa 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';

Nel codice HTML, dovrai incorporare gli script per poter applicare un prompt basato su hash perché la maggior parte dei browser non supporta l'hashing esterno script.

index.html

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

Per caricare script esterni, consulta "Caricare dinamicamente gli script originati" sotto Opzione B: intestazione della risposta CSP basata su hash.

CSP Valutatore è un ottimo strumento per Valutare il tuo CSP, ma allo stesso tempo è un buon esempio di CSP rigoroso e basato su nonce. Utilizza DevTools per scoprire come vengono utilizzati.

Browser supportati

Altri aspetti da considerare su CSP

Scopri di più

Tipi attendibili

Basato sul DOM XSS (cross-site scripting) è un attacco per cui dati dannosi vengono passati in un sink che supporta codice dinamico dei dati, come eval() o .innerHTML.

I tipi di attendibilità offrono gli strumenti per scrivere, verificare la sicurezza e mantenere senza DOM XSS. Possono essere abilitate tramite CSP e rendono Il codice JavaScript è sicuro per impostazione predefinita, limitando l'accettazione delle API web pericolose un oggetto speciale, un tipo affidabile.

Per creare questi oggetti è possibile definire criteri di sicurezza in cui che le regole di sicurezza (come escape o sanitizzazione) vengano applicate in modo coerente prima che i dati vengano scritti nel DOM. Queste norme sono le uniche posizioni nel codice che potrebbe introdurre DOM XSS.

Esempi di utilizzi

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 di attendibilità

  1. Applica i tipi attendibili per i sink DOM pericolosi Intestazione CSP e Tipi di attendibilità: 

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

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

    Naturalmente, puoi combinare i tipi attendibili con altre direttive CSP:

Unione di un CSP nonce basato sopra indicato 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 dei criteri di tipi attendibili consentiti impostando un valore aggiuntivo <code>trusted-types</code> (ad esempio, <code>trusted-types myPolicy</code>). Tuttavia, questo non è 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 dei 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', l'utilizzo di un tipo attendibile è
      requisito. L'utilizzo di API DOM pericolose con una stringa comporterà un
      .
    
  
    3. 



Browser supportati



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Scopri di più

X-Content-Type-Options

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

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

Esempio di utilizzo

X-Content-Type-Options: nosniff
Utilizzo di X-Content-Type-Options

X-Content-Type-Options: nosniff è consigliato per tutte le risorse fornite da server insieme all'intestazione Content-Type corretta.

X-Content-Type-Options: nosniff

Intestazioni di esempio inviate con un documento HTML

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

Browser supportati

Supporto dei browser

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Origine

Scopri di più

X-Frame-Options

Se un sito web dannoso può incorporare il tuo sito come iframe, ciò potrebbe consentire gli utenti malintenzionati richiamano azioni indesiderate da parte dell'utente con clickjacking. Inoltre, in alcune custodie Spectre-type attacchi informatici siti web dannosi la possibilità di venire a conoscenza dei contenuti di un documento incorporato.

X-Frame-Options indica se un browser deve essere autorizzato o meno a eseguire il rendering una pagina in <frame>, <iframe>, <embed> o <object>. Tutti i documenti si consiglia di inviare questa intestazione per indicare se consentono incorporati da altri documenti.

Esempio di utilizzo

X-Frame-Options: DENY
Come usare X-Frame-Options

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

Puoi provare a in che modo le seguenti configurazioni influiscono sul caricamento di un iframe su questo una demo. Cambia X-Frame-Options e fai clic sul pulsante Ricarica l'iframe.

Protezione del tuo sito web dall'incorporamento in altri siti web

Negare l'incorporamento da parte di altri documenti.

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

Protezione del tuo sito web dall'incorporamento in siti web multiorigine

Consenti l'incorporamento solo da documenti della stessa origine.

X-Frame-Options: SAMEORIGIN

Browser supportati

Supporto dei browser

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

Origine

Scopri di più

Criterio delle risorse tra origini (CORP)

Un utente malintenzionato può incorporare risorse di un'altra origine, ad esempio dal tuo sito, di acquisirne informazioni sfruttando le funzionalità basate sul web cross-site di fughe di notizie.

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

Esempio di utilizzo

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

È consigliabile che tutte le risorse vengano pubblicate con uno dei seguenti elementi tre intestazioni.

Puoi provare a come le seguenti configurazioni influiscono sul caricamento delle risorse in un Ambiente Cross-Origin-Embedder-Policy: require-corp su questo una demo. Cambia il Cross-Origin-Resource-Policy e fai clic sul pulsante Ricarica il iframe o il pulsante Ricarica l'immagine per vedere l'effetto.

Consenti il caricamento delle risorse cross-origin

È consigliabile applicare cross-origin alle risorse per i servizi simili a CDN (poiché vengono solitamente caricati da pagine multiorigine), a meno che non siano già pubblicati tramite CORS, che ha un effetto simile.

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

Limita il caricamento delle risorse da same-origin

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

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

Criteri delle risorse-tra origini: stessa origine 
Cross-Origin-Resource-Policy: same-origin

Limita il caricamento delle risorse da same-site

Ti consigliamo di applicare same-site a risorse simili a quelle riportate sopra ma che sono destinati a essere caricati da altri sottodomini del tuo sito.

Criterio-risorsa-tra-origine: stesso sito 
Cross-Origin-Resource-Policy: same-site

Browser supportati

Supporto dei browser

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

Origine

Scopri di più

Policy di apertura multiorigine (COOP)

Il sito web di un aggressore può aprire un altro sito in una finestra popup per apprendere informazioni al riguardo sfruttando l'cross-site di fughe di notizie. In alcuni casi, ciò potrebbe consentire anche Sfruttamento di attacchi side-channel basati su Spectre.

L'intestazione Cross-Origin-Opener-Policy consente a un documento di isolare da finestre multiorigine aperte tramite window.open() o tramite un link con target="_blank" senza rel="noopener". Di conseguenza, qualsiasi strumento di apertura multiorigine del documento non vi farà riferimento e non potrà interagire con essa.

Esempio di utilizzo

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

Puoi provare a come le seguenti configurazioni influiscono sulla comunicazione con un finestra popup multiorigine in questa demo. Modifica il menu a discesa Cross-Origin-Opener-Policy per entrambi i documenti e nella finestra popup, fai clic sul pulsante Apri un popup, quindi fai clic su Invia un postMessage per vedere se il messaggio viene effettivamente consegnato.

Isolare un documento da finestre multiorigine

L'impostazione di same-origin consente di isolare il documento da più origini finestre di documenti.

Criterio di apertura multiorigine: stessa origine 
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 a tutte le finestre popup, a meno che non impostino COOP con same-origin o same-origin-allow-popups. Ciò significa che same-origin-allow-popups può comunque impedisce che venga fatto riferimento al documento quando viene aperto come finestra popup, ma consentirgli di comunicare con i propri popup.

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

Consenti il riferimento a un documento da finestre multiorigine

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

Criteri di apertura multiorigine: non sicuro di Gemini Advanced. 
Cross-Origin-Opener-Policy: unsafe-none

Pattern di report non compatibili con COOP

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

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

COOP supporta anche una modalità di sola segnalazione che ti consente di ricevere report senza bloccare effettivamente le comunicazioni tra documenti multiorigine.

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

Browser supportati

Supporto dei browser

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Origine

Scopri di più

Condivisione delle risorse tra origini (CORS)

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

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

Esempio di utilizzo

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

Prima di vedere come configurare CORS, è utile comprendere la distinzione tra i tipi di richiesta. In base ai dettagli della richiesta, essere 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.
  • Il valore 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 criteri di richiesta semplici, il browser invia una richiesta multiorigine con un'intestazione Origin che indica la richiesta origine dati.

Intestazione della richiesta di esempio

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

Intestazione di risposta di esempio

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. Risorse significate per essere leggibile da qualsiasi sito può impostare questa intestazione su *. In questo caso il browser richiederà solo di effettuare la richiesta senza credenziali.
  • Access-Control-Allow-Credentials: true indica che le richieste che trasportano le credenziali (cookie) siano autorizzate a caricare la risorsa. Altrimenti, le richieste autenticate saranno rifiutate anche se l'origine richiedente è presente nell'intestazione Access-Control-Allow-Origin.

Puoi provare in che modo la richiesta semplice influisce sul caricamento delle risorse in un Ambiente Cross-Origin-Embedder-Policy: require-corp su questo una demo. Fai clic sull' Casella di controllo Condivisione delle risorse tra origini e fai clic sulla casella Ricarica l'immagine. per vedere l'effetto.

Richieste con periodo di pubblicazione prestabilito

Una richiesta preflight è preceduta da una richiesta OPTIONS per verificare se di una richiesta successiva.

Intestazione della 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 l'invio della seguente richiesta con il metodo POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type consente di impostare le intestazioni HTTP X-PINGOTHER e Content-Type nel successiva richiesta.

Esempi di intestazioni di risposta

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 successive possono essere effettuate con i metodi POST, GET e OPTIONS.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type indica le successive possono includere le intestazioni X-PINGOTHER e Content-Type.
  • Access-Control-Max-Age: 86400 indica che il risultato della query può essere memorizzata nella cache per 86.400 secondi.

Browser supportati

Supporto dei browser

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3.5.
  • Safari: 4.

Origine

Scopri di più

Criterio COEP (Cross-Origin Embedder Policy)

Ridurre la capacità delle applicazioni basate su Spectre attacchi a sottrarre risorse multiorigine, funzionalità come SharedArrayBuffer o I performance.measureUserAgentSpecificMemory() sono disattivati 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 altri, a meno che queste risorse non attivino esplicitamente il caricamento tramite CORS. o CORP. COEP può essere combinato conCross-Origin-Opener-Policy per attivare l'isolamento multiorigine di un documento.

Usa Cross-Origin-Embedder-Policy: require-corp quando vuoi attivare isolamento multiorigine per il documento.

Esempio di utilizzo

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

Esempi di utilizzo

COEP accetta un singolo valore di require-corp. Inviando questa intestazione, puoi indica al browser di bloccare il caricamento delle risorse che non vengono attivate tramite CORS o CORP.

Come funziona il COEP

Puoi provare in che modo le seguenti configurazioni influiscono sul caricamento delle risorse su questo una demo. Cambia il Cross-Origin-Embedder-Policy, la sezione Menu a discesa Cross-Origin-Resource-Policy, casella di controllo Cross-Origin-Resource-Policy e così via. per vedere come influiscono sul caricamento delle risorse. Inoltre, apri l'endpoint di reporting per vedere se le risorse bloccate segnalato.

Attiva l'isolamento multiorigine

Attiva 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 non compatibili con COEP

Puoi ricevere segnalazioni relative a risorse bloccate a causa del COEP tramite lo strumento di reporting tramite Google Cloud CLI o tramite l'API Compute Engine.

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

COEP supporta anche la modalità di sola segnalazione per consentirti di ricevere segnalazioni senza effettivamente bloccare il caricamento delle risorse.

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

Browser supportati

Supporto dei browser

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Origine

Scopri di più

HTTP Strict Transport Security (HSTS)

La comunicazione su una connessione HTTP semplice non è crittografata, pertanto dati trasferiti accessibili alle intercettazioni a livello di rete.

L'intestazione Strict-Transport-Security informa il browser che non dovrebbe mai caricarsi il sito tramite HTTP e al suo posto HTTP. Una volta impostato, il browser utilizzerà HTTPS anziché HTTP per accedere al dominio senza reindirizzamento per un determinato periodo di tempo 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 quando viene ricevuta una richiesta con HTTP. 

Strict-Transport-Security: max-age=31536000

Browser supportati

Supporto dei browser

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 7.

Origine

Scopri di più

Per approfondire