Securité

Entête HTTP

Entête HTTP : Politique de sécurité du contenu (CSP)

On protège généralement le serveur, contre les attaques de scripts (cross-site scripting (XSS)) et les injections SQL, directement dans le code de chaque page. Du cas par cas à chaque requête, la première ligne de défense comme dit Wikipédia. Essentiellement la validation de formulaires. En comparant chaque chaine de requête (querystring) avec des mots-clés et des signatures, à l’instar des antivirus... C’est efficace, dans la mesure où dans mon cas j’ai la déformation professionnelle nécessaire! Mais c’est comme étouper une passoire, il suffit d’une faille, d’une oublie ou même d’une nouvelle souche pour faire voler en éclats les mesures de sécurité. Sans parler du gestionnaire de serveur Web qui n’a aucun contrôle sur les scripts publiés sous un domaine, laissant le serveur extrêmement vulnérable.

La politique de sécurité du contenu, en anglais « Content Security Policy (CSP) », est un mécanisme d’applications Web implanté en amont de la requête HTTP, qui permet de limiter l’interprétation de script et de cadre imbriqué (iframe) directement dans le navigateur client. Une défense en profondeur qui consiste en une simple politique déclarative du serveur, via l’entête HTTP, pour indiquer au navigateur les sources à partir de laquelle l’application prévoit charger les ressources.

Mais attention bien que le CSP soit très efficace, en permettant d’améliorer votre sécurité, c’est à la merci du navigateur. Étant donné que seule la version « Edge » des navigateurs Internet Explorer est compatible, la question ne se pose même pas.

Liste blanche

Une application web peut déclarer qu’elle ne prévoit charger les scripts de confiance qu’à partir de sources ou de domaines spécifiques, à la manière de la liste blanche du serveur de courriel. Cette déclaration permet au client de détecter et de bloquer les scripts malveillants injectés dans l’application. Ce qui est bien avec cette méthode, contrairement au serveur de courriel, c’est qu’un site web peut utiliser exclusivement des ressources locales, contrairement aux courriels... C’est dire qu’on peut protéger son serveur des attaques avec une bonne politique de sécurité du contenu et surtout, une solide éthique de programmation.

Essentiellement :

1. En évitant les scripts et styles directement dans le code, dit « en ligne ». Parce que le butineur ne peut pas déterminer si un script « en ligne » a été injecté par un attaquant ;

2. Particulièrement l’évaluation de chaine avec eval(). Même si on peut l’éviter avec unsafe-eval, et même si la plupart des attaques XSS ne l’utilisent pas contrairement aux injections SQL. L’eval() reste toujours une faille potentielle. Mais attention, plusieurs scripts ne fonctionnent plus à cause de cette pratique qui n’est pas conseillée, même local ;

3. En transférant les scripts, styles et images externes localement sur le serveur ;

4. Et enfin en ajoutant dans l’entête HTTP une bonne politique de sécurité du contenu en spécifiant les exceptions pour les scripts externes autorisés, comme Google API comme jQuery, Analytic, Font, Ad Sens etc. On comprend pourquoi Google n’est pas derrière la Politique de sécurité du contenu ;-p ;

5. En évitant les iFrames.

Vous l’aurez compris, c’est assez simple, particulièrement pour un site d’auteur qui n’utilise pas ou peu de ressources externes d’autant que l’entête HTTP est une simple chaine de caractère. Mais ça peut devenir plus complexe dans un environnement qui utilise plusieurs domaines, un clusteur ou ces gabarits fort répandus avec des dizaines de ressources externes. Par exemple le script pour la compatibilité des images BPG de Fabrice Bellard utilise l’eval() et ne fonctionne donc pas sans une exception. Ou encore c’est toute une affaire juste pour autoriser les services de Google.

// Exemple HTTP : l’exécution de script est autorisée
// pour le domaine local et pour le domaine (et protocole) https://apis.google.com.
Content-Security-Policy: script-src 'self' https://apis.google.com

