Home Blogs Utiliser EdgeJS de Layer0 pour configurer les en-têtes de sécurité personnalisés
Applications

Utiliser EdgeJS de Layer0 pour configurer les en-têtes de sécurité personnalisés

About The Author

Outline

La mise en œuvre d’en-têtes de sécurité est devenue extrêmement importante car le nombre de violations et de vols de données augmente rapidement chaque jour. Les en-têtes de sécurité offrent une partie facile à mettre en œuvre de la solution : il suffit de passer des en-têtes HTTP spécifiques pour protéger votre site Web contre les attaques courantes telles que XSS, injection de code, clickjacking, etc

Que sont les en-têtes de sécurité ?

Les applications Web peuvent envoyer des commandes spéciales au navigateur pour protéger les sites Web contre les violations ou les vulnérabilités côté client, connues sous le nom d’en-têtes de sécurité.

Lorsqu’un utilisateur visite un site Web dans son navigateur, le serveur répond avec des en-têtes de réponse HTTP. Ces en-têtes, composés de métadonnées, partagent des informations avec le client et le serveur. Ces informations partagées définissent la façon dont les navigateurs doivent interagir avec le site Web. Les en-têtes de sécurité offrent une protection puissante contre diverses vulnérabilités et menaces des applications Web.

Ce blog décompose les en-têtes de sécurité importants suivants:

  • Politique de sécurité du contenu (CSP)
  • X-Content-Type-Options
  • Options X-Frame
  • Politique de ressources d’origine croisée (CORP)
  • Politique d’intégration des origines croisées (COEP)
  • Politique d’ouverture d’origine croisée (COOP)
  • Référent-police
  • Permissions-Policy
  • HTTP strict transport Security (HSTS)

Importance des en-têtes de sécurité

Les en-têtes de sécurité HTTP sont un élément fondamental de la sécurité des sites Web ; cependant, seulement 1,6% des premiers un million de sites Web ont mis en œuvre la politique de sécurité du contenu (CSP) et seulement 2% des sites implémentent CSP-Report-Only.

Choquant, non ?! L’absence d’en-tête HTTP CSP supprime les mécanismes de défense contre le Cross-site Scripting (XSS) et d’autres attaques par injection côté client. La violation de données de British Airways est l’un des incidents qui illustre comment, en raison d’un manque de sécurité côté client, les noms, adresses postales, adresses e-mail, numéros de carte de crédit, les dates d’expiration et les codes de sécurité de la carte de 380 000 clients ont été exposés, qui sont restés non détectés pendant 15 jours.

Ajout de sécurité avec EdgeJS de Layer0

Avec la plate-forme de déploiement de Layer0, des éléments tels que TLS sont automatiquement configurés pour chaque lien de déploiement, afin que les développeurs puissent expédier en toute sécurité par défaut. Dans ce blog, nous examinons de près les en-têtes de sécurité importants et un exemple pour montrer à quelle vitesse vous pouvez sécuriser un site Web avec routes config sur Layer0.

Débuter avec les en-têtes de sécurité avec Edgio

Politique de sécurité du contenu (CSP)

Comment CSP empêche le chargement de ressources à partir d’origines non autorisées

Content-Security-Policy fournit une couche supplémentaire pour empêcher les attaques Cross-site Scripting (XSS) en empêchant les scripts, styles, images, polices et médias d’être chargés (et exécutés) à partir d’origines autorisées spécifiques. Quelle que soit la sécurité de votre backend, si de mauvais acteurs peuvent attaquer le code qui s’exécute dans le navigateur plutôt que sur le serveur, les données de session utilisateur sont compromises et les informations confidentielles sont exposées. L’un des nombreux exemples (comme la violation de données de British Airways) est l’attaque MageCart sur le module de paiement de Ticketmaster. La brèche de Ticketmaster a fait 40 000 victimes de vol de carte de crédit et est restée active pendant 5 mois avant d’être prise! Le tout simplement en injectant un script d’écrémage de formulaire à l’intérieur du navigateur.

