𝗜 𝗔𝘂𝗱𝗶𝘁𝗲𝗱 𝗠𝘆 𝗦𝗶𝗱𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 — 𝗛𝗲𝗿𝗲 𝗜𝘀 𝗪𝗵𝗮𝘁 𝗜 𝗙𝗼𝘂𝗻𝗱

𝗝'𝗮𝗶 𝗮𝘂𝗱𝗶𝘁é 𝗺𝗲𝘀 𝗽𝗿𝗼𝗷𝗲𝘁𝘀 𝗽𝗲𝗿𝘀𝗼𝗻𝗻𝗲𝗹𝘀 𝗽𝗼𝘂𝗿 𝗹𝗮 𝘀é𝗰𝘂𝗿𝗶𝘁é — 𝘃𝗼𝗶𝗰𝗶 𝗰𝗲 𝗾𝘂𝗲 𝗷'𝗮𝗶 𝘁𝗿𝗼𝘂𝘃é

J'ai récemment audité tous mes projets personnels. J'ai vérifié mes backends FastAPI, mes bots Telegram et mes applications web. Je pensais être prudent.

J'avais tort.

J'ai trouvé de vrais bugs que j'ai réellement mis en production. Ce ne sont pas des problèmes théoriques. Ce sont des erreurs que j'ai commises en essayant d'aller vite.

Voici les principaux problèmes que j'ai rencontrés et comment les corriger :

1. Authentification conditionnelle J'ai écrit du code qui ne vérifiait les clés API que si un secret existait. Si j'oubliais de configurer le secret dans mon environnement, la vérification était totalement ignorée. Cela laissait mon API ouverte à tout le monde.

• Correction : Ne rendez jamais l'authentification conditionnelle. Si le secret est manquant, l'application doit renvoyer une erreur et s'arrêter.

2. Fuite de clés dans l'historique Git J'ai trouvé d'anciennes clés API dans mon historique Git. Je les avais déplacées vers des fichiers .env plus tard, mais Git conserve chaque ancienne version de votre code pour toujours.

• Correction : Considérez toute clé ayant été commitée dans Git comme compromise. Révokez-la immédiatement. Utilisez des outils comme git-filter-repo pour nettoyer votre historique.

3. Points de terminaison de débogage restants J'ai laissé des endpoints en production qui affichaient ma configuration de base de données et mes paramètres système. Ils sont utiles pendant le développement, mais dangereux une fois en ligne.

• Correction : Ajoutez la suppression des endpoints de débogage à votre checklist de déploiement.

4. Messages d'erreur trop détaillés Je renvoyais des erreurs système brutes à l'utilisateur. Ces erreurs révèlent vos chemins de fichiers, vos types de bases de données et vos versions de bibliothèques. Un attaquant peut utiliser ces données pour cibler votre système.

• Correction : Enregistrez l'erreur complète dans vos logs internes. Renvoyez un message générique « Internal Server Error » au client.

5. XSS via innerHTML J'utilisais innerHTML pour afficher les données utilisateur dans mon frontend. Cela permet à des attaquants d'injecter des scripts dans votre site.

• Correction : Sanitisez toujours les données ou utilisez textContent au lieu de innerHTML.

6. Absence de limitation de débit (Rate Limiting) J'avais des endpoints qui appelaient des modèles d'IA coûteux sans aucune limite. Un seul utilisateur pouvait générer une facture massive en quelques minutes.

• Correction : L'authentification empêche les utilisateurs non autorisés d'accéder au système. La limitation de débit empêche les utilisateurs autorisés d'abuser de votre système. Vous avez besoin des deux.

7. Paramètres CORS trop permissifs J'utilisais allow_origins=["*"] dans mon middleware. Cela permet à n'importe quel site web d'effectuer des requêtes vers votre API.

• Correction : N'autorisez que vos domaines spécifiques en production.

8. Fuite de fichiers J'ai écrit du code qui créait des fichiers temporaires, mais qui ne parvenait pas à les supprimer si le processus plantait. Ces fichiers restent indéfiniment sur votre serveur.

• Solution : Utilisez un bloc try-finally pour garantir que les fichiers sont supprimés même si une erreur survient.

Les problèmes de sécurité sont rarement intentionnels. Ils sont le résultat de l'approche « Je corrigerai cela plus tard ». Le « plus tard » n'arrive jamais.

Intégrez la sécurité dans votre flux de travail dès le premier jour. Vérifiez votre code avant de faire un commit et avant de déployer.

Source : https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb