Scopri di più sulle intestazioni che possono proteggere il tuo sito e cercare rapidamente i dettagli più importanti.
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)
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.
- Utilizza X-Frame-Options per impedire che i documenti vengano incorporati in un sito web dannoso.
- Utilizza Cross-Origin Resource Policy (CORP) per impedire che le risorse del tuo sito web vengano incluse da un sito web multiorigine.
- Utilizza Cross-Origin Opener Policy (COOP) per proteggere le finestre del tuo sito web dalle interazioni di siti web dannosi.
- Utilizza la condivisione delle risorse tra origini (CORS) per controllare l'accesso alle risorse del tuo sito web dai documenti multiorigine.
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
.
- Utilizza il criterio COEP (Cross-Origin Embedder Policy) insieme a COOP per attivare l'isolamento multiorigine.
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.
- Utilizza HTTP Strict Transport Security (HSTS) per pubblicare i tuoi contenuti in modo coerente tramite HTTPS.
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';
Utilizzi consigliati
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
frame-ancestors
protegge il sito dal clickjacking, un rischio che si verifica se consenti ai siti non attendibili di incorporare i tuoi. Se preferisci una soluzione più semplice, puoi utilizzareX-Frame-Options
per bloccare il caricamento, maframe-ancestors
ti offre una configurazione avanzata per consentire solo origini specifiche come incorporatori.- Probabilmente hai utilizzato un CSP per garantire che tutte le risorse del tuo sito vengano caricate tramite HTTPS. Questo è diventato meno pertinente: oggi, la maggior parte dei browser blocca i contenuti misti.
- Puoi anche impostare un CSP in modalità di solo report.
- Se non riesci a impostare un CSP come intestazione lato server, puoi impostarlo anche come meta tag. Tieni presente che non puoi utilizzare la modalità solo report per i meta tag (anche se questa impostazione potrebbe cambiare).
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, '<').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 TrustedType:
Content-Security-Policy: require-trusted-types-for 'script'
Attualmente
'script'
è l'unico valore accettabile per l'istruzionerequire-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 '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 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>
-
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 di 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'
, è obbligatorio utilizzare un tipo attendibile. L'utilizzo di un'API DOM pericolosa con una stringa comporterà un errore.
Browser supportati
Scopri di più
- Previeni le vulnerabilità di cross-site scripting (XSS) basate su DOM con i tipi attendibili
- CSP: request-Trusted-types-for - HTTP | MDN
- CSP: trusted-types - HTTP |
MDN
- Demo di TrustedType: apri DevTools Inspector e guarda cosa sta succedendo
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
Utilizzi consigliati
La funzionalità X-Content-Type-Options: nosniff
è consigliata per tutte le risorse pubblicate dal tuo server insieme all'intestazione Content-Type
corretta.
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
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
Utilizzi consigliati
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
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
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
Utilizzi consigliati
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.
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.
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.
Cross-Origin-Resource-Policy: same-site
Browser supportati
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
Utilizzi consigliati
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.
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.
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.
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
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
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
oPOST
. - Le intestazioni personalizzate includono solo
Accept
,Accept-Language
,Content-Language
eContent-Type
. 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 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 chehttps://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'intestazioneAccess-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 metodoPOST
.Access-Control-Request-Headers: X-PINGOTHER, Content-Type
consente al richiedente di impostare le intestazioni HTTPX-PINGOTHER
eContent-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 metodiPOST
,GET
eOPTIONS
.Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
indica che le richieste successive possono includere le intestazioniX-PINGOTHER
eContent-Type
.Access-Control-Max-Age: 86400
indica che il risultato della richiesta preflight può essere memorizzato nella cache per 86.400 secondi.
Browser supportati
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
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.
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
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
Utilizzi consigliati
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