API_KEY=abc123<\/pre>Accédez-y ensuite dans votre code :<\/p>
const apiKey = process.env.API_KEY;<\/pre>Cela permet de ne pas stocker de secrets dans votre base de code.<\/p>
Avant chaque commit, vérifiez qu’il n’y a pas de fuite à l’aide d’outils comme git-secrets<\/strong> ou Gitleaks<\/strong>. Ces outils analysent votre code et bloquent les commits qui contiennent des données sensibles.<\/p>Stockez les identifiants sensibles dans un gestionnaire de secrets pour les systèmes de production.<\/strong> Utilisez des outils comme AWS Secrets Manager, HashiCorp Vault ou Doppler pour stocker et accéder aux secrets en toute sécurité au moment de l’exécution, au lieu de les conserver dans des fichiers locaux.<\/p>Limitez l’accès à chaque secret. <\/strong>Seuls les services ou les parties de votre système qui ont besoin d’un secret doivent pouvoir y accéder.<\/p>Renouvelez régulièrement les secrets. <\/strong>Remplacez les clés API et les mots de passe à intervalles réguliers ou immédiatement après toute suspicion de compromission.<\/p>Enfin, vérifiez qu’aucun secret n’est exposé. Envoyez le code vers un dépôt privé et vérifiez qu’aucun secret n’apparaît dans :<\/p>
\n- Historique des commits<\/li>\n\n\n\n
- Journaux<\/li>\n\n\n\n
- Messages d’erreur<\/li>\n<\/ul>
Si un secret apparaît n’importe où dans votre base de code ou vos journaux, considérez-le comme compromis et remplacez-le immédiatement.<\/p>
3. Mettez en place l’authentification et l’autorisation dès le départ<\/h3>
Configurez l’authentification et l’autorisation dès le début de votre projet.<\/p>
Ajoutez des vérifications d’authentification à toutes les routes non publiques. <\/strong>Dans votre backend, protégez les routes à l’aide d’un middleware ou de gardes (par exemple, un middleware JWT ou des vérifications de session). Chaque requête doit vérifier que l’utilisateur est connecté avant de renvoyer des données.<\/p>Testez cela en ouvrant les routes dans une fenêtre de navigation privée ou en utilisant un outil comme Postman<\/strong> sans vous connecter. La requête doit renvoyer une erreur telle que 401 Unauthorized<\/strong>.<\/p>Ensuite, appliquez l’autorisation à chaque requête.<\/strong> Après avoir confirmé que l’utilisateur est connecté, vérifiez à quoi il est autorisé à accéder. Dans votre logique back-end, comparez l’identifiant de l’utilisateur authentifié avec celui du propriétaire de la ressource.<\/p>Par exemple, lorsque vous traitez une requête comme \/orders\/123<\/strong>, récupérez la commande et vérifiez :<\/p>if (order.userId !== currentUser.id) {\n return res.status(403).send(\"Forbidden\");\n}<\/pre>Testez cela en vous connectant avec un compte utilisateur, puis en essayant d’accéder aux données d’un autre utilisateur en modifiant les ID dans l’URL ou la requête API. Le système doit renvoyer 403 Forbidden<\/strong>.<\/p>Ne faites pas confiance aux ID fournis par le client. <\/strong>Validez-les toujours sur le serveur. Même si le frontend masque certaines données, partez du principe que les utilisateurs peuvent modifier les requêtes manuellement.<\/p>Appliquez la même logique de contrôle d’accès dans toute l’application. <\/strong>Utilisez des middlewares, des helpers ou des politiques partagés au lieu d’écrire des vérifications personnalisées pour chaque endpoint. Cela évite les failles où certaines routes restent non protégées.<\/p>Testez directement les scénarios non autorisés. <\/strong>Utilisez des outils comme Postman ou les outils de développement du navigateur pour :<\/p>\n- Supprimer les jetons d’authentification<\/li>\n\n\n\n
- Modifier le corps des requêtes<\/li>\n\n\n\n
- Relancez les requêtes avec des données utilisateur différentes<\/li>\n<\/ul>
Toute requête non autorisée doit être bloquée.<\/p>
Enfin, veillez à inclure des vérifications d’authentification et d’autorisation lors du développement de chaque nouvelle fonctionnalité. <\/strong>Ne les ajoutez pas plus tard. Lorsque vous créez un nouvel endpoint, commencez par ajouter la protection, puis implémentez la logique de la fonctionnalité.<\/p>4. Validez et assainissez les entrées utilisateur<\/h3>
Traitez toutes les entrées utilisateur comme non fiables et validez-les avant de les utiliser où que ce soit dans votre système.<\/p>
Commencez par ajouter des règles de validation dans votre backend. <\/strong>Utilisez une bibliothèque de validation comme Joi<\/strong>, Zod<\/strong> ou les validateurs intégrés du framework pour définir ce que chaque champ doit accepter.<\/p>Par exemple :<\/p>
const schema = z.object({\n email: z.string().email(),\n age: z.number().int().min(0)\n});<\/pre>Exécutez cette validation avant de traiter la demande. Si l’entrée ne correspond pas au schéma, renvoyez une erreur et arrêtez l’exécution :<\/p>
if (!schema.safeParse(req.body).success) {\n return res.status(400).send(\"Invalid input\");\n}<\/pre>N’essayez pas de corriger une entrée invalide. Rejetez-la et demandez à l’utilisateur d’envoyer des données correctes.<\/p>
Ensuite, assainissez les données avant de les utiliser dans des requêtes ou de les afficher sur une page. Utilisez des protections intégrées, comme des moteurs de templates qui échappent le HTML par défaut, ainsi que des bibliothèques comme DOMPurify pour le contenu généré par les utilisateurs.<\/p>
Pour les requêtes de base de données, utilisez toujours des requêtes paramétrées plutôt que la concaténation de chaînes de caractères :<\/p>
\/\/ safe\ndb.query(\"SELECT * FROM users WHERE email = ?\", [email]);\n\n\/\/ unsafe\ndb.query(`SELECT * FROM users WHERE email = '${email}'`);<\/pre>Testez directement la gestion de vos entrées. Essayez :<\/p>
\n- Saisir des scripts comme <script>alert(1)<\/script><\/strong><\/li>\n\n\n\n
- Soumettre des chaînes longues ou inattendues<\/li>\n\n\n\n
- Envoyer des formats non valides via des outils d’API comme Postman<\/li>\n<\/ul>
Le système doit rejeter l’entrée ou l’échapper de manière sécurisée. Il ne doit jamais exécuter de code ni renvoyer de données inattendues.<\/p>
Si votre application permet de téléverser des fichiers, limitez les types et la taille des fichiers côté serveur. Ne vous fiez pas aux vérifications côté client.<\/p>
Enfin, appliquez les mêmes règles de validation et d’assainissement à chaque source d’entrée. <\/strong>Cela inclut les formulaires, les requêtes API, les paramètres d’URL et les téléversements de fichiers. Ne partez pas du principe qu’une entrée est sûre simplement parce qu’elle provient de votre interface front-end.<\/p>5. Surveillez les dépendances en continu<\/h3>
Recensez chaque dépendance de votre projet et vérifiez régulièrement si elle présente des vulnérabilités connues.<\/p>
Commencez par exécuter une analyse des dépendances en local. <\/strong>Utilisez des outils intégrés comme :<\/p>npm audit<\/pre>ou<\/p>
pip-audit<\/pre>Cela affiche les vulnérabilités connues dans vos dépendances actuelles.<\/p>
Ensuite, automatisez cela dans votre flux de travail. <\/strong>Ajoutez un scanner de dépendances comme Dependabot<\/strong>, Snyk<\/strong> ou Aikido<\/strong> à votre dépôt. Par exemple, activez Dependabot dans GitHub afin qu’il analyse automatiquement vos dépendances et ouvre des pull requests avec des correctifs de sécurité.<\/p>Cela évite de devoir effectuer la vérification manuellement.<\/p>
Avant d’installer un package, vérifiez-le manuellement :<\/p>
\n- Recherchez le nom du package sur npm ou PyPI<\/li>\n\n\n\n
- Vérifiez la date de la dernière mise à jour<\/li>\n\n\n\n
- Vérifiez le nombre de téléchargements ou d’étoiles sur GitHub<\/li>\n<\/ul>
Si le paquet ne présente aucune activité ou semble suspect, ne l’installez pas.<\/p>
Verrouillez les versions de vos dépendances pour éviter les changements inattendus. Utilisez des fichiers de verrouillage comme :<\/p>
\n- package-lock.json<\/li>\n\n\n\n
- yarn.lock<\/li>\n\n\n\n
- requirements.txt<\/li>\n<\/ul>
Évitez les versions trop approximatives comme :<\/p>
\"library\": \"^1.0.0\"<\/pre>Utilisez plutôt des versions fixes :<\/p>
\"library\": \"1.0.0\"<\/pre>Mettez régulièrement à jour les dépendances. Lorsqu’un outil signale une vulnérabilité :<\/p>
\n- Exécutez la mise à jour (npm update<\/strong> ou une commande similaire)<\/li>\n\n\n\n
- Vérifiez ce qui a changé<\/li>\n\n\n\n
- Testez la fonctionnalité concernée<\/li>\n<\/ol>
Ne retardez pas les mises à jour, car les vulnérabilités connues sont activement exploitées.<\/p>
Supprimez les dépendances inutilisées en vérifiant les fichiers de votre projet. Si un package n’est importé ni utilisé nulle part, supprimez-le et exécutez :<\/p>
npm uninstall package-name<\/pre>Cela réduit les risques inutiles.<\/p>
Après chaque mise à jour, testez la fonctionnalité qui dépend de ce package. Par exemple :<\/p>
![\"Schéma](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/46\/2026\/06\/Entree-non-securisee.jpg\/w=1024,h=1024,fit=scale-down\")
<\/figure>\n<\/div>![\"Schéma](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/46\/2026\/06\/Impact-systeme.jpg\/w=1024,h=1024,fit=scale-down\")