“Ça marche en local… pourquoi sécuriser davantage ?”
– Un développeur naïf (aujourd’hui sans projet en production)

🚩 Le mythe du projet « simple »

Combien de fois a-t-on entendu :

“C’est juste un petit outil interne.”
“On verra la sécurité plus tard.”
“On est entre nous, pas besoin d’authentification.”

Sauf qu’un projet qui fonctionne… attire des utilisateurs.
Et qui dit utilisateurs, dit données sensibles, accès, et exposition.

🛡️ La sécurité, une dette technique invisible

Quand on code vite sans penser à la sécurité, on accumule une dette…
Et le jour où l’on veut ajouter un auth, limiter les accès ou auditer les opérations, il faut tout réécrire.

Voici les erreurs les plus fréquentes qu’on voit encore trop souvent :

• Tokens JWT non expirables

• Aucune protection contre le brute-force

• Utilisateurs stockés sans hashing (oui, ça arrive encore…)

• Filtres d’accès en dur dans le frontend 😱

✅ Les fondations à poser dès le départ

Même pour un side-project :

• 1. JWT avec expiration + refresh token

• 2. Gestion des rôles (RBAC) dès la V1

• 3. Hash du mot de passe avec BCrypt ou Argon2

• 4. Limiter les requêtes de type login / reset par IP ou session

• 5. Séparation Frontend / Backend stricte

Tu n’es pas obligé de tout faire d’un coup.
Mais tu ne peux pas te permettre de ne rien faire du tout.

🚀 Et si on codait « comme si ça allait scaler » ?

Le meilleur moment pour sécuriser ton application, c’était au début.
Le deuxième meilleur moment… c’est maintenant.

Même une simple TODO app mérite un minimum de protection.
Parce qu’elle ne le restera peut-être pas longtemps.