script-src est la directive pour le contrôle de privilèges liés à un script pour une page Web donnée. 'self' spécifie une source valide de script, en l’occurrence la source locale. Et une seconde, spécifiée par un nom de domaine en particulier « https://apis.google.com » et le protocole « HTTPS ». Le navigateur téléchargera et interprètera seulement le JavaScript en provenance de apis.google.com via le protocole HTTPS. Ainsi que les ressources de la même origine que la page en cours ('self'). « apis.google.com » autorise les deux protocoles en même temps. Noter que apis.google.com et google.com représentent deux sources différentes, il faut dans ce cas spécifier les deux.

Avec cette politique définie via l’entête HTTP, le navigateur va simplement lancer une erreur au lieu de charger le script à partir d’une autre source. Si un attaquant parvient à injecter du code dans votre site, c’est plutôt sur ce message d’erreur que se terminera la transaction :

Bar OPEN

Bon par défaut, c’est « bar open », le chargement et l’interprétation de tout type de ressources peut importe la source est autorisé. Si vous ne définissez pas une politique spécifique pour une directive, le navigateur se comportera comme si TOUT (*) était une source valide. C’est pas pour rien que le test de SecurityHeaders.io retourne la note « F » par défaut. Car, c’est « bar open » ! Le chargement et l’interprétation de tout type de ressources, peut importe la source, est autorisé. Vous pouvez remplacer ce comportement par défaut en spécifiant une directive default-src. Cette directive définit les valeurs par défaut pour la plupart des directives laissées sans précision.

En général, cela s’applique à toute directive qui se termine par -src (c’est-à-dire à part les directives : base-uri,form-action, frame-ancestors, plugin-types, report-uri, sandbox). Si default-src autorise https://example.com mais qu’aucun font-src n’est spécifié, vous devrez charger les polices uniquement à partir de https://example.com et nulle part ailleurs. En précisant uniquement la directive script-src, les images, les polices, et les ressources autre qu’un script, pourront être chargées à partir de toute origine.

Bien que les ressources de script soient beaucoup plus à risquent au niveau de la sécurité, le CSP fournit un ensemble de politique sous forme de directives qui permettent un contrôle assez pointu des ressources qu’une page est autorisée à charger :

base-uri

limite les URL qui peuvent apparaître dans l’élément HTML <base> d’une page.

child-src

limite les URL pour le contenu des cadres intégrés (iframe). Par exemple : le child-src https://youtube.com permettrait d’intégrer les vidéos de YouTube, mais pas d’autres origines. Utilisez-le à la place de la directive frame-src dépréciée.

connect-src

limite les origines à laquelle vous pouvez vous connecter (via XHR, WebSockets et EventSource).

font-src

spécifie les origines qui peuvent servir de polices Web. Web Fonts de Google pourraient être activés par la font-src https://fonts.googleapis.com/

form-action

liste les paramètres valides pour la soumission de balises <form>

frame-ancestors

spécifie les sources qui peuvent incorporer la page en cours. Cette directive s’applique à <frame>, <iframe>, <embed> et <applet>. Cette directive ne peut pas être utilisé dans les balises <meta> et s’applique uniquement aux ressources non-HTML.

frame-src

Déprécié Utilisez plutôt child-src.

img-src

liste les ressources à partir desquelles les images peuvent être chargées.

media-src

limite les origines autorisées à diffuser de la vidéo et de l’audio.

object-src

limite les origines autorisées à diffuser du flash et autres plugiciels.

plugin-types

limite les types de plugiciels qu’une page peut charger.

report-uri

spécifie un URL où un navigateur envoie des rapports quand une politique de sécurité de contenu est violé. Cette directive ne peut pas être utilisé dans les balises <meta>.

script-src

liste les ressources à partir desquelles les feuilles de styles CSS peuvent être chargées.

style-src

liste les ressources à partir desquelles les script JavaScript CSS peuvent être chargés.

upgrade-insecure-requests

Directive des navigateurs pour réécrire les schémas d’URL, pour par exemple changer le protocole de HTTP vers HTTPS, pour les sites Web avec un grand nombre d’anciennes URL qui doivent être réécrites.

