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

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

TypeScript est une surcouche de JavaScript qui ajoute un typage statique, mais ne protège pas contre les vulnérabilités web classiques. Les développeurs débutants se fient souvent à la rigueur des types, oubliant la sécurité au niveau de la logique et des données. Dans cet article, nous analysons les 10 vulnérabilités les plus courantes dans les applications TypeScript avec des exemples de code et des méthodes de protection.

1. XSS (Cross-Site Scripting) via dangerouslySetInnerHTML

L'un des problèmes les plus fréquents est l'insertion de HTML utilisateur sans assainissement. En TypeScript, cela se produit souvent avec React ou Angular.

// ❌ Code vulnérable\nfunction UserComment({ comment }: { comment: string }) {\n  return <div dangerouslySetInnerHTML={{ __html: comment }} />;\n}\n\n// ✅ Version sécurisée\nimport DOMPurify from 'dompurify';\n\nfunction SafeComment({ comment }: { comment: string }) {\n  const sanitized = DOMPurify.sanitize(comment);\n  return <div dangerouslySetInnerHTML={{ __html: sanitized }} />;\n}

2. Injections SQL via des requêtes en chaîne de caractères

TypeScript ne protège pas contre les injections SQL si vous utilisez des chaînes brutes. Utilisez toujours des requêtes paramétrées.

// ❌ Dangereux\nconst query = `SELECT * FROM users WHERE email = '${userEmail}'`;\n\n// ✅ Sécurisé (exemple avec Prisma)\nconst user = await prisma.user.findUnique({\n  where: { email: userEmail }\n});

3. Stockage non sécurisé des secrets dans le code

Les clés API, jetons et mots de passe ne doivent pas apparaître dans le code source. TypeScript est compilé en JavaScript, et toutes les chaînes restent lisibles.

// ❌ Ne faites jamais cela\nconst API_KEY = 'sk-1234567890abcdef';\n\n// ✅ Utilisez les variables d'environnement\nconst API_KEY = process.env.API_KEY;\nif (!API_KEY) throw new Error('API_KEY est manquant');

4. Injections NoSQL (MongoDB)

Avec MongoDB via Mongoose ou le driver, on peut accidentellement passer un objet de requête qui manipule la logique.

// ❌ Code vulnérable\napp.post('/login', async (req, res) => {\n  const user = await User.findOne({ \n    email: req.body.email, \n    password: req.body.password \n  });\n});\n\n// ✅ Version sécurisée\napp.post('/login', async (req: Request, res: Response) => {\n  const { email, password } = req.body;\n  if (typeof email !== 'string' || typeof password !== 'string') {\n    return res.status(400).send('Entrée invalide');\n  }\n  const user = await User.findOne({ email, password });\n});

5. CSRF (Cross-Site Request Forgery)

Si votre application utilise l'authentification par cookie, un attaquant peut effectuer des actions au nom de l'utilisateur.

// ❌ Absence de protection\napp.post('/transfert', (req, res) => {\n  // Exécution du transfert sans vérification de la source\n});\n\n// ✅ Protection via jeton CSRF (exemple avec csurf)\nimport csrf from 'csurf';\nconst csrfProtection = csrf({ cookie: true });\napp.post('/transfert', csrfProtection, (req, res) => {\n  // Exécution sécurisée\n});

6. Pollution de prototype (Prototype Pollution)

Lors de la fusion d'objets sans vérification, on peut écraser les propriétés du prototype, ce qui entraîne des vulnérabilités.

// ❌ Dangereux\nfunction merge(target: any, source: any) {\n  for (const key in source) {\n    target[key] = source[key];\n  }\n}\n\n// ✅ Sécurisé\nfunction safeMerge(target: Record<string, any>, source: Record<string, any>) {\n  for (const key in source) {\n    if (Object.prototype.hasOwnProperty.call(source, key)) {\n      target[key] = source[key];\n    }\n  }\n}

7. Fuite d'informations via les erreurs

Les traces de pile et les détails de la base de données ne doivent pas être affichés à l'utilisateur. TypeScript peut endormir la vigilance en raison du typage strict.

// ❌ Mauvais\napp.use((err, req, res, next) => {\n  res.status(500).json({ error: err.m