La sécurité pour vibecoders : protège tes comptes, tes clés API et tes users (Claude Code & Codex)

Cette vidéo aborde la sécurité des applications et des comptes, un sujet crucial pour les développeurs utilisant des outils comme Cloud ou Codex. L'objectif est de prévenir les piratages qui peuvent avoir des conséquences dramatiques, allant de la perte de données à la responsabilité légale. La première ligne de défense est un bon mot de passe. Un mot de passe fort n'est pas simplement complexe, mais long. Une phrase de passe de quatre à cinq mots aléatoires est plus robuste et facile à retenir qu'une combinaison courte de caractères spéciaux. Cependant, l'erreur la plus fréquente est de réutiliser le même mot de passe partout. Pour y remédier, l'utilisation d'un gestionnaire de mots de passe est indispensable. Il génère et stocke des mots de passe uniques pour chaque site, ne nécessitant de l'utilisateur que de se souvenir d'un seul mot de passe maître. Des gestionnaires comme Bitwarden, One Password ou Proton Pass sont recommandés, en évitant de stocker les mots de passe en clair dans un fichier texte. La double authentification (2FA) est une autre couche de sécurité essentielle. Elle ajoute une deuxième preuve de connexion, rendant un compte inaccessible même si un pirate obtient le mot de passe. Le 2FA devrait être activé en priorité sur la boîte mail principale, GitHub, le gestionnaire de mots de passe et les comptes bancaires. Il existe différentes formes de 2FA, dont certaines sont plus sûres que d'autres. Le 2FA par SMS est la forme la plus faible car les numéros de téléphone peuvent être volés via des techniques comme le "Sim swapping". Cela permet aux pirates de réinitialiser tous les mots de passe associés à ce numéro. Les applications d'authentification comme Google Authenticator ou Authy sont une meilleure option. Elles génèrent des codes à six chiffres qui changent toutes les 30 secondes, hors ligne, évitant ainsi le transit par SMS. La meilleure solution, bien que payante, est l'utilisation de clés physiques (clés USB) qui nécessitent une interaction physique pour autoriser la connexion. Si une clé physique n'est pas envisageable, les applications d'authentification sont un bon compromis. Il est crucial de sauvegarder les codes de récupération fournis lors de l'activation du 2FA, car ils permettent de retrouver l'accès aux comptes en cas de perte du téléphone ou de la clé physique. Ces codes ne doivent pas être stockés sur l'ordinateur ni à un endroit facilement accessible en cas de cambriolage. La deuxième partie de la sécurité concerne le code lui-même. La fuite de secrets dans le code est une erreur fréquente et coûteuse. Un secret est toute information donnant un accès ou un pouvoir, comme les clés API (Stripe, OpenAI), les tokens GitHub, les identifiants de base de données ou les clés privées SSH. Les informations publiques (URL de site, clés publiques) ne sont pas des secrets. En cas de doute, il faut traiter l'information comme un secret. Les secrets ne doivent jamais être écrits en dur dans le code. Ils doivent être stockés dans un fichier `.env` local, sous forme de paires clé-valeur. En production, ces variables d'environnement sont recopiées dans le tableau de bord du service de déploiement (par exemple, Vercel). Il est impératif de ne jamais committer le fichier `.env` sur GitHub. Pour cela, il faut l'ajouter au fichier `.gitignore`. Un fichier `.env.example` peut être commit sur GitHub, mais il ne doit contenir que les noms des variables, sans leurs valeurs. Si un fichier `.env` est committé par erreur, la suppression du fichier ne suffit pas, car il reste dans l'historique des commits. La priorité est de révoquer immédiatement les clés exposées et d'en générer de nouvelles. Pour les outils comme Cloud ou Codex qui lisent le code du projet, il est important de leur interdire l'accès au fichier `.env` pour éviter que des secrets ne se retrouvent dans leur contexte. Cela se fait en ajoutant une règle `deny` dans le fichier `.cloudsettings.json`. Il est aussi crucial de ne jamais coller une vraie clé API dans le chat d'une IA comme Cloud ou OpenAI, mais plutôt de faire référence à la variable d'environnement qui la contient. Lors de la création de secrets ou de privilèges, il est recommandé d'accorder le minimum de pouvoir et une durée de vie limitée. Par exemple, les tokens GitHub devraient être limités à un seul dépôt, avec des droits en lecture seule et une date d'expiration. Il est également essentiel de relire le code généré par l'IA, car l'utilisateur reste responsable de ce qui est mis en ligne. Une fois l'application en ligne, il faut savoir que tout ce qui part dans le navigateur est public. Les clés API secrètes ne doivent jamais être incluses directement dans le code côté front-end. Le navigateur est la vitrine, le serveur est l'arrière-boutique sécurisée. Les secrets doivent vivre dans l'arrière-boutique. Pour Next.js, les variables préfixées par `NEXT_PUBLIC` sont injectées dans le bundle du navigateur et deviennent publiques. Ce préfixe est réservé aux valeurs volontairement publiques, comme une clé publishable Stripe. En cas de doute, il ne faut pas utiliser `NEXT_PUBLIC`. Pour appeler une API payante avec une clé secrète, il faut passer par une route API sur le serveur. Le navigateur appelle cette route, qui ajoute la clé secrète (stockée côté serveur sans `NEXT_PUBLIC`) avant d'appeler l'API externe et de renvoyer la réponse au navigateur. Ainsi, la clé secrète ne quitte jamais le serveur. Il ne faut jamais faire confiance au client (navigateur ou utilisateur). Toutes les données provenant d'un navigateur peuvent être truquées. Les vérifications côté client visent le confort de l'utilisateur (empêcher les comportements "stupides"), tandis que les vérifications côté serveur sont cruciales pour empêcher les comportements "malicieux". Le serveur doit recontrôler toutes les données (identité, droits, valeurs) avant d'agir. Des failles de sécurité connues, comme le XSS (Cross-Site Scripting), rappellent qu'il faut toujours se méfier de ce que l'utilisateur soumet dans un formulaire, car il pourrait injecter du code malveillant. Concernant l'authentification des utilisateurs, il est fortement recommandé de ne pas réinventer la roue et d'utiliser des systèmes existants et éprouvés comme NextAuth.js, Clerk, Supabase Auth ou Firebase Auth. Lors du stockage des mots de passe, il ne faut jamais les stocker en clair, mais plutôt leur *hash* (empreinte irréversible) généré avec des algorithmes comme Bcrypt ou Argon2. Pour éviter les attaques par force brute, il faut limiter le nombre de tentatives de connexion sur la page d'authentification. L'utilisation du protocole HTTPS est obligatoire, car il chiffre toutes les communications, y compris les mots de passe, contrairement au HTTP où tout peut être lu sur un réseau public. Enfin, il est conseillé d'activer les outils de protection de GitHub, qui détectent les clés exposées dans le code et les failles de sécurité dans les dépendances. Pour se prémunir des attaques de la chaîne d'approvisionnement (supply chain attacks), l'utilisation de PNPM pour gérer les dépendances est préférable à NPM, car il offre une meilleure protection contre ce type d'attaques. En résumé, les points clés sont: mots de passe longs et uniques avec un gestionnaire, 2FA (clés physiques ou apps d'authentification), ne jamais exposer les secrets dans le code (utiliser `.env` et `.gitignore`), ne jamais faire confiance au client, utiliser des systèmes d'authentification existants, stocker les *hashes* des mots de passe, limiter les tentatives de connexion et utiliser HTTPS.