Bonnes pratiques de sécurité Angular

Nous avons déjà partagé notre fiche mémo sur les fondamentaux de la sécurité AngularJS. Cette fois, nous entrons directement dans le vif du sujet avec les bonnes pratiques de sécurité pour Angular moderne. Vous pouvez télécharger ici la fiche des bonnes pratiques de sécurité Angular.

6 bonnes pratiques de sécurité Angular

1. La « méthode Angular » vous protège contre les attaques XSS

2. Utilisez innerHTML avec prudence

3. N’utilisez jamais de modèles générés en concaténant des entrées utilisateur

4. N’utilisez jamais les API natives du DOM pour interagir avec les éléments HTML

5. Évitez les moteurs de template dans les templates côté serveur

6. Analysez votre projet Angular pour détecter les composants qui introduisent des failles de sécurité

1. La « méthode Angular » vous protège contre les attaques XSS

Bonne pratique de sécurité Angular nº 1 : utilisez l’interpolation ({{  }}) pour encoder de manière sûre les caractères potentiellement dangereux et échapper les expressions HTML ou CSS non fiables dans une expression de template. 

À l’instar de React et Vue.js, Angular applique une approche de sécurité par défaut à la façon dont il gère l’interpolation de chaînes dans le navigateur. Par défaut, toutes les données sont considérées comme dangereuses et non fiables. C’est pourquoi ces bibliothèques, ainsi que d’autres bibliothèques de vues modernes, suivent la bonne pratique consistant à encoder par défaut toute sortie de texte dans un contexte HTML.

Comme nous l’avons expliqué en détail dans notre précédent article de blog sur les bonnes pratiques de sécurité AngularJS, il est fortement recommandé de suivre la « méthode Angular » en utilisant l’interpolation de chaînes intégrée avec des accolades, afin d’échapper toute entrée malveillante susceptible de mettre en danger votre application web et de l’exposer à des failles de script intersite (XSS).

2. Utilisez innerHTML avec prudence

Bonne pratique de sécurité Angular nº 2 : si vous devez ajouter du HTML de manière dynamique à un composant, liez sa génération à [innerHTML]. Ainsi, les données sont interprétées comme du HTML dans leur contexte et assainies : toutes les balises dangereuses sont supprimées, ce qui empêche l’exécution de code malveillant de script intersite. Notez que l’action d’ assainir n’est pas la même que celle d’ encoder.

Quelle est la différence entre l’assainissement et l’encodage de sortie ?

Avec l’encodage de sortie, les chaînes sont remplacées par leur représentation textuelle, qui peut correspondre à une balise HTML spécifique. Par exemple, si une entrée telle que script est analysée, Angular peut afficher ce texte en encodant les chevrons, une pratique standard dans de nombreuses bibliothèques et frameworks qui appliquent les bonnes pratiques de sécurité. Pour cela, il effectue un mappage appelé encodage des entités HTML et écrit le texte suivant dans le DOM : script. Le navigateur interprète ensuite le contexte et affiche une balise script.

Contrairement à l’encodage de sortie, l’assainissement ou le filtrage adopte une approche plus proactive : il détecte les caractères dangereux et les supprime du texte qui sera ensuite écrit dans le DOM.

Le contexte devient alors un facteur déterminant pour l’encodage de sortie et l’assainissement, car il influence directement la manière dont ces opérations doivent être effectuées.

Consultez la documentation Angular pour en savoir plus sur les contextes de sécurité. Voici ce qu’elle indique :

Angular définit les contextes de sécurité suivants :

* HTML est utilisé lorsqu’une valeur est interprétée comme du HTML, par exemple lors de la liaison à innerHtml.* Style est utilisé pour lier du CSS à la propriété style.* URL est utilisé pour les propriétés URL, telles que * Resource URL est une URL qui sera chargée et exécutée comme du code, par exemple, dans .

Notez le traitement particulier des URL, qui ne sont pas filtrées.

3. Ne générez jamais de modèles en concaténant des entrées utilisateur

Bonne pratique de sécurité Angular nº 3 : ne concaténez jamais de chaîne contenant une entrée potentiellement fournie par l’utilisateur pour créer un template.

Les cas d’usage qui nécessitent de concaténer des templates plutôt que d’utiliser correctement l’interpolation de chaînes ou la composition de composants recommandée dans une application Angular devraient être rares, voire inexistants. Si vous rencontrez cette mauvaise pratique dans une base de code, nous vous encourageons à assainir ou à refactoriser l’entrée fournie autant que possible.

Voici un exemple auquel vous devez prêter attention et que vous devez éviter :

Bonne pratique de sécurité Angular : ne générez jamais de templates en concaténant des entrées utilisateur

