Sommaire
En résumé : Corriger une faille après la mise en production peut nécessiter des reprises importantes et affecter les utilisateurs.
Si vous lancez une application web ou mobile, intégrer la sécurité dès le départ est le meilleur investissement que vous puissiez faire : exigences de sécurité dans le cahier des charges, framework bien configuré, secrets hors du code, vérifications automatisées et test d’intrusion avant la mise en production.
Travaux à prévoir selon le moment où une faille est détectée :
| Phase | Travaux à prévoir | Impact |
|---|---|---|
| Conception | Adapter la conception | Facile à corriger, on change le plan |
| Développement | Reprendre le code | Il faut modifier le code et vérifier qu’il n’y a pas de régression |
| Tests | Corriger et tester à nouveau | Retards de livraison, il faut corriger le code et refaire les tests |
| Production | Corriger et redéployer | Urgence, stress, perte de données possible, impact sur les clients |
Le risque d’une sécurité traitée trop tard
Certains projets d’application web ou mobile traitent la sécurité comme une étape finale, un audit réalisé juste avant la mise en ligne.
À ce stade, les choix d’architecture sont figés donc si l’audit révèle un problème de fond, deux options : repousser le lancement (coûteux) ou accepter le risque (dangereux).
Le Security by Design, c’est simplement l’idée de penser à la sécurité dès le départ plutôt que de tenter de la greffer à la fin. L’ANSSI formalise cette approche dans son guide Agilité et sécurité numériques. Comme pour un bâtiment : il vaut mieux prévoir des murs solides sur le plan que de renforcer des murs fragiles après construction.
5 actions concrètes pour sécuriser votre projet dès le départ
1. Définir les exigences de sécurité dans le cahier des charges
Avant d’écrire la moindre ligne de code, posez-vous ces questions :
- Quelles données sensibles allez-vous manipuler ? (données personnelles, paiements, données de santé…)
- Qui doit avoir accès à quoi ? (principe du moindre privilège : chaque utilisateur n’accède qu’à ce dont il a besoin)
- Que se passe-t-il si le service tombe en panne ? (plan de continuité)
Ces réponses doivent figurer dans le cahier des charges, au même titre que les fonctionnalités. Un prestataire qui ne vous pose pas ces questions dès le départ est un signal d’alerte.
2. Choisir un framework moderne et le configurer correctement
Les frameworks de développement récents (Laravel, Django, Next.js…) intègrent des protections de base contre les attaques les plus courantes : injections SQL, vol de session, falsification de formulaires. Encore faut-il :
- Ne pas désactiver ces protections pour gagner du temps
- Ne pas contourner le framework en écrivant du code « à la main » là où il fournit une solution sécurisée
- Maintenir le framework à jour : les mises à jour corrigent souvent des failles de sécurité
Lors de nos tests d’intrusion web, nous vérifions systématiquement si les protections du framework sont correctement activées.
3. Ne jamais stocker de secrets dans le code source
Clés d’API, mots de passe de bases de données, certificats… Nous trouvons régulièrement ces informations en clair dans le code source lors de nos audits. Si un attaquant accède à votre code source (dépôt public, fuite, accès non autorisé), tous les secrets qui s’y trouvent sont immédiatement compromis.
Conservez vos secrets dans un gestionnaire dédié (HashiCorp Vault, AWS Secrets Manager ou équivalent) pour éviter de les stocker dans le code source.
4. Automatiser les vérifications de sécurité
Des outils peuvent être intégrés à votre pipeline de déploiement pour détecter automatiquement certaines failles. Ils ne remplacent pas une revue humaine mais constituent un premier filet de sécurité :
| Vérification | Ce que ça détecte | Outils gratuits |
|---|---|---|
| Analyse du code | Failles dans votre code | Semgrep, SonarQube |
| Scan des dépendances | Bibliothèques vulnérables | Dependabot, Snyk |
| Détection de secrets | Mots de passe dans le code | Gitleaks |
Ces outils s’exécutent automatiquement à chaque modification du code, avec une couverture qui dépend des règles, des accès et du contexte fournis. Des défauts de logique métier peuvent leur échapper, d’où l’intérêt d’un accompagnement par un expert en complément.
5. Prévoir un test d’intrusion avant la mise en production
Les outils automatisés ne détectent qu’une partie des failles. Un test d’intrusion réalisé par un expert humain permet de découvrir les failles logiques, celles qui exploitent le fonctionnement normal de l’application de manière imprévue.
Par exemple : un utilisateur qui modifie l’URL pour accéder au compte d’un autre ou qui change le prix d’un article dans la requête de paiement. Des outils peuvent aider à repérer ces situations mais leur validation demande de comprendre les droits attendus et les règles métier.
Pour en savoir plus sur la préparation, consultez notre guide : Comment se préparer à un test d’intrusion.
Le bon moment pour chaque action
| Phase du projet | Action sécurité |
|---|---|
| Cahier des charges | Définir les exigences de sécurité et les risques |
| Développement | Framework sécurisé, outils automatisés, revues de sécurité intermédiaires |
| Pré-production | Test d’intrusion avant mise en ligne |
| Production | Surveillance, mises à jour, audits réguliers |
Un accompagnement sécurité applicative permet de planifier des revues de code ciblées et des tests aux étapes clés du développement, jusqu’au pentest avant mise en production.
La sécurité n’est pas un coût supplémentaire, c’est une assurance contre des coûts bien plus élevés : perte de données, indisponibilité du service, atteinte à la réputation, sanctions RGPD.
Vous lancez une application web ou mobile et souhaitez intégrer la sécurité dès le départ ? Découvrez notre accompagnement sécurité applicative ou contactez-nous pour en discuter.