Const { Router } = require(‘@layer0/core/router’) const ContentSecurityPolicy = `default-src ‘self’ ; script-src .googleapis.com ‘self »unsafe-eval »unsafe-line’ *.layer0.co ; style-src ‘self’ ; img-Connect ‘.gstatic.com New Router() .get(« /:route », ({ setResponseHeader }) => { setResponseHeader(« Content-Security-Policy », ContentSecurityPolicy.replace(/\n/g, «  »)) })

Content-Security-Policy vous permet de :

  1. Surmontez les attaques XSS (Cross site Scripting)
  2. Évitez les déclics
  3. Signalez les violations aux règles du CSP

X-Content-Type-Options

Comment configurer X-Content-Type-Options empêche la détection de type MIME

L’en-tête X-Content-Type-Options indique que les types MIME (Multipurpose Internet Mail Extensions, un identifiant pour les formats de fichier) spécifiés dans les en-têtes Content-Type doivent être strictement suivis. Avec MIME Type Sniffing, des opérations telles que le téléchargement d’images peuvent exécuter des exécutables qui pourraient être malveillants, où l’en-tête X-Content-Type-Options entre en jeu.

Const { Router } = require(‘@layer0/core/router’) New Router() .get(« /:route », ({ setResponseHeader }) => { setResponseHeader(« X-Content-Type-Options », « nosniff ») })

Options X-Frame

En-tête X-Frame-Options

L’en-tête X-Frame-Options indique si un navigateur doit être autorisé à afficher une page dans un cadre, un iframe, un embed ou une balise d’objet à éviter attaques par click-jacking . Que ce soit défini sur REFUSER ou SAMEORIGIN, cela garantit que leur contenu n’est pas intégré dans d’autres sites ou uniquement intégré dans des sites ayant la même origine, respectivement.

Const { Router } = require(‘@layer0/core/router’) New Router() .get(« /:route », ({ setResponseHeader }) => { setResponseHeader(« X-Frame-Options », « SAMEORIGIN ») })

X-Frame-Options vous permet de :

  1. Empêchez les attaques Clickjacking
  2. Indiquer si un navigateur doit être autorisé à afficher une page dans un <cadre>, <iframe>, <incorporer> ou <objet>

Politique de ressources d’origine croisée (CORP)

CORP permet aux serveurs de se protéger contre une certaine intégration inter-origine ou inter-site de la ressource demandée (par exemple, les réponses API). Il empêche également les attaques spéculatives de canal latéral comme spectre.

Const { Router } = require(‘@layer0/core/router’) New Router() .get(« /:route », ({ setResponseHeader }) => { setResponseHeader(« Cross-Origin-Resource-Policy », « same-origin ») })

Cross-Origin Resource Policy est un en-tête de réponse opt-in qui peut protéger n’importe quelle ressource ; il n’est pas nécessaire pour les navigateurs de renifler les types MIME. — MDN Docs

Politique d’intégration des origines croisées (COEP)

L’en-tête COEP empêche le chargement de ressources d’origine croisée pour lesquelles aucune autorisation n’a été accordée (via cors ou CORP). Utilisez « require-corp » pour appliquer l’en-tête, tandis que « Unsafe-none » pour permettre l’extraction de documents d’origine croisée.

Const { Router } = require(‘@layer0/core/router’) New Router() .get(« /:route », ({ setResponseHeader }) => { setResponseHeader(« Cross-Origin-Embedder-Policy », « require-corp ») })

Politique d’ouverture d’origine croisée (COOP)

L’application de l’en-tête COOP garantit que le groupe de contexte de navigation d’un document de niveau supérieur n’est pas partagé entre des documents d’origine croisée. Alors que « same-origin » casse les intégrations qui nécessitent des interactions de fenêtres inter-origines telles que OAuth et Payment, « same-origin-allow-popups » vise à partager le contexte avec uniquement les popups de SAMEORIGIN.

Const { Router } = require(‘@layer0/core/router’) New Router() .get(« /:route », ({ setResponseHeader }) => { setResponseHeader(« Cross-Origin-Opener-Policy », « same-origin-allow-popups ») })

Politique référent

Lorsqu’un utilisateur navigue (en cliquant sur un lien) d’un site (l’origine) à un autre (la destination), ce dernier reçoit des informations sur l’origine de l’utilisateur. L’en-tête Referrer-Policy contrôle la quantité de ces informations disponibles pour la destination. Pour toutes les directives de Referrer-Policy, reportez-vous à Referrer-Policy — HTTP | MDN (mozilla.org).

Const { Router } = require(« @layer0/core/router ») module.exports= New Router() .get(« / », ({ setResponseHeader }) => { setResponseHeader(« Referrer-Policy », « origin-when-cross-origin ») })

Politique d’autorisations

Un en-tête HTTP expérimental qui permet d’autoriser/refuser les fonctionnalités du navigateur dans ses propres cadres et dans n’importe quelle iframe du document. Pour toutes les directives de Referrer-Policy, référez-vous à Feature-Policy — HTTP | MDN (mozilla.org)

Const { Router } = require(« @layer0/core/router ») module.exports= New Router() .get(« / », ({ setResponseHeader }) => { setResponseHeader( « permissions-Policy », « camera=(), microphone=(), géolocalisation=() » ) ; })

HTTP strict transport Security (HSTS)

En-tête HSTS strict transport Security

HTTP strict-transport-Security (HSTS) informe les navigateurs de charger le site Web uniquement en utilisant HTTPS, au lieu d’utiliser le protocole HTTP.

Const { Router } = require(‘@layer0/core/router’) New Router() .get(« /:route », ({ setResponseHeader }) => { setResponseHeader(« strict-transport-Security », « max-age=31536000 ; includeSubDomains ») })

HSTS vous donne la possibilité de:

  1. Protection contre les attaques de rétrogradation HTTP (attaques SSL stripping)
  2. La défense du contenu mixte passe par défaut en HTTPS

Un exemple

Avec Layer0, il est plus facile que jamais d’implémenter des Security Headers. En utilisant EdgeJS de Layer0, vous pouvez ajouter des en-têtes de sécurité à n’importe quel site Web, indépendamment du framework utilisé. Ce qui suit cherche à implémenter les en-têtes de sécurité pertinents dans un site Web construit avec Sapper via Layer0.

Exemple : https://rishi-raj-jain-security-headers-example-default.layer0-limelight.link
GitHub : rishi-raj-jain/Security-headers-example
Rapport : lien de rapport sur les en-têtes de sécurité

Discussion

Allez-y et ajoutez des en-têtes de sécurité pertinents pour sécuriser votre application web! Avec Layer0 vous pouvez faire encore plus que cela, secrets, empoisonnement du cache et activation de l’authentification de base à Edgio Documentation — Security.