Prêtez une attention particulière à la concaténation inhabituelle d’une chaîne et d’un template à la ligne 20. La valeur de potentialUserInput peut être une expression malveillante d’origine inconnue ou non fiable. C’est un exemple de mauvaise pratique à surveiller.

Voici une illustration plus complète que vous pouvez tester dans mon environnement Angular : elle montre que les entrées utilisateur ne sont pas traitées de manière sûre lorsqu’elles sont concaténées au template.

Bonne pratique de sécurité Angular en action : ne générez jamais de templates en concaténant des entrées utilisateur

À ce sujet, la recommandation officielle du guide de sécurité Angular indique :

« Ne générez jamais le code source d’un template en concaténant des entrées utilisateur et des templates. Pour prévenir ces failles, utilisez le compilateur de templates hors ligne, également appelé injection de template. »

- Guide de sécurité Angular

Angular recommande d’utiliser son compilateur Ahead of Time pour compiler les templates hors ligne. Vous évitez ainsi complètement les nombreuses failles d’injection de template :

ng build --aot
ng serve --aot

Notez que dans les versions récentes d’Angular — Angular v9 et ultérieures — la compilation avec Ivy active par défaut la compilation anticipée, ce qui empêche l’injection de template :

{
  "projects": {
    "my-existing-project": {
      "architect": {
        "build": {
          "options": {
            ...
            "aot": true,
          }
        }
      }
    }
  }
}

4. N’utilisez jamais les API natives du DOM pour interagir avec les éléments HTML

Bonne pratique de sécurité Angular nº 4 : n’utilisez jamais les API natives du DOM pour interagir avec les éléments HTML de la page.

Évitez de manipuler directement le DOM. Utilisez plutôt les mécanismes de template et les API propres à Angular. De manière générale, évitez :

•  node.appendChild();

• d’utiliser les méthodes de l’objet document pour interagir avec la page

• d’utiliser les API jQuery

Certaines API natives d’Angular permettent le même type de manipulation directe du DOM que nous déconseillons, comme l’API ElementRef. ElementRef d’Angular présente des risques de sécurité lorsqu’elle sert à accéder à un nœud DOM directement pour le manipuler.

Cette pratique, comme toute autre interaction en dehors des API Angular, peut entraîner des failles de sécurité.

5. Évitez les moteurs de template dans les templates côté serveur

Bonne pratique de sécurité Angular nº 5 : évitez les moteurs de template tiers pour créer des templates ou y ajouter des données dans les applications Angular rendues côté serveur.

Si vous avez utilisé Node.js pour créer des applications web, vous avez probablement eu recours à un moteur de template comme EJS, Pug, Handlebars ou l’une de ses alternatives. Ces outils servent à gérer les templates rendus côté serveur pour la couche de présentation. Ils peuvent inclure des partiels, des compositions de mises en page et d’autres fonctionnalités qui facilitent la génération dynamique d’une vue.

Cependant, l’utilisation de ces mécanismes de moteur de template dans une application Angular rendue côté serveur peut entraîner l’injection de code malveillant dans un template. Cela s’explique par le fait que les données injectées proviennent de l’extérieur du périmètre des API Angular et ne peuvent pas être assainies, ce qui présente les mêmes risques que la concaténation de chaînes dans un template.

6. Analysez votre projet Angular pour détecter les composants qui introduisent des failles de sécurité

Bonne pratique de sécurité Angular nº 6 : analysez toujours les dépendances open source et les composants Angular de votre projet afin de détecter les failles de sécurité. Utilisez gratuitement la plateforme ou la CLI Snyk pour détecter, corriger et surveiller les failles de sécurité.

Lorsque vous utilisez des bibliothèques tierces, comme Angular et son écosystème de modules ou de composants, gardez à l’esprit les deux types de risques suivants : les failles de sécurité touchant la bibliothèque Angular elle-même et celles présentes dans les modules Angular tiers que vous importez et utilisez dans votre projet.

L’utilisation de composants présentant des failles connues constitue un risque de sécurité web documenté par le Top 10 OWASP, dont vous devez tenir compte. En effet, l’image ci-dessous présente une liste de modules Angular présentant des failles de sécurité connues, par exemple celles qui seraient signalées lors de l’exécution de npm install ou npm audit. Comme le montre cette image issue de notre rapport sur la sécurité des frameworks JavaScript, certains d’entre eux enregistrent des millions de téléchargements par an, mais ne disposent toujours d’aucun correctif de sécurité à ce jour :

Sécurité d’Angular : le risque des dépendances indirectes

Sécuriser les applications web Angular

Si vous utilisez npm audit, c’est une excellente première étape : vous êtes déjà sur la bonne voie !

Cependant, même si vous utilisez la fonctionnalité d’audit de npm, vous devez encore prendre en compte certains risques de sécurité :

