5 bonnes pratiques de sécurité pour React avec TypeScript

En tant que bibliothèque dédiée à la création d’interfaces utilisateur, et non un framework complet, React permet aux développeurs de choisir les bibliothèques qu’ils préfèrent pour différents aspects d’une application, comme le routage, l’historique et l’authentification. De son côté, Microsoft a créé TypeScript comme une extension de JavaScript afin d’ajouter le typage statique facultatif à un langage autrement faiblement typé.

L’utilisation de TypeScript avec React présente plusieurs avantages pour le développement d’applications, notamment la possibilité de créer des composants React plus simples et de mieux prendre en charge JavaScript XML (JSX) pour la validation des types statiques. Comme nous pouvons utiliser des composants JavaScript dans un projet TypeScript, les équipes de développement qui maîtrisent JavaScript peuvent mettre à profit ces connaissances et bénéficier du typage fort.

Il existe de nombreux modèles de base pour démarrer des projets React, notamment Create React App, Create Next App, Vite, React Boilerplate et React Starter Kit.

Create React App est un outil autonome qui fonctionne avec npm ou Yarn. Une fois installé, il suffit de quelques commandes pour générer et lancer un nouveau projet.

Commencez par ouvrir votre terminal et exécutez la commande suivante pour installer l’outil Create React App :

1npm install -g create-react-app

Créez ensuite un projet à l’aide du modèle TypeScript avec l’exécution de paquets Node (npx) :

1npx create-react-app [webapp-name] --template typescript

Vous pouvez également créer le projet avec le gestionnaire de paquets Yarn :

1yarn create react-app [webapp-name] --template typescript

les risques de sécurité potentiels et les moyens de les atténuer.

Activer le mode strict

Le mode strict active automatiquement les paramètres du compilateur TypeScript liés aux règles de types de données. Lorsque le mode strict de TypeScript est activé, le code est validé selon des règles de typage strictes. Les développeurs doivent ainsi écrire du code qui respecte les limites des types de données attribués aux variables, constantes, paramètres et valeurs de retour des fonctions. Le mode strict est important, car il permet aux développeurs de détecter et de corriger les erreurs d’incompatibilité de types dès les premières phases du développement.

Supposons qu’une application contienne la fonction suivante :

1export async function deleteComment(slug, commentId): Promise<void> {
2  await axios.delete(`articles/${slug}/comments/${commentId}`);
3}

Nous appelons la fonction deleteComment en passant l’argument slug sous forme de chaîne et commentId sous forme de nombre :

1deleteComment('whats-new-in-react', 1257);

Toutefois, rien ne nous empêche d’appeler la fonction avec deux chaînes :

1deleteComment('foo', 'bar');

Le code ci-dessus n’est peut-être pas autorisé par les règles métier, mais comme nous n’avons pas indiqué de types, les deux paramètres sont considérés comme étant de type any par défaut. Par conséquent, TypeScript ne peut pas nous aider à détecter le problème tant que nous n’activons pas le mode strict.

Le mode strict est défini sur true dans les applications React nouvellement créées. Cette valeur peut toutefois être différente dans les projets existants.

Pour vérifier que notre projet TypeScript fonctionne en mode strict, ouvrez le fichier tsconfig.json et vérifiez que la valeur de la configuration strict est true :

1{
2  ...
3  "strict": true,
4  ...
5}

Revenons à la fonction deleteComment. Une petite modification suffit à déclencher des erreurs de compilation TypeScript :

Ajoutez les types chaîne et nombre aux paramètres de deleteComment :

1export async function deleteComment(slug: string, commentId: number): Promise<void> {
2  await axios.delete(`articles/${slug}/comments/${commentId}`);
3}

Cela génère des erreurs de compilation et empêche les développeurs de créer du code côté client qui appelle par inadvertance la fonction deleteComment avec des types non valides, comme dans l’exemple ci-dessous :

1deleteComment(null, true);

L’option strict active automatiquement d’autres options de compilateur recommandées, liées à la vérification des types plus stricte.

N’utilisez pas le type de retour any pour les fonctions de rappel dont la valeur sera ignorée

Si vous déclarez le type de retour d’une fonction de rappel comme any, puis utilisez par inadvertance sa valeur de retour alors que la fonction ne renvoie aucune valeur, vous risquez de faire une erreur qui passera inaperçue.

Prenons l’exemple d’une fonction nommée onListFieldKeyUp qui prend en paramètre une fonction de rappel nommée onEnter :

1export function onListFieldKeyUp(onEnter: () => any): (ev: React.KeyboardEvent) => void {
2  return (ev) => {
3    if (ev.key === 'Enter') {
4      ev.preventDefault();  
5      var enterResult = onEnter();
6      //do something with enterResult
7      }
8    }
9  };
10}

