Scopri di più sulle intestazioni che possono mantenere sicuro il tuo sito e cercare rapidamente i dettagli più importanti.
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
- Opzioni X-Frame
- 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)
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.
- Usa X-Frame-Options per impedire che i documenti vengano incorporati da un sito web dannoso.
- Utilizza i criteri delle risorse multiorigine (CORP) per impedire che il tuo sito web affinché possano essere incluse da un sito web multiorigine.
- Utilizza il Criterio di apertura multiorigine (COOP) per proteggere il tuo sito web dalle interazioni di siti web dannosi.
- Utilizza la condivisione delle risorse tra origini (CORS) per controllare l'accesso ai tuoi da documenti multiorigine.
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
.
- Utilizza il Criterio per l'incorporamento multiorigine (COEP) insieme a COOP per per abilitare l'isolamento multiorigine.
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.
- Utilizza HTTP Strict Transport Security (HSTS) per gestire in modo coerente i tuoi tramite HTTPS.
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';
Utilizzi consigliati
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
frame-ancestors
protegge il tuo sito dal clickjacking, un rischio che si presenta se consenti siti non attendibili nei quali incorporare il tuo. Se preferisci una soluzione più semplice, puoi utilizzareX-Frame-Options
per bloccare il caricamento, maframe-ancestors
restituisce una configurazione avanzata per consentire solo origini specifiche come incorporatori.- Forse hai utilizzato un CSP per fare in modo che tutte le risorse del tuo sito siano vengono caricati tramite HTTPS. Questo ha diventano meno pertinenti: oggi la maggior parte dei browser contenuti-misti.
- Puoi anche impostare un CSP in modalità solo report .
- Se non riesci a impostare un CSP come intestazione lato server, puoi anche impostarlo come meta del tag. Tieni presente che non puoi utilizzare la modalità solo report per i meta tag (anche se questo potrebbe cambiare).
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, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
Utilizzi consigliati
-
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 perrequire-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 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<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>
-
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, '>');
}
});
}
-
Applica il criterio
Utilizza il criterio durante la scrittura dei dati nel DOM:
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
Con require-trusted-types-for 'script'
, l'utilizzo di un tipo attendibile è
requisito. L'utilizzo di API DOM pericolose con una stringa comporterà un
.
Browser supportati
Scopri di più
- Previeni le vulnerabilità di cross-site scripting basate su DOM con Trusted
Tipi
- CSP: request-trusted-types-for - HTTP |
MDN
- CSP: tipi attendibili - HTTP |
MDN
- Demo Tipi di attendibilità: apri DevTools Inspector e verifica
che cosa succede
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
Utilizzi consigliati
X-Content-Type-Options: nosniff
è consigliato per tutte le risorse fornite da
server insieme all'intestazione Content-Type
corretta.
![X-Content-Type-Options: nosniff](https://web.developers.google.cn/static/articles/security-headers/image/x-content-type-options-n-7088b3ce0282f.png?authuser=5&hl=it)
Intestazioni di esempio inviate con un documento HTML
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
Browser supportati
Scopri di più
Opzioni X-Frame
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 danno 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
Utilizzi consigliati
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](https://web.developers.google.cn/static/articles/security-headers/image/x-frame-options-deny-0729b63f3a2e.png?authuser=5&hl=it)
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
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
Utilizzi consigliati
È 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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-365b98767bed6.png?authuser=5&hl=it)
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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-27b9213f10fd2.png?authuser=5&hl=it)
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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-158905cfe6687.png?authuser=5&hl=it)
Cross-Origin-Resource-Policy: same-site
Browser supportati
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
Utilizzi consigliati
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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-2d273fc0106eb.png?authuser=5&hl=it)
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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-7311769f30905.png?authuser=5&hl=it)
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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-6542ad44c7cdc.png?authuser=5&hl=it)
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
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
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
oPOST
. - Le intestazioni personalizzate includono solo
Accept
,Accept-Language
,Content-Language
eContent-Type
. - Il valore
Content-Type
èapplication/x-www-form-urlencoded
,multipart/form-data
otext/plain
.
Tutto il resto è classificato come richiesta preflight. Per ulteriori dettagli, consulta Condivisione delle risorse tra origini (CORS) - HTTP | MDN.
Utilizzi consigliati
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 chehttps://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'intestazioneAccess-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 metodoPOST
.Access-Control-Request-Headers: X-PINGOTHER, Content-Type
consente di impostare le intestazioni HTTPX-PINGOTHER
eContent-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 metodiPOST
,GET
eOPTIONS
.Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
indica le successive possono includere le intestazioniX-PINGOTHER
eContent-Type
.Access-Control-Max-Age: 86400
indica che il risultato della query può essere memorizzata nella cache per 86.400 secondi.
Browser supportati
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
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](https://web.developers.google.cn/static/articles/security-headers/image/how-coep-works-28c183abab5d5.png?authuser=5&hl=it)
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
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
Utilizzi consigliati
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