• Vous avez peut-être corrigé toutes les failles de sécurité du projet à ce jour, mais que se passera-t-il lorsqu’une nouvelle faille sera découverte dans l’un de ces modules Angular ? Saurez-vous si elle touche l’une de vos applications Angular déployées sur Vercel, Netlify ou une autre plateforme ?

• L’autre problème est que npm audit ne suit que les failles connues ayant un CVE officiel. Or, [Snyk suit plus de 23 failles de sécurité concernant des modules Angular](https://snyk.io/blog/angular-vs-react-security-bakeoff-2019/), qu’npm audit ne signale pas.

Snyk résout ces deux problèmes pour vous, gratuitement ;-)

Comment commencer ?

Créez votre compte Snyk gratuit et connectez vos projets frontend sur GitHub ou Bitbucket : Snyk détectera automatiquement les problèmes et créera des pull requests contenant les correctifs.

Pour commencer rapidement et détecter les problèmes de sécurité Angular, vous pouvez aussi utiliser la CLI Snyk :

npm install -g snyk
snyk test

La CLI Snyk fournit bien plus que les vulnérabilités CVE connues, contrairement à npm audit qui ne les signale pas.

Source : Angular vs React : duel de sécurité 2019

Snyk fournit des recommandations de correction concrètes pour passer à une version corrigée.

Si vous cherchez un outil d’analyse de sécurité Angular, découvrez Snyk pour suivre vos dépendances open source, recevoir des alertes et les mettre à jour à mesure que des failles sont découvertes.

Pour aller plus loin :

• Si vous assurez la maintenance d’AngularJS ou développez activement avec ce framework, découvrez les 10 bonnes pratiques fondamentales de sécurité AngularJS.

• Comment la posture de sécurité d’Angular se compare-t-elle à celle de React ? Nous avons publié un rapport détaillé sur la sécurité des frameworks JavaScript à ce sujet.

Angular est-il sécurisé ?

Le nouveau framework Angular (Angular 2 et versions ultérieures) est considéré comme sécurisé par défaut et ne présente aucune faille de sécurité connue. En comparaison, son prédécesseur AngularJS compte plus de 25 failles de sécurité connues publiquement, dont les plus récentes remontent à juin 2020. Veillez à suivre les bonnes pratiques de sécurité Angular et consultez le rapport de Snyk sur la sécurité des frameworks JavaScript pour une analyse approfondie de la sécurité de l’écosystème des modules npm pour Angular, React et d’autres projets.

Comment sécuriser une application Angular ?

Voici quelques principes fondamentaux pour sécuriser une application Angular :

1. En tant que développeur, veillez à suivre la « méthode Angular » et ses bonnes pratiques pour vous protéger contre les attaques XSS. Par exemple, n’utilisez pas innerHTML, ne générez jamais de templates en concaténant des entrées utilisateur et n’utilisez jamais les API natives du DOM pour interagir avec les éléments HTML.

2. Analysez votre projet Angular afin de repérer les composants qui introduisent des failles de sécurité. Même si vous respectez les propres pratiques de sécurité d’Angular, les auteurs d’autres modules peuvent ne pas en faire autant et vous exposer à de graves problèmes. Ne vous contentez pas d’analyser : corrigez les problèmes et surveillez les nouvelles failles potentielles. Snyk est idéal pour cela et constitue un outil gratuit que vous pouvez facilement connecter à vos projets. Pour en savoir plus, consultez nos bonnes pratiques de sécurité Angular.

Quel framework est le plus sécurisé, Angular ou React ?

Le projet Angular (Angular 2+) ne présente aucune vulnérabilité de sécurité connue publiquement. React présente 2 vulnérabilités de sécurité, mais elles remontent à 2017 et vous utilisez probablement déjà une version plus récente. Le prédécesseur d’Angular, AngularJS, présente plus de 25 vulnérabilités de sécurité. Si vous développez ou maintenez encore des applications avec AngularJS, veillez à analyser vos projets avec un outil de sécurité gratuit conçu pour les développeurs, comme Snyk. À ce sujet, vous pouvez consulter le rapport sur la sécurité des frameworks JavaScript, qui étudie l’état de la sécurité dans les écosystèmes Angular et React.

Angular assainit-il les entrées utilisateur ?

Par défaut, Angular encode en sortie tous les textes potentiellement dangereux susceptibles de provoquer une attaque XSS, à condition de respecter les bonnes pratiques de codage sécurisé propres à Angular, comme l’utilisation des doubles accolades ({{}}) pour l’interpolation sécurisée. Si vous utilisez toutefois la liaison innerHTML d’Angular, celui-ci fera de son mieux pour vous protéger en assainissant le contenu dangereux. Cette méthode ne devrait cependant être utilisée qu’en dernier recours pour ajouter des entrées utilisateur.