Conscience de sécurité de base
Les cinq règles non négociables que chaque ingénieur doit suivre
⏱ Estim. ~5 min
01 · Lire
Tu n'as pas besoin d'être un expert en sécurité. Mais tu dois absolument éviter les erreurs qui causent la majorité des incidents de sécurité.
La vérité, c'est que la plupart des incidents de sécurité ne sont pas causés par des hackers sophistiqués. Ils sont causés par des ingénieurs qui oublient les bases : mots de passe laissés dans le code source, entrée utilisateur non validée, endpoints HTTP au lieu de HTTPS.
Ces cinq règles te tiennent hors des ennuis. Elles ne sont pas optionnelles — c'est le minimum pour écrire du code en qui les autres peuvent avoir confiance.
02 · Lire
Mémorise ces cinq règles. Elles couvrent la majorité des erreurs de sécurité des ingénieurs juniors.
Points clés
- Ne jamais commiter de secrets : clés API, mots de passe, tokens → .env + .gitignore
- Ne jamais faire confiance à l'entrée utilisateur : sanitize tout ce qui vient d'un formulaire ou d'une URL avant utilisation
- Toujours HTTPS : rien de sérieux ne tourne en HTTP — les données en transit doivent être chiffrées
- Garde les dépendances à jour : lance npm audit régulièrement pour trouver les vulnérabilités connues
- Ne logge pas de données sensibles : jamais console.log(password) ou tokens dans les logs de production
03 · Lire
Tu viens de recevoir une app à auditer avant la mise en production. Voyons combien de violations de sécurité tu peux trouver avec cat et grep.
04 · Pratique terminal
Lis d'abord le code source complet. Cherche tout ce qui viole les cinq règles de sécurité que tu viens d'apprendre.
(Cette section est interactive — active JavaScript pour l'utiliser.)
05 · Pratique terminal
Maintenant utilise grep pour trouver toutes les violations potentielles de sécurité d'un coup — tout ce qui ressemble à un mot de passe, un secret ou une clé.
(Cette section est interactive — active JavaScript pour l'utiliser.)
06 · Exemple de code
Voici à quoi ressemble la version corrigée. Compare avec ce que tu as vu — chaque violation de sécurité est traitée.
app.js — problèmes de sécurité corrigés
require('dotenv').config();
const express = require('express');
const app = express();
// Secrets from .env, not hardcoded
const API_SECRET = process.env.API_SECRET;
app.post('/login', (req, res) => {
// POST body, not URL query string
const { username, password } = req.body;
console.log('Login attempt:', username);
// No password logged! Compare with hashed version in DB
});
app.listen(process.env.PORT || 3000, () => {
console.log('Server running');
// No secrets logged!
});
Les correctifs : (1) les secrets déplacés vers .env via dotenv, (2) le login utilise POST (body) au lieu de GET (URL), (3) seul le username est loggé — jamais le mot de passe, (4) plus de comparaison de mot de passe en dur — utilise un vrai système d'auth avec mots de passe hashés, (5) le log de démarrage ne laisse pas fuiter de secret.
07 · Quiz
Lequel de ces éléments ne devrait jamais être commité dans git ?
- package.json
- Un fichier .env avec des clés API
- index.html
- README.md
08 · Compléter
Pour vérifier les vulnérabilités connues dans les dépendances de ton projet, lance npm _____.
Autres leçons de ce chapitre
⚠ L'expérience interactive complète nécessite JavaScript. Active-le et recharge la page.
※ Ce site est un projet éducatif indépendant — pas un produit officiel d'Anthropic. Claude™ est une marque déposée d'Anthropic, PBC.