Comparaison des pratiques de codage sécurisé de React et Angular

Écrit par

30 octobre 2019

0 minutes de lecture

Bienvenue dans le rapport 2019 de Snyk sur la sécurité des frameworks JavaScript. Cette section porte sur le niveau global de sécurité des projets Angular et React.

Dans cette section, nous examinons le niveau de sécurité des projets Angular et React. Nous nous intéressons notamment aux conventions de codage sécurisé, aux fonctionnalités de sécurité intégrées, aux politiques de divulgation responsable et à la documentation dédiée à la sécurité des projets.

Le tableau ci-dessous présente quelques-uns des composants de sécurité essentiels aux bonnes pratiques de maintenance de tout package open source, ainsi que la façon dont Angular et React les prennent en charge, le cas échéant.

Téléchargez le rapport ici !

Élément	Angular	React
Page consacrée à la sécurité	✅ https://angular.io/guide/security	❌Le site web de React (https://reactjs.org) ne mentionne aucune directive de sécurité, hormis la référence à la fonction dangerouslySetInnerHTML dans la section DOM Elements de la documentation API Reference.
Contact sécurité	✅security@angular.io	❌Aucun contact sécurité
Politique de divulgation responsable	✅Soutenue par les équipes de sécurité internes de Google et fondée sur la philosophie de sécurité de Google. Référence : https://www.google.com/about/appsecurity/	❌Aucune politique de divulgation responsable
Exemples de projets vulnérables	✅https://angular.io/generated/live-examples/security/stackblitz. html	❌Aucune référence à des exemples de projets vulnérables
Assainissement intégré	✅DomSanitizer fournit une fonction intégrée d’assainissement des valeurs non fiables. Référence : https://angular.io/api/platform-browser/DomSanitizer#sanitize	❌L’assainissement des entrées potentiellement malveillantes doit être mis en œuvre à la discrétion des utilisateurs, au moyen de bibliothèques tierces comme DOMPurify. Référence : https://github.com/cure53/DOMPurify
Politique de sécurité du contenu (CSP)	✅Compatibilité CSP pour les directives Angular v1.x. Référence : https://docs.angularjs.org/api/ng/directive/ngCsp	🔘Sans objet pour React
Falsification de requête intersites (CSRF)	✅Prise en charge intégrée du CSRF via le service HttpClient d’Angular. Références : https://angular.io/guide/http et https://docs.angularjs.org/api/ng/service/$http	🔘Sans objet pour React en tant que bibliothèque d’affichage. Les développeurs doivent s’en charger à l’aide de code personnalisé ou de modules communautaires.

Pratiques de codage sécurisé pour Angular

Angular v2 et les versions ultérieures reposent sur une architecture complètement différente de celle d’Angular v1, notamment avec une liaison de données unidirectionnelle. De plus, elles ont abandonné l’interpolation automatique des données par observateurs, ainsi que d’autres techniques qui étaient souvent à l’origine de nombreuses vulnérabilités de sécurité dans Angular v1.

La compilation anticipée (AoT) atténue des problèmes comme l’injection d’expressions dans les templates Angular et permet d’assurer la sécurité au moment de la compilation plutôt qu’à l’exécution. Toutefois, l’interpolation dynamique de templates côté client laisse toujours la porte ouverte aux vulnérabilités de sécurité sous la forme d’injections de code Angular. Dans sa documentation sur les bonnes pratiques, Angular déconseille clairement cette interpolation dynamique. La documentation d’Angular précise également que ces pratiques sont fortement déconseillées.

Pour atténuer les vulnérabilités de script intersites (XSS), Angular applique par défaut un encodage de sortie contextuel ou assainit le code malveillant. De plus, les conventions de nommage des méthodes indiquent beaucoup plus clairement les risques associés lorsque le développeur choisit délibérément de les utiliser, contrairement aux anciennes versions d’Angular, notamment Angular v1.x.

Des méthodes telles que bypassSecurityTrustHtml(value) ou bypassSecurityTrustUrl() signalent implicitement les dangers liés à leur utilisation pour insérer des données dans le DOM. En outre, Angular fournit DomSanitizer pour assainir explicitement les valeurs.

Pratiques de codage sécurisé pour React

Par défaut, React encode presque toutes les valeurs de données lors de la création d’éléments DOM. Pour permettre aux utilisateurs d’insérer du contenu HTML dans le DOM, React propose la fonction au nom évocateur dangerouslySetInnerHTML(), qui met clairement en évidence les risques liés à son utilisation.

Les contextes qui ne sont pas pris en charge par le modèle de sécurité de React et dont la gestion incombe aux utilisateurs comprennent la création des éléments suivants :

Des éléments HTML d’ancre (liens) dont la valeur de l’attribut href provient d’une entrée fournie par l’utilisateur. Cela concerne principalement les versions antérieures à React v16.9, récemment publiée, qui atténue les risques liés aux URL basées sur javascript: dans les valeurs de l’attribut href et dans d’autres contextes, comme les actions de formulaires, les sources d’iFrame, etc.
Des composants React à partir d’entrées fournies par l’utilisateur

Le rendu côté serveur de React peut introduire des vulnérabilités XSS si une entrée malveillante fournie par l’utilisateur est injectée telle quelle dans un contexte JavaScript sans encodage ni assainissement adéquats.

Sécurité HTTP

À partir de la version 1.2, les branches de version d’Angular v1.x ont ajouté la prise en charge de la Politique de sécurité du contenu (CSP), nécessaire en raison de l’utilisation de eval() et de Function() pour interpoler les expressions.

La falsification de requête intersites (CSRF) permet aux applications web de faire confiance à l’origine d’une requête. Dans les versions récentes d’Angular, la prise en charge du CSRF est intégrée au client HTTP via le module @angular/common/ http. Dans les versions Angular v1.x, une fonctionnalité similaire est prise en charge par le fournisseur $http.

Contrairement à Angular, React n’inclut pas de client HTTP et ne peut donc pas prendre en charge le CSRF directement. React se voulant une bibliothèque d’affichage minimaliste, il revient au développeur de gérer ce problème à l’aide de code personnalisé ou de modules développés par la communauté.

Nous vous recommandons vivement de télécharger la version complète du rapport au format numérique. Nous avons également publié les sections générales suivantes sous forme d’articles de blog :