Il suffit de spécifier la directive et la source autorisé. On peut ajouter le nombre de directives qu’on veut en les séparent par un point virgule.

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Il y a quatre mnémoniques acceptées comme source :

'none'

ne correspond à rien ;

'self'

correspond à l’origine de la page en cours, mais pas ses sous-domaines (www.exemple.com mais pas exemple.com) ;

'unsafe-inline'

permet le JavaScript et CSS « en ligne » (inline) ;

'unsafe-eval'

permet l’évaluation de chaine de caractère (eval).

Exemples simples

# Bloc tout.
default-src ’none’;

# Accepte la CSS local (domaine de la page en cour).
style-src ’self’;

# Accepte le JavaScript local (domaine de la page en cour).
script-src ’self’;

# Autorise les connexion XHR de Google Maps APIs via HTTPS.
connect-src https://maps.googleapis.com; 

# Autorise les images de Google Maps via HTTPS.
img-src https://maps.google.com;

Le dangereux code en ligne (inline)

JavaScript

Le CSP s’appuie comme on le sais sur une « liste blanche », c’est une façon non ambiguë d’instruire le navigateur pour traiter des ensembles spécifiques de ressources comme acceptable et de rejeter le reste. Cette façon de faire ne résout cependant pas la plus grande menace, celle des attaques XSS (injection de script en ligne). Si un attaquant peut injecter du JavaScrip malveillant (<scrip> verslenfer.com(); </ script>), le navigateur n’a pas de mécanisme permettant de le distinguer le code en ligne légitime du code malveillant. D’ailleurs le test SecurityHeaders.io retourne un A+ même en autorisant le JavaScript en ligne ! Le CSP résout toutefois ce problème en interdisant carrément les scripts en ligne (inline) : c’est le seuile moyen absolument sûr.

Cette interdiction affecte non seulement les scripts intégrés directement dans les balises de script, mais aussi les gestionnaires d’évènements (event handlers) en ligne et le JavaScript dans un hyperlien. Vous aurez besoin de déplacer le contenu des balises de script dans un fichier externe, et remplacer le JavaScript dans les hyperliens <a ... onclick="[JAVASCRIPT]"> par des appels externes à l’aide de la méthode « addEventListener » appropriée. Par exemple, vous devrez réécrire le JavaScript suivant :

<script>
  function maFonction() {
    alert('Ahurissant');
  }
</script>
<button onclick='maFonction();'>Ahurissant?</button>

// Par quelque chose comme :

<!-- page.html -->
<script src='maFonction.js'></script>
<button id='oAhurissant'>Ahurissant?</button>

// maFonction.js
function maFonction() {
  alert('Ahurissant!');
}
document.addEventListener('DOMContentReady', function () {
  document.getElementById('oAhurissant')
          .addEventListener('click', maFonction);
});

Le nouveau code n’a rien d’exceptionnel, c’est déjà programmer de façon éthique. Et on devrait toujours programmer de cette façon. C’est ici qu’on peut s’arracher les cheveux à convertir les pages Web d’un site Web existant, ou d’un gabarit à bas prix (template). Sinon, c’est une maudite bonne habitude à prendre si vous ne l’aviez pas déjà prise. Car un JavaScript « en ligne » (Inline) ne devrait jamais être utilisé. Les ressources extérieures sont plus faciles à gérer par les techniques de mise en cache, plus compréhensible pour les développeurs et propice à la compilation et à la minification.

Feuille de styles (CSS)

Le style (CSS) « en ligne » (Inline) est traité de la même manière. À la fois l’attribut de style et les balises de style devraient être regroupés en feuilles de style externes pour se protéger contre une variété de méthodes étonnamment habiles d’exfiltration de données permises par le CSS. J’avoue que je ne sais absolument pas de quoi il est question. Il faudrait examiner un peu tout ça, mais je le crois sur parole et c’est une autre bonne habitude à prendre.

'unsafe-inline'

