Sommaire
En résumé : Corriger une faille de sécurité en production coûte jusqu’à 30 fois plus cher qu’en phase de conception (source : IBM/NIST).
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.
Coût de correction d’une faille selon le moment de détection :
| Phase | Coût relatif | Impact |
|---|---|---|
| Conception | 1x | Facile à corriger, on change le plan |
| Développement | 6x | Il faut modifier le code et vérifier qu’il n’y a pas de régression |
| Tests | 15x | Retards de livraison, il faut corriger le code et refaire les tests |
| Production | 30x | Urgence, stress, perte de données possible, impact sur les clients |
Le problème : la sécurité arrive toujours trop tard
La majorité des entreprises qui développent une 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.
La bonne pratique : ne stockez jamais de secrets dans le code source. Utilisez un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager ou équivalent).
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. Ils détectent les erreurs les plus évidentes mais ne trouvent pas les failles de logique métier ni les problèmes d’architecture, d’où l’importance 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. Aucun outil automatisé ne détecte ce type de faille.
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 cybersécurité couvre l’ensemble de ces étapes, de la conception au pentest final.
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 cybersécurité ou contactez-nous pour en discuter.
