OWASP Top 10 expliqu? pour les d?veloppeurs ? avec exemples de code

Qu'est-ce que l'OWASP Top 10

L'OWASP (Open Worldwide Application Security Project) publie depuis 2003 une liste des 10 risques de s?curit? les plus critiques pour les applications web. Cette liste est mise ? jour tous les 3 ? 4 ans sur la base de donn?es r?elles de compromission. En 2026, la version 2021 reste la r?f?rence.

Ce n'est pas une liste exhaustive de toutes les vuln?rabilit?s possibles ? c'est une s?lection des risques les plus r?pandus et les plus impactants, ceux que chaque d?veloppeur devrait conna?tre et savoir ?viter.

A01 ? Broken Access Control

Le contr?le d'acc?s d?finit ce que les utilisateurs peuvent et ne peuvent pas faire. Quand il est d?faillant, des utilisateurs non autoris?s peuvent acc?der ? des donn?es ou fonctions r?serv?es ? d'autres.

Exemple vuln?rable ? IDOR (Insecure Direct Object Reference)

// ❌ Dangereux : n'importe qui peut voir la commande de n'importe qui
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order);
});

Correction

// ✅ Correct : on v?rifie que la commande appartient ? l'utilisateur connect?
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findOne({
    _id: req.params.id,
    userId: req.user.id  // l'utilisateur ne peut voir que SES commandes
  });
  if (!order) return res.status(404).json({ error: 'Non trouv?' });
  res.json(order);
});

A02 ? Cryptographic Failures

Les donn?es sensibles mal chiffr?es (ou pas chiffr?es du tout) exposent vos utilisateurs ? des fuites catastrophiques. Les erreurs les plus courantes : stocker des mots de passe en MD5 ou SHA1, utiliser HTTP au lieu de HTTPS, transmettre des donn?es sensibles en clair.

// ❌ Dangereux : MD5 est cass?, ne jamais l'utiliser pour les mots de passe
const hashedPassword = crypto.createHash('md5').update(password).digest('hex');

// ✅ Correct : bcrypt avec un co?t suffisant (min 12)
const bcrypt = require('bcrypt');
const hashedPassword = await bcrypt.hash(password, 12);

// V?rification
const isValid = await bcrypt.compare(inputPassword, hashedPassword);

A03 ? Injection

L'injection consiste ? ins?rer du code malveillant dans une requ?te interpr?t?e par le syst?me. L'injection SQL est la plus connue, mais les injections NoSQL, de commandes shell, et LDAP sont tout aussi dangereuses.