Si vous devez absolument utiliser des scripts et des styles en ligne, vous pouvez l’activer en ajoutant 'unsafe-inline' comme une source autorisée dans une directive script-src ou style-src. Vous pouvez également utiliser la mnémonique nonce ou un hachage sha256 (hash). Mais de grâce, éviter cette pratique à tout prix. Bannir les scripts « en ligne » est le plus important gain de sécurité du CSP, et l’interdiction de style en ligne endurcira également votre application. C’est une tâche ardue que de déplacer son code dans un fichier externe et de se plier à ces directives, mais c’est un compromis qui en vaut certainement la peine.

Si vous devez absolument utiliser...

Content-Security-Policy: script-src 'unsafe-inline';

Le CSP niveau 2 offre aussi une compatibilité pour les scripts en ligne en permettant une liste blanche de script en ligne spécifique à l’aide soit de nonce cryptographique (numéro utilisé une fois) ou un hachage (encodage sha256). Bien que cela puisse être lourd dans la pratique, ça peut donner un bon coup de pouce.

Pour utiliser nonce, donnez à votre balise de script un attribut nonce. Sa valeur doit correspondre à l’une des valeurs spécifiées dans la liste des sources de confiance. Par exemple :

<script nonce=EBFneeIOfn23fn3e983s55Af>
  // Code en ligne pour gagner du temps, ça dépanne toujours.
</script>

Maintenant, ajoutez nonce à votre directive script-src :

Content-Security-Policy: script-src 'nonce-EBFneeIOfn23fn3e983s55Af' 

Rappelez-vous qu’une chaine « nonces » doit être régénérée pour chaque demande de page et ils doivent être impossible à deviner...

Le hachage fonctionne à peu près de la même façon. Au lieu d’ajouter du code à la balise de script, créer un hachage SHA du script lui-même et ajoutez-le à la directive script-src. Par exemple, disons que votre page contient ceci :

<script>alert('Hello, world.');</script>

Votre politique devrait contenir :

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';

Il y a quelques détails à noter ici. Le préfixe sha*- spécifie l’algorithme utilisé pour générer le hachage. Dans l’exemple ci-dessus, sha256- est utilisé, mais le CSP supporte également le hachage sha384- et sha512-. Lors de la génération du hachage, n’encodez pas les balises <script>. Et attention avec les espaces et la case des caractères (majuscule/minuscule).

L’évaluation de chaine de caractères avec eval()

Même si une attaque ne peut injecter du script, elle pourrait être en mesure de tromper votre application dans la conversion du texte normalement inerte dans exécutable JavaScript et l’exécuter en son nom. eval(), une nouvelle Function(), setTimeout([chaine], ...), et setInterval([chaine], ...) sont tous des vecteurs à travers lesquels l’injection de texte pourrait finir par exécuter quelque chose d’inattendu et de malveillant. La réponse par défaut de CSP par rapport à ce risque est, sans surprise, est de bloquer complètement tous ces vecteurs.

Cela a plus d’un impact sur la façon de créer des applications :

Traitez le JSON via la méthode native JSON.parse, plutôt que de compter sur l’évaluation de chaine avec eval(). Les opérations natives du JSON sont disponibles dans tous les navigateurs depuis IE8 et ils sont totalement sécuritaires.

Réécrire tous les appelle setTimeout ou setInterval que vous avez programmé avec une évaluation de chaine de caractère par une « fonction en ligne ». Par exemple :

setTimeout("document.querySelector('a').style.display = 'none';", 10);

// Devrait codé ainsi :

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

Évitez les gabarits en ligne (templating inline) à l’exécution : de nombreuses librairies utilisent trop facilement new Function() pour accélérer la génération de modèle lors de l’exécution. C’est peut-être une utilisation astucieuse de la programmation dynamique, mais au risque d’évaluer des chaines malveillantes. Certains cadriciels supportent le CSP , la directive ng-csp de AngularJS est un bon exemple.

Encore mieux, si votre langage offre la précompilation (Handlebars le fait par exemple), précompilation vos modèles peut rendre l’expérience encore plus rapide que la plus rapide des mises en œuvre de modèle exécuté en ligne tout en étant plus sûr. Si l’évaluation (eval) est tout à fait indispensable à votre application, vous pouvez les activer en ajoutant 'unsafe-eval' comme source autorisée dans une directive script-src. Mais c’est tout à fait déconseillé encore une fois. Avec l’interdit d’exécuter des chaines évaluées, il est beaucoup plus difficile pour un attaquant d’exécuter du code non autorisé sur votre site.

