Riferimento rapido per le intestazioni di sicurezza

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

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas

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 quando hai bisogno di un promemoria.

Intestazioni di sicurezza consigliate per i siti web che gestiscono dati utente sensibili:
Content Security Policy (CSP)
Trusted Types
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 siti web con funzionalità avanzate:
Condivisione di risorse multiorigine (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 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 injection

Le vulnerabilità di injection si verificano quando i dati non attendibili elaborati dalla tua applicazione possono influire sul suo comportamento e, in genere, portare all'esecuzione di script controllati da utenti malintenzionati. La vulnerabilità più comune causata da 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 può in genere consentire a un malintenzionato di accedere completamente ai dati utente elaborati dall'applicazione e a qualsiasi altra informazione ospitata nella stessa origine web.

Le difese tradizionali contro le injection includono l'uso coerente di sistemi di modelli HTML con escape automatico, l'evitare l'uso di API JavaScript pericolose e l'elaborazione corretta dei dati utente ospitando i caricamenti di file in un dominio separato e la sanitizzazione dell'HTML controllato dall'utente.

  • Utilizza la Content Security Policy (CSP) per controllare quali script possono essere eseguiti dalla tua applicazione per ridurre il rischio di injection.
  • Utilizza i Trusted Types per applicare la sanitizzazione dei dati passati alle 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.

Isola il tuo 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 di un'altra applicazione nel documento dell'utente malintenzionato, consentendogli di modificare o leggere i dati dell'applicazione.

Le vulnerabilità comuni che compromettono l'isolamento web includono il clickjacking, il cross-site request forgery (CSRF), il cross-site script inclusion (XSSI) e vari cross-site leak.

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

Crea un sito web efficace in modo sicuro

Spectre rende potenzialmente leggibili tutti i dati caricati nello stesso gruppo di contesti di navigazione, nonostante la policy della stessa origine. I browser limitano le funzionalità che potrebbero sfruttare la vulnerabilità dietro un ambiente speciale chiamato "isolamento multiorigine". Con l'isolamento multiorigine, puoi utilizzare funzionalità potenti come SharedArrayBuffer.

Cripta il traffico verso il tuo sito

I problemi di crittografia si verificano quando un'applicazione non crittografa completamente i dati in transito, consentendo ad aggressori che intercettano le comunicazioni di conoscere le interazioni dell'utente con l'applicazione.

La crittografia insufficiente può verificarsi nei seguenti casi: mancato utilizzo di HTTPS, contenuti misti, impostazione di cookie senza l'attributo Secure (o il prefisso __Secure) o logica di convalida CORS permissiva.

Policy di sicurezza del contenuto (CSP)

Il cross-site scripting (XSS) è un attacco in cui una vulnerabilità su un sito web consente l'inserimento e l'esecuzione di 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 attivare una CSP rigida utilizzando uno dei seguenti approcci:

  • Se esegui il rendering delle pagine HTML sul server, utilizza una CSP rigida basata su nonce.
  • Se il codice HTML deve essere pubblicato in modo statico o memorizzato nella cache, ad esempio se si tratta di un'applicazione a pagina singola, utilizza una CSP rigida basata su hash.

Esempio di utilizzo: una CSP basata 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 una CSP rigida basata su nonce {: #nonce-based-csp}

Se esegui il rendering delle pagine HTML sul server, utilizza una CSP rigida basata su nonce.

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';

In 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 rigida basata su nonce. Utilizza DevTools per vedere come viene utilizzato.

2. Utilizza una CSP rigida basata 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 una CSP rigida basata 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';

In HTML, dovrai inserire gli script in linea per applicare una policy basata su hash, perché la maggior parte dei browser non supporta l'hashing degli script esterni.

index.html

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

Per caricare script esterni, leggi "Carica script di origine in modo dinamico" nella sezione Opzione B: intestazione della risposta CSP basata su hash.

CSP Evaluator è un ottimo strumento per valutare il tuo CSP, ma anche un buon esempio di CSP rigoroso basato su nonce. Utilizza DevTools per vedere come viene utilizzato.

Browser supportati

Altri aspetti da considerare relativi al CSP

Scopri di più

Trusted Types

L'XSS basato su DOM è un attacco in cui i dati dannosi vengono passati a un sink che supporta l'esecuzione di codice dinamico, come eval() o .innerHTML.

Trusted Types fornisce gli strumenti per scrivere, rivedere la sicurezza e gestire le applicazioni senza XSS basati su DOM. Possono essere attivati tramite CSP e rendono il codice JavaScript sicuro per impostazione predefinita limitando le API web pericolose in modo che accettino solo un oggetto speciale, un tipo attendibile.

Per creare questi oggetti, puoi definire policy di sicurezza in cui puoi assicurarti che le regole di sicurezza (come l'escaping o la sanitizzazione) vengano applicate in modo coerente prima che i dati vengano scritti nel DOM. Queste policy sono quindi gli unici punti del codice che potrebbero potenzialmente 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 Trusted Types per i sink DOM pericolosi Intestazione CSP e Trusted Types: 

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

    Al momento, 'script' è l'unico valore accettabile per l'istruzione require-trusted-types-for.

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

Unione di un CSP basato su nonce con Trusted Types: 

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 Trusted Types consentiti impostando un'ulteriore istruzione <code>trusted-types</code> (ad esempio, <code>trusted-types myPolicy</code>). Tuttavia, non si tratta di un requisito.  </aside>


    
  
  1. 
    
    Definisci una policy
    
    
    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 la policy
    
    
    Utilizza la policy quando scrivi 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 è un requisito. L'utilizzo di un'API DOM pericolosa con una stringa genererà 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 un markup HTML valido), alcuni browser lo considerano un documento attivo e consentono l'esecuzione di script nel contesto dell'applicazione, causando 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 tue risorse.

Esempio di utilizzo

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

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

X-Content-Type-Options: nosniff

Esempio di intestazioni inviate con un documento HTML

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

Browser supportati

Browser Support

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

Source

Scopri di più

X-Frame-Options

Se un sito web dannoso può incorporare il tuo sito come iframe, i malintenzionati potrebbero indurre l'utente a compiere azioni indesiderate tramite clickjacking. Inoltre, in alcuni casi gli attacchi di tipo Spectre offrono ai siti web dannosi la possibilità di scoprire i contenuti di un documento incorporato.

X-Frame-Options indica se un browser deve essere autorizzato o meno a eseguire il rendering di una pagina in un <frame>, <iframe>, <embed> o <object>. È consigliabile che tutti i documenti inviino questa intestazione per indicare se consentono o meno l'incorporamento da parte di 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.

Impedisce che il tuo sito web venga incorporato da altri siti web

Nega l'incorporamento da parte di 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 parte di documenti della stessa origine.

X-Frame-Options: SAMEORIGIN

Browser supportati

Browser Support

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

Source

Scopri di più

Cross-Origin Resource Policy (CORP)

Un malintenzionato può incorporare risorse da un'altra origine, ad esempio dal tuo sito, per ottenere informazioni su di esse sfruttando le fughe di dati cross-site basate sul web.

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: same-origin, same-site e cross-origin. Si consiglia 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 seguenti tre intestazioni.

Consenti il caricamento delle risorse cross-origin

È consigliabile che i servizi simili a CDN applichino cross-origin alle risorse (poiché in genere vengono caricate da pagine multiorigine), a meno che non vengano già pubblicate tramite CORS, che ha un effetto simile.

Cross-Origin-Resource-Policy: cross-origin 
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 alle 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 accedendo all'URL in una nuova finestra del browser. Cross-Origin Resource Policy protegge la risorsa solo dall'incorporamento da parte di altri siti web.

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

Limita le risorse da caricare da same-site

Ti consigliamo di applicare same-site alle risorse simili a quelle sopra indicate, ma destinate a essere caricate da altri sottodomini del tuo sito.

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

Browser supportati

Browser Support

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

Source

Scopri di più

Cross-Origin Opener Policy (COOP)

Il sito web di un malintenzionato può aprire un altro sito in una finestra popup per ottenere informazioni su di esso sfruttando le fughe di dati cross-site 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 un link con target="_blank" senza rel="noopener". Di conseguenza, qualsiasi opener multiorigine del documento non avrà alcun riferimento a quest'ultimo e non potrà interagirvi.

Esempio di utilizzo

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

Isola un documento dalle finestre multiorigine

L'impostazione same-origin fa sì che il documento venga isolato dalle finestre dei documenti multiorigine.

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

Isola un documento dalle finestre multiorigine, ma consenti i popup

L'impostazione same-origin-allow-popups consente a un documento di conservare un riferimento alle sue 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 impedire che il documento venga referenziato quando viene aperto come finestra popup, ma consente di comunicare con i propri popup.

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

Consenti il riferimento a un documento da parte di 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 
Cross-Origin-Opener-Policy: unsafe-none

Pattern di report non compatibili con COOP

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

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

COOP supporta anche una modalità di sola generazione di report, in modo da poter ricevere report senza bloccare effettivamente la comunicazione tra documenti multiorigine.

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

Browser supportati

Browser Support

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

Source

Scopri di più

Condivisione di risorse multiorigine (CORS)

A differenza di altri elementi di questo articolo, la condivisione delle risorse tra origini (CORS) non è un'intestazione, ma un meccanismo del 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 a risorse multiorigine. Ad esempio, quando viene caricata un'immagine multiorigine, anche se viene visualizzata visivamente sulla pagina web, il codice JavaScript della pagina non ha accesso ai dati dell'immagine. Il provider di risorse può allentare le limitazioni e consentire ad altri siti web di leggere la risorsa attivando CORS.

Esempio di utilizzo

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

Prima di esaminare come configurare CORS, è utile comprendere la distinzione tra i tipi di richiesta. A seconda dei dettagli della richiesta, questa 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 maggiori dettagli, consulta Condivisione delle risorse multiorigine (CORS) - HTTP | MDN.

Richiesta semplice

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

Intestazione della richiesta di esempio

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

Esempio di intestazione 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 destinate a essere leggibili da qualsiasi sito possono impostare questa intestazione su *. In questo 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) possono caricare la risorsa. In caso contrario, le richieste autenticate verranno rifiutate anche se l'origine della richiesta è presente nell'intestazione Access-Control-Allow-Origin.

Richieste preflight

Una richiesta preflight è preceduta da una richiesta OPTIONS per verificare se la richiesta successiva può essere inviata.

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 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.

Esempi di intestazioni della 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 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

Browser Support

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

Source

Scopri di più

Cross-Origin Embedder Policy (COEP)

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

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

Utilizza Cross-Origin-Embedder-Policy: require-corp quando vuoi attivare l'isolamento multiorigine per il tuo 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 indicare al browser di bloccare il caricamento delle risorse che non vengono attivate tramite CORS o CORP.

Come funziona COEP

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

Risorse del report incompatibili con COEP

Puoi ricevere report sulle risorse bloccate causate da COEP con l'API Reporting.

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

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

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

Browser supportati

Browser Support

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

Source

Scopri di più

HTTP Strict Transport Security (HSTS)

La comunicazione tramite una connessione HTTP semplice non è crittografata, il che rende i dati trasferiti accessibili a intercettatori a livello di rete.

L'intestazione Strict-Transport-Security indica al browser che non deve mai caricare il sito utilizzando HTTP, ma deve utilizzare HTTPS. Una volta impostata, il browser utilizzerà HTTPS anziché 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 quando viene ricevuta una richiesta con HTTP. 

Strict-Transport-Security: max-age=31536000

Browser supportati

Browser Support

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

Source

Scopri di più

Per approfondire

Indietro
Informazioni su "same-site" e "same-origin"