La question qu'on me pose le plus souvent quand j'anime une revue de code, ce n'est pas « comment on fait un audit ? ». C'est : « par où on commence ? ». Et c'est exactement le problème. La plupart des équipes que j'ai croisées savent qu'il faut « sécuriser », mais personne ne sait dire à quel moment du cycle de développement ça se joue vraiment.
J'ai vu une startup se faire vider sa base clients un vendredi soir à 23 h. Pas une attaque sophistiquée. Un endpoint d'API sans authentification, oublié dans une feature sortie en urgence. La correction a pris vingt minutes. Le nettoyage, trois semaines. Voilà ce que coûte une bonne pratique oubliée.
Les meilleures pratiques de sécurité pour le développement d'application web ne sont pas une liste à cocher en fin de projet. Ce sont des décisions prises à chaque étape, souvent invisibles, dont la valeur ne se mesure qu'au moment où quelqu'un essaie de casser votre travail.
Points clés à retenir
- La sécurité se conçoit par phase du cycle de développement, pas en une passe finale
- L'OWASP Top 10 reste la base, mais l'utiliser comme checklist est une erreur fréquente
- L'analyse automatisée (SAST, DAST, SCA) attrape les erreurs connues ; elle ne remplace pas la réflexion de conception
- Un secret versionné dans Git est un secret compromis, même s'il est supprimé ensuite
- Le RGPD et les recommandations de l'ANSSI imposent une traçabilité qu'on néglige souvent
- La majorité des failles exploitées viennent de détails basiques, pas de scénarios hollywoodiens
Pourquoi la checklist de sécurité ne fonctionne pas
J'ai longtemps cru qu'un bon audit suffisait. Un pentest avant la mise en production, un rapport, des tickets à corriger. Propre sur le papier. Sauf qu'à chaque fois, le même schéma revenait : l'équipe corrigeait les dix points du rapport, puis cassait autre chose deux semaines plus tard en ajoutant une feature.
Le problème n'est pas le pentest. Le problème, c'est de traiter la sécurité comme un événement au lieu d'un réflexe.
OWASP, c'est quoi exactement ?
OWSAP désigne l'Open Worldwide Application Security Project, une fondation à but non lucratif qui publie des ressources ouvertes sur la sécurité applicative. Dans le milieu, on la connaît surtout pour son Top 10, un classement des catégories de risques les plus critiques.
Ce n'est ni une norme, ni une certification, ni un label. Personne ne « passe » OWASP. C'est un référentiel vivant, mis à jour tous les quelques années selon les attaques réellement observées. Le lire une fois ne suffit pas : sa valeur vient de la façon dont vous l'intégrez dans vos décisions quotidiennes.
L'erreur que 90 % des équipes commettent avec le Top 10
Elles le lisent comme une liste de courses. Injection SQL ? Coché, on utilise un ORM. Contrôle d'accès défaillant ? Coché, on a des rôles. Sauf que le Top 10 décrit des catégories de risques, pas des vulnérabilités atomiques. « Contrôle d'accès défaillant » couvre des dizaines de scénarios différents, du simple IDOR à l'escalade de privilèges horizontale.
Traiter une catégorie comme un item validé une fois pour toutes, c'est se rassurer sans se protéger.
Un workflow de sécurisation par phase de développement
Voici comment j'organise les choses aujourd'hui sur les projets que je suis. Ça n'a rien de révolutionnaire, mais c'est ce qui tient dans le temps.
Conception et exigences : là où tout se joue
C'est la phase qu'on sacrifie le plus souvent, et c'est une erreur coûteuse. Trois questions à poser avant d'écrire la première ligne :
- Quelles données cette fonctionnalité manipule-t-elle ? Si la réponse contient « données personnelles » ou « identifiants », le niveau d'exigence monte d'un cran
- Qui doit pouvoir y accéder, et surtout qui ne doit pas pouvoir ?
- Que se passe-t-il si quelqu'un envoie volontairement des données malformées ?
Sur un projet de gestion RH, cette dernière question a évité une fuite potentielle : un endpoint d'export CSV acceptait un paramètre de tri non filtré, ce qui permettait d'extraire l'intégralité de la table salaires. Détecté en trente minutes lors d'une revue de conception, corrigé avant le moindre commit.
Développement : les réflexes non négociables
La validation des entrées côté serveur, toujours. Jamais uniquement côté client, qui n'est qu'une commodité d'interface. Ce n'est pas une opinion, c'est la base — et pourtant c'est encore la cause de la majorité des injections que je rencontre.
Sur la gestion de session : cookies avec les attributs HttpOnly, Secure et SameSite, expiration côté serveur, régénération de l'identifiant après authentification. Des détails. Des détails qui font la différence entre une session volée et une session protégée.
Et puis il y a les en-têtes HTTP, souvent ignorés. CSP pour limiter les sources de scripts, HSTS pour forcer le HTTPS, X-Content-Type-Options pour empêcher le reniflage de type MIME. Trois lignes de configuration, un paquet d'attaques en moins.
La gestion des secrets, ce cauchemar silencieux
J'ai déjà trouvé une clé d'API AWS en clair dans un dépôt public. Le commit datait de huit mois. La clé était toujours active. Coût estimé de l'exposition : plusieurs milliers d'euros de ressources détournées avant détection par la facturation.
Un secret versionné est un secret compromis. Le supprimer du dernier commit ne le retire pas de l'historique Git. Les bonnes pratiques tiennent en quelques points :
- Variables d'environnement ou coffre-fort de secrets (Vault, gestionnaire natif du cloud)
- Rotation automatique des identifiants sensibles
- Détection automatisée dans la CI qui bloque tout commit contenant un motif de clé connu
- Jamais de secret dans un fichier de configuration par défaut, même pour du test local
Enfin des outils qui font le travail à votre place
L'analyse automatisée ne remplace pas la réflexion, mais elle attrape ce que l'œil humain laisse passer à 18 h un vendredi.
| Type d'outil | Ce qu'il analyse | Quand l'utiliser |
|---|---|---|
| SAST | Le code source, à la recherche de motifs vulnérables | À chaque commit, en CI |
| DAST | L'application en fonctionnement, comme un attaquant | Sur environnement de test à chaque déploiement |
| SCA | Les dépendances et leurs vulnérabilités connues | En continu, c'est là que les alertes arrivent le plus vite |
| Analyse de secrets | L'historique Git et les fichiers | Avant chaque push, en pre-commit hook |
Sur un projet e-commerce, la mise en place d'un SCA (analyse des dépendances) a révélé onze bibliothèques obsolètes avec des vulnérabilités critiques connues, dont une utilisée pour la gestion des paiements. Aucune n'était surveillée manuellement. Le coût de la mise à jour : deux jours. Le coût potentiel d'une exploitation : sans commune mesure.
Quelques noms qui reviennent
Pour le DAST, OWASP ZAP reste la référence open source, intégrable dans un pipeline. Il détecte les erreurs classiques : injections, mauvaises configurations, exposition d'informations. Ce n'est pas un scanner miracle : il produit des faux positifs, et il ne comprend pas votre logique métier. Un endpoint qui renvoie les données de tous les utilisateurs parce que vous avez oublié un filtre WHERE user_id ne sera pas toujours détecté.
Complétez toujours le scan automatique par une revue humaine ciblée sur les flux d'autorisation.
Existe-t-il une certification OWASP ?
Non, l'OWASP ne délivre pas de certification individuelle. Ce qui existe, ce sont des formations et des programmes dispensés par des organismes tiers qui s'appuient sur les ressources OWASP, notamment autour du projet OWASP SAMM pour la maturité ou du OWASP ASVS pour la vérification. Si vous cherchez un cadre de référence pour structurer vos exigences, ASVS est bien plus exploitable qu'une simple lecture du Top 10 : il liste des exigences vérifiables, classées par niveau de criticité.
Ce que le RGPD et l'ANSSI changent concrètement
Beaucoup d'équipes techniques pensent que la conformité, c'est le problème du juriste. C'est faux, et ça se paie.
Le RGPD impose deux choses qui touchent directement le développement : la minimisation des données (ne collectez que ce dont vous avez besoin) et la traçabilité des accès aux données personnelles. Concrètement, ça veut dire des logs d'accès, une politique de rétention, et la capacité de supprimer réellement les données d'un utilisateur sur demande. Pas un flag « supprimé » dans la base — une suppression effective.
L'ANSSI, de son côté, publie des guides sectoriels et des recommandations sur les architectures. Ce ne sont pas des obligations légales, mais s'en écarter sans raison documentée devient difficile à justifier face à un client du secteur public ou de la santé.
Anonymiser n'est pas pseudonymiser
Distinction que j'ai vue mal comprise plus d'une fois. Pseudonymiser, c'est remplacer une donnée identifiante par un identifiant — la personne reste réidentifiable si vous conservez la table de correspondance. Anonymiser, c'est rendre la réidentification impossible en pratique. Si votre table de correspondance traîne dans le même schéma de base, vous n'avez pas anonymisé quoi que ce soit.
La sécurité des API, le parent pauvre
Les interfaces web ont longtemps concentré l'attention. Aujourd'hui, la majorité des données circulent par API, et c'est là que les contrôles se relâchent.
Trois règles qui ne devraient jamais être négociées. D'abord, l'authentification systématique : aucun endpoint ne devrait être public sans décision explicite documentée. Ensuite, la limitation de débit, pour empêcher l'énumération d'identifiants et les attaques par force brute. Enfin, la validation stricte du format des données échangées, schéma à l'appui — une API qui accepte n'importe quoi est une porte ouverte.
J'ai vu une API de facturation répondre correctement à une requête sur la facture d'un autre client. Pas de bug de sécurité complexe : une vérification d'autorisation oubliée dans une seule branche du code. Vingt lignes de tests auraient suffi à la détecter.
La sécurité après la mise en production
C'est là que le travail réel commence, et c'est là que les équipes décrochent. Une application mise en production n'est pas un objet fini. Chaque dépendance évolue, chaque nouvelle feature rouvre des surfaces qu'on croyait fermées.
Ce que je maintiens désormais sur chaque projet : une revue trimestrielle des dépendances, un scan automatique à chaque déploiement, et surtout un journal de décisions de sécurité. Pourquoi tel endpoint est public, pourquoi telle donnée est conservée six mois. Écrit, daté, relu.
Ce journal a une valeur inattendue : quand un nouveau développeur rejoint l'équipe, il ne casse plus par ignorance ce qui avait été décidé en connaissance de cause.
La sécurité d'une application web ne se joue pas lors d'un audit annuel. Elle se joue à chaque fois qu'un développeur se demande « est-ce que je devrais vérifier ça ? » et décide de vérifier. Le reste, les outils, les référentiels, les certifications, ce n'est que du confort autour de cette décision-là. Si vous ne deviez retenir qu'une chose de tout ce qui précède : la question n'est jamais « est-ce que c'est sécurisé ? », mais « qu'est-ce qui se passe si quelqu'un essaie de me prouver le contraire ? ». Posez-la tôt, posez-la souvent, et acceptez que la réponse change à chaque commit.