Content-Security-Policy: script-src 'unsafe-eval';

Exemple avec autorisation de script « en ligne » et eval()

// Exemple pour autoriser l’interprétation des scripts locaux,  
// Plus l’autorisation de script « en ligne » avec 'unsafe-inline'
// Et l’autorisation de l’évaluation de chaine de caractère avec 'unsafe-eval'
// PAS DU TOUT SÉCURITAIRE
Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval';

// Exemple des Trucsweb.com
// Avec autorisation de la publicité Google
Content-Security-Policy: default-src trucsweb.com www.trucsweb.com; script-src 'self' googleads.g.doubleclick.net;

Journal des violations CSP avec report-uri

« rapport-uri » permets de compiler les violations de votre politique de sécurité du contenu dans un fichier journal. Il suffit de spécifier une adresse (URL) avec la directive et le navigateur se chargera d’envoyer une requête HTTP à cette adresse à chaque violation. Cette directive fait une demande HTTP avec la méthode POST et une chaine JSON qui contient tous les détails de la violation. Récupérer cette chaine pour la sauvegarder dans un « fichier log » sur le serveur à l’aide de votre langage serveur préféré.

Exemple d’entête :

Content-Security-Policy: default-src 'self'; report-uri: https://example.com/csp/journaux;

Chaque tentative d’ouvrir une autre source non autorisée provoquera la soumission de la chaine JSON via une requête HTTP POST à notre rapport-uri. Comme l’exemple suivant avec un script de Google Analytic bloqué.

{
    "csp-report": {
        "blocked-uri:" "http://ajax.googleapis.com"
        "document-uri:" "http://example.com/index.html"
        "original-policy": "default-src 'self'; report-uri https://example.com/csp/journaux"
        "referrer:" ""
        "violated-directive": "default-src 'self'"
    }
}

Content-Security-Policy-Report-Only

Si vous envisagez de mettre en œuvre une Politique de sécurité du contenu, testez-le en utilisant l’entête HTTP « Content-Security-Policy-Report-Only », au lieu de « Content-Security-Policy ». Elle fonctionne exactement de la même façon que l’entête de CSP, mais en signalant les violations sans appliquer effectivement la politique en bloquant des ressources restreintes. Vous pouvez même utiliser les deux entêtes en même temps, l’application d’une politique tout en surveillant l’effet que des changements pourraient avoir dans l’autre.

<div class="alert alert-success" id="jsNode"><h5><span class="glyphicon glyphicon-ok"></span> Script « en ligne » bloqué</h5> Si vous pouvez lire ce texte, votre navigateur est compatible avec le CSP et bloque l’interprétation des scripts « en ligne » avec une directive.</div>

<script>
  window.onload=function(){
    var jsNode = document.getElementById("jsNode");
    jsNode.innerHTML = "<h5><span class=\"glyphicon glyphicon-exclamation-sign\"></span> Script « en ligne » bloqué</h5> Votre navigateur est incompatible avec le CSP ou aucune directive n’empêche d’interpréter ce script « en ligne » qui remplace le contenu du DIV.";
    jsNode.className = "alert alert-danger";
  };
</script>

Implentation

// HTML - Exemple avec une métadonnée « http-equiv »
// Qui n’autorise pas le iFrame ni l’objet.
<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">

// Exemple avec autorisation Bootstrap, Fontawesome, Google Font, analytics, Google Ajax et jQuery.
<meta http-equiv="Content-Security-Policy" content="default-src https:; font-src https://fonts.gstatic.com https://use.fontawesome.com https://cdn.jsdelivr.net; img-src 'self'; object-src 'none'; script-src 'self' https://cdn.jsdelivr.net/ https://code.jquery.com https://ajax.googleapis.com; style-src 'self' https://cdn.jsdelivr.net https://use.fontawesome.com;" />



  
  


# Apache config
Header set Content-Security-Policy "default-src 'self';"