// ❌ Dangereux : concat?nation directe de l'input utilisateur
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`;
// Input malveillant : ' OR '1'='1 ? expose tous les utilisateurs

// ✅ Correct : requ?tes param?tr?es
const query = 'SELECT * FROM users WHERE email = ';
const [rows] = await db.execute(query, [req.body.email]);

// ✅ Correct avec un ORM
const user = await User.findOne({ where: { email: req.body.email } });

A04 ? Insecure Design

Certaines vuln?rabilit?s ne viennent pas d'un bug de code mais d'une mauvaise conception. Exemple classique : une fonctionnalit? de reset de mot de passe qui utilise une question secr?te (facilement devinable) au lieu d'un lien ? usage unique.

A05 ? Security Misconfiguration

Les mauvaises configurations sont les vuln?rabilit?s les plus fr?quentes et les plus ?vitables : mots de passe par d?faut, ports ouverts inutilement, messages d'erreur qui exposent la stack trace, headers de s?curit? HTTP absents.

// ✅ Headers de s?curit? essentiels (avec Helmet.js en Node)
const helmet = require('helmet');
app.use(helmet());

// Ce que Helmet configure automatiquement :
// Content-Security-Policy
// X-Frame-Options: DENY
// X-Content-Type-Options: nosniff
// Strict-Transport-Security (HSTS)
// Referrer-Policy

// ✅ Ne jamais exposer les d?tails d'erreur en production
app.use((err, req, res, next) => {
  console.error(err); // logger en interne
  res.status(500).json({
    error: process.env.NODE_ENV === 'production'
       'Erreur interne'
      : err.message  // d?tails seulement en dev
  });
});

A06 ? Vulnerable Components

Vos d?pendances npm, pip, ou Maven peuvent contenir des vuln?rabilit?s connues. L'attaque Log4Shell en 2021 (CVE-2021-44228) a compromis des millions de serveurs via une biblioth?que Java utilis?e par presque tout le monde.

# V?rifier les vuln?rabilit?s connues dans vos d?pendances
npm audit
npm audit fix  # corriger automatiquement les moins risqu?es

# Python
pip install safety
safety check

# Automatiser avec GitHub Dependabot ou Snyk dans votre CI/CD

A07 ? Authentication Failures

Mots de passe trop simples accept?s, pas de protection contre le brute force, tokens de session pr?visibles, pas de MFA sur les comptes sensibles : les failles d'authentification donnent acc?s direct aux donn?es de vos utilisateurs.

// ✅ Politique de mot de passe robuste
function validatePassword(password) {
  if (password.length < 12) throw new Error('Minimum 12 caract?res');
  if (!/[A-Z]/.test(password)) throw new Error('Au moins une majuscule');
  if (!/[0-9]/.test(password)) throw new Error('Au moins un chiffre');
  // V?rifier contre les listes de mots de passe courants
  if (commonPasswords.includes(password.toLowerCase()))
    throw new Error('Mot de passe trop courant');
}

// ✅ Verrouillage progressif anti-brute force
const loginAttempts = new Map();
async function handleLogin(email, password) {
  const key = email;
  const attempts = loginAttempts.get(key) || { count: 0, lastAttempt: 0 };
  const delay = Math.pow(2, attempts.count) * 1000; // d?lai exponentiel
  if (Date.now() - attempts.lastAttempt < delay)
    throw new Error('Trop de tentatives, r?essayez plus tard');
  // ... v?rification du mot de passe
}

A08 ? Software Integrity Failures

D?s?rialisation de donn?es non v?rifi?es, mise ? jour automatique sans v?rification de signature, pipeline CI/CD non s?curis? : si votre code ou vos mises ? jour peuvent ?tre alt?r?s par un tiers, vous ?tes vuln?rable aux attaques supply chain.

A09 ? Logging Failures

Sans logs, vous ne saurez jamais qu'une attaque est en cours ou qu'elle a eu lieu. La dur?e moyenne de d?tection d'une intrusion est de 206 jours. De bons logs permettent de d?tecter les attaques, d'analyser les incidents, et de prouver la conformit?.

// ✅ Logger les ?v?nements de s?curit? essentiels
const securityLogger = {
  loginSuccess: (userId, ip) =>
    logger.info('AUTH_SUCCESS', { userId, ip, timestamp: new Date() }),
  loginFailure: (email, ip) =>
    logger.warn('AUTH_FAILURE', { email, ip, timestamp: new Date() }),
  accessDenied: (userId, resource) =>
    logger.warn('ACCESS_DENIED', { userId, resource, timestamp: new Date() }),
  suspiciousActivity: (details) =>
    logger.error('SUSPICIOUS', { ...details, timestamp: new Date() })
};

// ?️ Ne jamais logger : mots de passe, tokens, donn?es personnelles sensibles

A10 ? SSRF

La SSRF permet ? un attaquant de forcer votre serveur ? faire des requ?tes vers des ressources internes normalement inaccessibles depuis l'ext?rieur (m?tadonn?es AWS, services internes, etc.).

// ❌ Dangereux : votre serveur fait des requ?tes vers n'importe quelle URL
app.get('/preview', async (req, res) => {
  const response = await fetch(req.query.url);  // l'attaquant peut mettre http://169.254.169.254/
  res.send(await response.text());
});

// ✅ Correct : valider et filtrer les URLs autoris?es
const ALLOWED_HOSTS = ['api.exemple.com', 'cdn.exemple.com'];
app.get('/preview', async (req, res) => {
  const url = new URL(req.query.url);
  if (!ALLOWED_HOSTS.includes(url.hostname))
    return res.status(403).json({ error: 'Host non autoris?' });
  const response = await fetch(url.toString());
  res.send(await response.text());
});

Synth?se

L'OWASP Top 10 couvre les risques les plus r?pandus, mais la s?curit? web est un domaine vaste. La bonne nouvelle : en appliquant les corrections pr?sent?es dans ce guide, vous ?liminez la grande majorit? des vecteurs d'attaque que les attaquants opportunistes utilisent. Chaque ligne de code s?curis?e r?duit la surface d'attaque de votre application.