Sécurité de l'application
À l'issue de cette leçon, le stagiaire applique les fondamentaux de sécurité d'une application moderne : variables d'environnement, secrets en production, principes d'authentification, conformité RGPD. Cette leçon est obligatoire avant tout projet exposé à internet.
Variables d'environnement et fichier .env
Une application moderne distingue deux types de configuration : ce qui est spécifique au déploiement (URL de base de données, clés d'API, mots de passe de service) et ce qui est commun à tous les déploiements (logique métier, structure de page, comportements).
La configuration spécifique vit dans des variables d'environnement, généralement chargées au démarrage depuis un fichier .env. Ce fichier ne doit jamais être versionné dans Git. La règle est simple et non négociable.
# .env (NE PAS versionner) SUPABASE_URL=https://exemple.supabase.co SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs... # .gitignore .env node_modules/ dist/ .DS_Store # .env.example (versionné, sans valeurs réelles) SUPABASE_URL=https://votreprojet.supabase.co SUPABASE_ANON_KEY=votre-cle-anon-ici
Le mécanisme : le fichier .env contient des paires CLE=valeur que l'application lit. Un fichier .gitignore liste .env pour empêcher Git de le suivre. Et un fichier .env.example est versionné — il contient les noms des variables sans les valeurs, pour que vos collaborateurs sachent ce qu'ils doivent configurer chez eux.
Secrets en production
En développement local, les secrets vivent dans le .env sur votre machine. En production, ils doivent vivre dans le système de secrets de votre plateforme d'hébergement.
Vercel Environment Variables, Supabase secrets, AWS Secrets Manager, GitHub Actions secrets, Cloudflare Pages env vars. Le bon outil dépend du contexte — le principe est le même : ces systèmes chiffrent les secrets au repos et n'exposent les valeurs qu'au moment de l'exécution.
Ne stockez jamais un secret dans le code source. Même temporairement. Même « le temps de tester ». Un secret poussé sur GitHub, même dans un dépôt privé, doit être considéré comme compromis et révoqué immédiatement. Les bots qui scannent les commits publics sont rapides — quelques minutes.
Authentification — trois principes
Pour une application qui sert des utilisateurs, l'authentification est l'angle mort le plus dangereux. Trois principes pour ne pas se rater :
1. Bibliothèque éprouvée
N'écrivez pas votre propre système de hachage de mot de passe. N'écrivez pas votre propre logique de session. Supabase Auth, Auth.js, Clerk, Firebase Auth — choisissez selon votre stack et restez sur des solutions maintenues.
2. HTTPS partout
Y compris en local pour les tests. Vercel et la plupart des hébergeurs gèrent automatiquement les certificats. Ne servez jamais une application en HTTP brut au-delà de votre machine.
3. Validation côté serveur
Tout ce qui arrive du client est suspect. Validez les entrées. Autorisez les actions à chaque requête. Ne faites pas confiance à un état envoyé par le navigateur. Ne supposez jamais qu'un utilisateur ne peut pas modifier son propre rôle dans une requête.
Conformité RGPD — trois obligations structurantes
Si votre application traite des données personnelles d'utilisateurs européens — et vous avez de fortes chances d'en être là — le RGPD s'applique. Trois obligations qui structurent les premières heures de développement :
Minimisation des données
Ne collectez que ce qui est strictement nécessaire à votre service. Pas de « on prend tout au cas où ». Si vous n'avez pas besoin de la date de naissance, ne la demandez pas. Chaque champ collecté doit avoir une justification.
Information et consentement
Politique de confidentialité claire et accessible. Consentement explicite pour les cookies non essentiels et pour les traitements optionnels (marketing, statistiques détaillées, transferts à des tiers).
Droits d'accès et de suppression
Mécanisme par lequel un utilisateur peut consulter ses données et demander leur suppression. Pas forcément automatisé d'emblée — un mail d'export traité à la main est acceptable au début. Mais documenté et opérationnel.
Les données de stagiaires — identité, parcours, évaluations — sont des données personnelles à part entière. Documentez vos traitements dans un registre, même léger. La CNIL fournit des modèles gratuits.
Sécuriser un projet — procédure en 3 étapes
Vérifier que
.envn'est pas suivi par Git. Dans le terminal du projet :git status. La commande ne doit pas mentionner.env. Si elle le mentionne, c'est que Git le suit déjà — souvent parce qu'il a été versionné par erreur avant d'être ajouté au.gitignore.Retirer
.envdu suivi Git si nécessaire. La commande :git rm --cached .env. Puisgit commit -m "chore: untrack .env". C'est rattrapable, mais uniquement avant que le commit ne parte sur un dépôt public.Demander à Claude un audit final. Dans le panneau Claude de VS Code : « Examine ce projet et liste les fichiers ou patterns qui pourraient exposer des secrets ou des données sensibles ». Claude trouve souvent des choses qu'un humain rate — un fichier de config oublié, une clé en dur dans un fichier de test, un commentaire qui contient un identifiant.
Check-list sécurité sur votre projet
Sur le projet en cours, faites passer la check-list complète : (1) .env dans .gitignore ? (2) Secrets en production configurés sur la plateforme ? (3) Authentification par bibliothèque éprouvée ? (4) HTTPS partout ? (5) Validation côté serveur en place ? (6) Registre RGPD léger documenté ? Notez les points conformes et les chantiers restants. Cette check-list est à reprendre à chaque nouveau projet, même si elle paraît répétitive.
Cet exercice est à conserver dans votre dossier de stagiaire. Il n'est pas évalué mais il est tracé.
- cnil.fr autorité française de protection des données, modèles de registre RGPD
- owasp.org — Top 10 référentiel des dix risques de sécurité web les plus critiques
- docs.github.com — Secret scanning scan automatique des secrets sur GitHub
Vous appliquez la check-list sécurité (env, secrets, auth, HTTPS, validation, RGPD) sur votre projet en cours ?