Sécurité des applications TypeScript : top 10 des vulnérabilités

Sécurité des applications TypeScript : top 10 des vulnérabilités

TypeScript, en tant que surcouche de JavaScript, hérite de nombreuses vulnérabilités de ce dernier, tout en ajoutant des risques spécifiques liés au système de types et à la compilation. Même un typage strict ne garantit pas la sécurité — des erreurs de logique et des pratiques non sécurisées peuvent entraîner des conséquences graves. Dans cet article, nous allons analyser le top 10 des vulnérabilités des applications TypeScript, fournir des exemples de code et donner des recommandations de protection.

1. Cross-Site Scripting (XSS) via dangerouslySetInnerHTML

L'une des vulnérabilités les plus courantes dans les applications React/TypeScript est l'insertion de HTML non échappé via dangerouslySetInnerHTML.

// ❌ Code vulnérablefunction UserComment({ comment }: { comment: string }) {  return <div dangerouslySetInnerHTML={{ __html: comment }} />;}

// ✅ Variante sécuriséeimport DOMPurify from 'dompurify';

function SafeComment({ comment }: { comment: string }) {  const sanitized = DOMPurify.sanitize(comment);  return <div dangerouslySetInnerHTML={{ __html: sanitized }} />;}

2. Injections SQL via des requêtes non échappées

L'utilisation de chaînes template dans les requêtes SQL avec des entrées utilisateur est une voie directe vers l'injection.

// ❌ Code vulnérableasync function getUser(id: string) {  const query = `SELECT * FROM users WHERE id = '${id}'`;  return db.execute(query);}

// ✅ Variante sécurisée (utilisation de requêtes paramétrées)async function safeGetUser(id: string) {  const query = 'SELECT * FROM users WHERE id = $1';  return db.execute(query, [id]);}

3. Prototype Pollution via la fusion profonde d'objets

TypeScript permet de copier facilement des objets, mais ne vérifie pas la chaîne des prototypes.

// ❌ Code vulnérablefunction merge(target: any, source: any) {  for (const key in source) {    if (typeof source[key] === 'object') {      target[key] = merge(target[key] || {}, source[key]);    } else {      target[key] = source[key];    }  }  return target;}

// ✅ Variante sécuriséefunction safeMerge(target: Record<string, any>, source: Record<string, any>) {  const result = { ...target };  for (const key of Object.keys(source)) {    if (key === '__proto__' || key === 'constructor') continue;    if (typeof source[key] === 'object' && !Array.isArray(source[key])) {      result[key] = safeMerge(result[key] || {}, source[key]);    } else {      result[key] = source[key];    }  }  return result;}

4. Injections NoSQL (MongoDB)

Lors du travail avec MongoDB, la transmission directe d'un objet depuis la requête peut entraîner l'injection d'opérateurs $where ou $regex.

// ❌ Code vulnérableapp.post('/login', async (req, res) => {  const { username, password } = req.body;  const user = await User.findOne({ username, password });  // Si on transmet { "$gt": "" }, on peut contourner la vérification});

// ✅ Variante sécuriséeimport { sanitize } from 'mongo-sanitize';

app.post('/login', async (req, res) => {  const cleanBody = sanitize(req.body);  const user = await User.findOne({    username: cleanBody.username,    password: cleanBody.password  });});

5. Commandes OS via child_process

L'exécution d'une entrée utilisateur via exec sans échappement est une vulnérabilité critique.

// ❌ Code vulnérableimport { exec } from 'child_process';

function runCommand(input: string) {  exec(`echo ${input}`, (err, stdout) => {    console.log(stdout);  });}

// ✅ Variante sécuriséeimport { execFile } from 'child_process';

function safeCommand(input: string) {  // Utilisation de execFile avec un tableau d'arguments  execFile('echo', [input], (err, stdout) => {    console.log(stdout);  });}

6. Path Traversal lors du travail avec les fichiers