Notez que la variable enterResult ci-dessus stocke le résultat de la fonction de rappel onEnter afin de pouvoir le réutiliser. Bien que cette fonction de rappel ne renvoie aucune valeur, nous avons déclaré la variable enterResult de type any. TypeScript ne peut donc pas vous signaler le problème.

Quelle est la solution ?

Tout d’abord, si vous savez que la fonction onEnter ne renvoie aucune valeur, remplacez le type any du paramètre de la fonction de rappel par void. TypeScript affiche alors l’erreur « Une expression de type 'void' ne peut pas être testée pour sa valeur de vérité. »

Enfin, supprimez le code qui stocke la valeur de retour de onEnter dans la variable enterResult :

1export function onListFieldKeyUp(onEnter: () => void): (ev: React.KeyboardEvent) => void {
2  return (ev) => {
3    if (ev.key === 'Enter') {
4      ev.preventDefault();
5      onEnter();
6    }
7  };
8}

Attaques par rendu côté serveur dans React

Une application web peut générer le code HTML côté client ou côté serveur. Les bibliothèques et frameworks JavaScript modernes, comme React, utilisent le rendu côté serveur. Cette approche améliore les performances, notamment en accélérant le chargement des pages : le back-end peut pré-générer rapidement la page entière et transmettre le contenu HTML, CSS et JavaScript statique au front-end. Les utilisateurs peuvent ainsi naviguer et afficher la page web instantanément. Cette approche contribue également au référencement naturel (SEO), car les pages qui se chargent rapidement obtiennent de meilleurs scores dans les algorithmes de recherche.

Le cross-site scripting (XSS) est une méthode d’attaque qui consiste à injecter des scripts malveillants côté client dans une page web. React a été conçu pour se protéger des attaques XSS. Toutefois, une programmation incorrecte et le rendu côté serveur dans React peuvent entraîner une vulnérabilité XSS que des utilisateurs malveillants chercheront à exploiter.

Par exemple, ne concaténez jamais de données non assainies avec le résultat de la fonction renderToStaticMarkup avant d’envoyer la chaîne au client :

1app.get("/", function (req, res) {
2  return res.send(
3    ReactDOMServer.renderToStaticMarkup(
4      React.createElement("h1", null, "Hello World!")
5    ) + someUnsanitizedData
6  );
7});

Le code ci-dessus est dangereux, car un pirate pourrait avoir compromis la variable someUnsanitizedData afin d’y inclure du code JavaScript malveillant, comme ci-dessous :

1someUnsanitizedData = "</scrïpt><scrïpt>alert('You are compromised!')</scrïpt>

Pour prévenir les attaques XSS, utilisez un assainisseur HTML comme DomPurify.

Utiliser des types opaques

Un type de données opaque garantit le masquage des informations. Sa structure de données n’est pas définie dans l’interface, ce qui masque et encapsule l’implémentation d’un type de données concret. Les modules externes peuvent utiliser le type opaque sans accéder à ses composants internes, tandis que les fonctions internes disposant des informations manquantes peuvent manipuler ce type. Les types opaques vous permettent de modifier et de faire évoluer les détails internes sans changer le code qui les utilise. Leur utilisation reste donc une bonne pratique de développement.

TypeScript ne fournit pas de types opaques prêts à l’emploi, mais il est facile de les implémenter. Voyons comment résoudre un cas concret.

Imaginons une application de commerce en ligne qui utilise une fonction TypeScript pour ajouter un produit au panier d’un client :

1function addToCart(customerCode: string, productCode: string) {
2  console.log(`Product ${productCode} has been added to the cart of the customer ${customerCode}`);
3}

Ces paramètres typés garantissent que le programmeur ne pourra pas utiliser des nombres ou d’autres types à la place de chaînes pour les paramètres customerCode et productCode :

1addToCart('ABC-001984', 'SPC-004487');

Ce code ne présente rien de problématique en soi, mais le type n’exprime pas les valeurs avec précision. À la simple lecture de la ligne de code, on ne peut pas savoir quel paramètre correspond au code client ou au code produit. De plus, TypeScript n’affichera aucun avertissement si les deux valeurs sont interverties.

Voyons maintenant comment la fonction addToCart a été remaniée dans l’exemple ci-dessous pour utiliser des types opaques :

