Valider, limiter, surveiller

Validation des entrées et injections

• Ne jamais faire confiance aux données venues de l'extérieur : paramètres d'URL, en-têtes HTTP, corps de requête.
• Requêtes préparées contre l'injection SQL (et d'autres injections).
• Sanitisation : nettoyer et valider les entrées pour éviter XSS (Cross-Site Scripting) ou CSRF (Cross-Site Request Forgery), selon le cours.

Au TP : valider la longueur du nom d'utilisateur, la validité du mot de passe, et renvoyer un message détaillant les problèmes si les données sont invalides.

-- Dangereux : concaténer l'entrée
"SELECT * FROM users WHERE email = '" + email + "'"
-- Préparé : l'entrée reste une donnée
"SELECT * FROM users WHERE email = ?"

(exemple ajouté)

Limiter le taux de requêtes

Le rate limiting limite le nombre de requêtes qu'un utilisateur peut faire dans un intervalle de temps (le TP donne l'exemple de 100 requêtes par heure) pour contrer le DoS et limiter l'impact d'un attaquant. Le CAPTCHA vérifie que les requêtes viennent de vrais utilisateurs et non de robots.

Surveillance et audit

• Journaux (logs) détaillés : adresse IP, heure, types de requêtes, résultats.
• Audits réguliers pour vérifier les normes et l'absence de nouvelles vulnérabilités.

Autres points du TP

• Helmet : en-têtes de sécurité HTTP (réduit des attaques comme XSS).
• Gestion des erreurs : message clair en cas de token manquant ou invalide, mais pas de trace de pile ni d'infos sur la structure de la base.
• Paquets : auditer et mettre à jour (exemple du TP : « 13 vulnerabilities (3 low, 2 moderate, 7 high, 1 critical) »).