🚨 Top 15 erreurs de sécurité qui ruinent ton SaaS

Lorsqu’on construit une application SaaS, beaucoup de développeurs — notamment freelances ou juniors — se concentrent sur les fonctionnalités et l’UX. La sécurité passe souvent après… jusqu’au jour où une fuite ou une attaque survient.

Voici une liste des erreurs de sécurité que l’on retrouve le plus souvent dans les projets, et qui sont pourtant faciles à éviter :

---

🔑 API et gestion des droits

• Endpoints d’administration non protégés
  Trop souvent, l’API d’admin reste exposée sans contrôle d’accès strict.
• Logique admin dans le client
  Le frontend contient parfois des morceaux de code révélant comment fonctionnent les privilèges. Un vrai guide pour un attaquant.
• Accès aux ressources d’autres utilisateurs
  C’est l’erreur numéro un : un simple changement d’ID dans l’URL permet de consulter les données d’un autre utilisateur.
• Mise à jour de propriétés sensibles
  Exemple classique : la variable isAdmin dans le modèle utilisateur, modifiable via un simple PATCH.

---

🕵️‍♂️ Fuites d’informations

• Secrets dans le frontend
  Clés API, tokens, ou même fichiers IPA/APK de vieilles versions : tout ça finit parfois exposé au grand public.
• Sitemaps ou listes d’endpoints oubliées
  Ce sont des cartes au trésor pour qui veut explorer les zones sensibles de votre app.
• Réponses API trop bavardes
  Inutile de renvoyer un password_hash ou des tokens internes dans un JSON.
• Publication de source maps
  Les fichiers .map rendent votre code compréhensible et facilitent l’ingénierie inverse.
• IDs incrémentés
  Les /users/1, /users/2, /users/3 permettent de dumper une base entière. Préférez des UUIDs.

🧑‍💻 Dev & CI/CD

• Secrets commités dans Git
  Clés API et variables d’environnement poussées par erreur (puis supprimées en commit suivant, mais toujours visibles dans l’historique).
• .env exposés
  Le fichier .env traîne parfois sur un serveur, accessible en simple GET /env ou via une mauvaise config Nginx/Apache.
• Droits trop larges en CI/CD
  Les runners CI ont accès à toute la prod au lieu d’un rôle limité (principe du moindre privilège oublié).
• Pas de rotation des clés
  Une clé API générée il y a 3 ans reste valide et exposée dans plusieurs environnements.

---

🔐 Authentification & sessions

• Pas de rate limiting sur le login
  Laisser un formulaire de connexion sans limite de tentatives = brute force assuré.
• JWT qui n’expirent jamais
  Un token volé reste valable indéfiniment → un accès permanent pour l’attaquant.
• Cookies de session sans HttpOnly ni Secure
  Facilement volables via XSS ou interceptables en clair.

---

🛠️ Divers erreurs « bêtes mais communes »

• Backup exposé dans un répertoire /backup
  Zip ou SQL dump oublié après un test → jackpot pour un attaquant.
• Admin panel avec mot de passe par défaut
  Le fameux admin/admin qui traîne encore trop souvent.
• Pas de monitoring ni alerting
  On découvre l’intrusion uniquement… quand un client appelle pour dire qu’il a vu ses données fuiter.
• Pas de politique de logs
  Soit trop de logs sensibles, soit pas assez pour comprendre un incident.

✅ Conclusion

La majorité de ces failles ne demandent pas de techniques complexes : ce sont des oublis, des mauvaises habitudes ou un manque de relecture. Les corriger ne prend pas beaucoup de temps, mais peut éviter une catastrophe.

Un bon réflexe : considérer chaque mise en production comme une ouverture de porte vers l’extérieur. La question à se poser : “Est-ce que je n’ai pas laissé les clés sous le paillasson ?”