# PHP example
header("Content-Security-Policy: default-src 'self'");

# Node.js example
request.setHeader("Content-Security-Policy", "default-src 'self'");

// ASP.NET
public class ContentSecurityPolicyFilterAttribute : ActionFilterAttribute {
  public override void OnActionExecuting( ActionExecutingContext filterContext) {
    var response = filterContext.HttpContext.Response;
    response.AddHeader("Content-Security-Policy" , 
         "default-src https:; 
          script-src 'self' https://code.jquery.com https://ajax.aspnetcdn.com; 
          style-src 'self' https://ajax.aspnetcdn.com");
    base.OnActionExecuting(filterContext);
  }
}

// Web.config / IIS
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <!-- Nouvelles directives CSP pour la protection contre les attaques de type « Injections XSS » (réf. : http://content-security-policy.com/) -->
        <add name="Content-Security-Policy" value="default-src https:; font-src https://fonts.gstatic.com https://use.fontawesome.com https://cdn.jsdelivr.net; img-src 'self' object-src 'none'; script-src 'self' https://cdn.jsdelivr.net/ https://code.jquery.com https://ajax.googleapis.com; style-src 'self' https://cdn.jsdelivr.net https://use.fontawesome.com;" />
        <remove name="X-Content-Type-Options"/>
        <!-- Protection contre les attaques de type « MIME-type confusion » (ref.: https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/) -->
        <add name="X-Content-Type-Options" value="nosniff"/>
        <!-- Protection contre les attaques de type « Clickjacking » (réf. : https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet) -->
        <remove name="Strict-Transport-Security" />
        <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
        <!-- Protection contre les attaques de type « Clickjacking » (réf. : http://stackoverflow.com/a/22105445/1233379) -->
        <add name="X-Frame-Options" value="SAMEORIGIN" />
        <!-- Protection contre les attaques de type « Injections XSS » (réf. : https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers/) -->
        <add name="X-XSS-Protection" value="1; mode=block" />
        <!-- Empêche les fuites de données de référence sur des connexions non sécurisées (réf. : https://scotthelme.co.uk/a-new-security-header-referrer-policy/) -->
        <add name="Referrer-Policy" value="strict-origin" />  
        <add name="Set-Cookie" value="Max-Age=0; Secure; HttpOnly" />
        <!-- « Feature-Policy » REMPLACÉ PAR « Permissions-Policy » -->
        <add name="Feature-Policy" value="vibrate 'self'; usermedia *; sync-xhr 'self'" />
        <add name="Permissions-Policy" value="geolocation=(self), microphone=()" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>


# nginx conf file
add_header Content-Security-Policy "default-src 'self';";

Exemple avec médias sociaux, Google et autorisations de scripts en ligne et eval() JavaScript, CSS « en ligne ».

default-src *; script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* ’unsafe-inline’ ’unsafe-eval’ https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com; style-src * ’unsafe-inline’; connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:* ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://attachment.fbsbx.com https://attachment.fbsbx.com;

Via le gestionnaire IIS

Utiliser le gestionnaire IIS pour ajouter vos entête HTTP et vos directives de « Politique de sécurité du contenu (CSP) ».

1. Ouvrez le gestionnaire des services Internet (IIS) ;
2. Sélectionnez votre site ;
3. Dans l’onglet IIS, cliquer « En-tête de réponse HTTP » ;
4. Ajoutez vos entête HTTP.

Ressources

• Content Security Policy Reference
• Securityheaders.io : Scan your site now
• HTTP Header Check Analyze HTTP Response Headers
• W3C - Content Security Policy Level 2
• An Introduction to Content Security Policy par Mike West (2012)
• W3C - 14 Header Field Definitions (HTTP/1.1)
• Chrome - Content Security Policy (CSP)
• Microsoft - Reducing MIME type security risks
• Keycdn - Hardening Your HTTP Security Headers
• OWASP Secure Headers Project
• hsecscan - A security scanner for HTTP response headers (Python 2.x)
• MDN - CSP Policy Directives
• XSS Filter Evasion Cheat Sheet