1export type CustomerCode = string & { _: 'CustomerCode' };
2export type ProductCode = string & { _: 'ProductCode' };
3
4const makeCustomerCode =
5  (customerCode: string): CustomerCode => {
6    if (/^\w{3}-\d{6}$/.test(customerCode)) { //regex validation
7      return customerCode as CustomerCode;
8    } else {
9      throw new Error('Not a customer code!');
10    }
11  };
12
13const makeProductCode =
14  (productCode: string): ProductCode => {
15    if (/^\w{3}-\d{6}$/.test(productCode)) { //regex validation
16      return productCode as ProductCode;
17    } else {
18      throw new Error('Not a product code!');
19    }
20  };
21
22function addToCart(customerCode: CustomerCode, productCode: ProductCode) {
23  console.log(`Product ${productCode} has been added to the cart of the customer ${customerCode}`);
24}
25
26let customerCode: CustomerCode = makeCustomerCode('ABC-001984');
27let productCode: ProductCode = makeProductCode('SPC-004487');
28
29addToCart(customerCode, productCode);

Grâce à nos nouveaux types opaques et à leur validation par expression régulière, le code génère une erreur de compilation si vous fournissez des codes incorrects :

1let customerCode: CustomerCode = makeCustomerCode('000-001984'); //Error: Not a customer code!
2let productCode: ProductCode = makeProductCode('9871'); //Error: Not a product code!

Quand utiliser dangerouslySetInnerHTML et respecter les bonnes pratiques d’assainissement

React utilise un DOM virtuel, une stratégie légère permettant de mettre à jour efficacement le code HTML de la page et évitant aux utilisateurs de devoir manipuler directement les éléments HTML au moyen des API natives du navigateur.

Il peut toutefois arriver que vous deviez contourner ce mécanisme et définir du code HTML brut dans vos applications React. Pour manipuler directement ce code HTML, React utilise une propriété spéciale de composant appelée dangerouslySetInnerHTML :

1return (
2<p dangerouslySetInnerHTML={{__html: data}}></p>);

Comme son nom l’indique, la propriété dangerouslySetInnerHTML peut rendre une application vulnérable si elle n’est pas utilisée correctement. Les pirates peuvent exploiter les applications qui s’appuient sur dangerouslySetInnerHTML pour lancer des attaques de cross-site scripting (XSS) et injecter dans votre site web des scripts malveillants déguisés en saisies utilisateur fiables.

Pour éviter ce risque, assainissez toujours le contenu HTML avant de l’insérer afin d’éliminer les « impuretés » et le code malveillant. Vous pouvez utiliser une bibliothèque comme DOMPurify et appliquer la fonction sanitize :

1import DOMPurify from 'dompurify';
2
3return (
4<p dangerouslySetInnerHTML={{__html: DOMPurify.sanitize(data)}}></p>);

Il est essentiel de noter que, comme toute autre bibliothèque, DOMPurify peut occasionnellement présenter une vulnérabilité de sécurité. Heureusement, la Snyk Vulnerability Database a rapidement intégré les données sur cette vulnérabilité et proposé une solution. Ainsi, quelle que soit la fiabilité historique d’une bibliothèque, nous devons tout de même faire preuve de diligence et utiliser un outil comme Snyk pour rechercher régulièrement les vulnérabilités connues.

Et ce n’est là qu’un des problèmes de sécurité auxquels les développeurs doivent prêter attention. Dans cette vidéo, Liran Tal explique comment les développeurs React peuvent commettre des erreurs qui entraînent d’autres vulnérabilités exploitables par les pirates.

Play Video: Liran Tal - You thought your React application is secure? Think again | ReactNext 2021

Conclusion

Dans cet article, nous avons présenté plusieurs bonnes pratiques pour développer des applications React avec TypeScript, décrit les risques de sécurité potentiels et proposé des solutions.

• Le mode strict permet d’imposer des contraintes de types et de détecter tôt dans le développement les erreurs d’incompatibilité de types. L’utilisation de void dans les fonctions de rappel empêche les développeurs d’utiliser une valeur de retour lorsque la fonction de rappel n’en renvoie aucune.

• Les attaques par injection de commandes constituent une grave menace pour la sécurité. Évitez de créer du code dynamique à partir de saisies utilisateur suspectes et utilisez la fonction execFile plutôt que exec.

• Les injections HTML constituent une autre grave menace pour la sécurité. Lorsque vous utilisez dangerouslySetInnerHTML, assainissez toujours le balisage inséré afin d’empêcher les pirates de manipuler les saisies utilisateur et d’injecter du code malveillant.

• Enfin, les types opaques donnent du sens aux domaines et facilitent la validation des types ainsi que la prévention des doublons.

Il est facile d’utiliser TypeScript et React pour créer des applications rapides et sécurisées, en particulier avec des frameworks comme Create React App et en s’appuyant sur vos connaissances préalables de JavaScript.