Beaucoup d'applications mises en ligne cette année fonctionnent très bien du point de vue de l'utilisateur. Le formulaire enregistre, la page charge, le paiement passe. Rien ne signale que la même application accepte aussi des requêtes qu'elle devrait refuser, ou stocke des mots de passe lisibles par quiconque a accès au serveur. La sécurité a ce côté déroutant : elle reste invisible tant que personne ne cherche, et brutale le jour où quelqu'un cherche.
Je forme des développeurs depuis six ans, après quatorze ans passés à écrire du code en entreprise et en freelance. Quand je fais relire les projets de fin de parcours, la partie fonctionnelle tient souvent la route. La partie sécurité, elle, se résume à un mot de passe haché et un formulaire de connexion. Il y a là un angle mort de formation plus qu'un manque de sérieux : personne ne leur a montré à quoi ressemble une attaque, donc elles ne peuvent pas la voir venir.
À quoi ressemble une application non sécurisée
Vue de l'extérieur, elle ressemble à toutes les autres. La différence tient dans ce qu'elle accepte de faire quand on la sollicite d'une manière imprévue. Exemple courant : un site qui affiche les commandes via une URL du type /commande/1042. Si changer le numéro en 1043 affiche la commande d'un autre client, le site marche parfaitement et expose quand même les données de tout le monde.
Il y a une distinction utile à poser tôt. Un bug casse quelque chose que l'utilisateur voit. Une faille laisse l'application fonctionner tout en ouvrant une porte que personne n'a voulue, et passe donc la recette sans encombre puisque, du point de vue du parcours normal, tout marche. Cette absence de symptôme explique pourquoi le sujet descend en bas de la liste des priorités : on corrige ce qui casse la démo, rarement ce qui ne casse rien.
Sur les projets de reconversion, de développeurs juniors ou de petites équipes pressées, les points faibles se répètent. Des identifiants écrits en dur dans le code et poussés sur un dépôt public. Une base de données joignable depuis internet avec le mot de passe par défaut. Un formulaire qui insère directement dans la requête SQL ce que l'utilisateur a tapé. Un jeton d'API doté de tous les droits alors qu'il sert à lire trois lignes. Aucun de ces défauts n'empêche l'application de tourner. Chacun suffit à la compromettre.
Pourquoi le risque existe et grandit tout seul
Le principe de base tient en une phrase : tout ce qui entre dans ton application vient potentiellement d'un attaquant. Le contenu d'un formulaire, un paramètre d'URL, un en-tête HTTP, un fichier envoyé, un cookie. Tant que ces entrées sont traitées comme si elles étaient forcément honnêtes, l'application exécute ce qu'on lui demande, y compris ce qu'aucun utilisateur légitime ne demanderait jamais.
Un attaquant réel ressemble rarement à l'image du pirate encapuchonné. La majorité des tentatives sont automatisées : des programmes parcourent internet en continu, testent des millions d'adresses, essaient des mots de passe connus, cherchent des versions de logiciels avec des failles publiées. Ton projet posé sur un serveur n'a pas besoin d'intéresser quelqu'un pour être attaqué, il suffit qu'il existe et qu'il réponde. Un scanner ne trie pas entre une startup financée et un side-project de portfolio.
Le temps joue aussi contre toi. Une application déployée aujourd'hui utilise des bibliothèques dans leur version du jour. Six mois plus tard, certaines de ces bibliothèques ont des failles rendues publiques, documentées, avec le mode d'emploi de l'attaque en accès libre. Si personne ne met à jour, la surface d'attaque grossit sans qu'une seule ligne du code d'origine ait changé. C'est la logique de la dette technique appliquée à la sécurité, et elle se repère avec les mêmes signaux avant-coureurs que ceux décrits dans notre article sur les signaux d'alarme d'une dette technique qui va exploser.
Retiens ceci : une faille ne se déclenche pas au moment où tu l'écris, mais au moment où quelqu'un la trouve. Entre les deux, il peut se passer un jour ou deux ans. Cette latence est ce qui rend le sujet si facile à repousser.
Trois failles courantes et leur effet réel
1. L'injection SQL
Une injection SQL se produit quand une valeur envoyée par l'utilisateur est insérée telle quelle dans une requête à la base. L'exemple classique reste le champ de connexion. Imagine un code qui construit sa requête comme ceci :
query = "SELECT * FROM users WHERE email = '" + email + "'"Si quelqu'un tape ' OR '1'='1 dans le champ email, la requête finale renvoie tous les utilisateurs. Selon le reste du code, la technique permet de contourner une authentification, de lire une table entière, parfois d'effacer des données. La parade tient dans les requêtes préparées, où la valeur saisie ne peut plus être interprétée comme du code. Ce mécanisme fait partie de ce qu'on couvre dans nos formations backend, notamment celle sur Symfony 7, où les requêtes passent par un ORM qui applique cette protection par défaut.
2. L'accès direct à un objet qui n'est pas le tien
C'est le cas de la commande 1042 vu plus haut. Le nom technique est IDOR, pour référence directe non contrôlée à un objet. L'application affiche une ressource identifiée par un numéro sans vérifier que la personne connectée a le droit de la voir. Cette faille est redoutable parce qu'elle ne demande aucune compétence : il suffit d'incrémenter un chiffre dans la barre d'adresse. Une facture, un dossier, un message privé, tout devient accessible dès que l'identifiant est devinable et que le contrôle d'accès manque. La règle de fond ici est celle du moindre privilège, détaillée dans l'article sur le principe de Least Privilege.
C'est la faille que je vois passer le plus souvent en correction de projet. Le développeur a bien mis une page de connexion, il vérifie donc que l'utilisateur est authentifié. Il oublie la seconde question, celle qui compte : cet utilisateur authentifié a-t-il le droit d'accéder à cette ressource précise. Savoir qui tu es et savoir ce que tu peux voir sont deux contrôles distincts, et le second se code ligne par ligne, sur chaque route.
3. Les secrets exposés
Une clé d'API, un mot de passe de base ou un jeton d'accès écrit dans le code et poussé sur un dépôt Git reste dans l'historique même après suppression. Des robots surveillent les dépôts publics et récupèrent ces secrets dans les minutes qui suivent la publication. Un jeton d'accès à un service cloud oublié dans un commit peut se transformer en facture de plusieurs milliers d'euros, générée par des machines qui minent de la cryptomonnaie sur ton compte pendant que tu dors. Le cas revient assez souvent pour que GitHub ait mis en place un système de détection automatique des secrets, ce qui donne une idée de sa fréquence.
Ces trois failles reviennent dans une large part des projets débutants. Nous en avons rassemblé cinq, avec les corrections associées, dans l'article les 5 failles de sécurité qu'on retrouve dans presque tous les projets juniors.
Les conséquences : argent, loi, réputation
Une faille exploitée ne reste pas un problème technique. Elle se propage dans des domaines qui n'ont rien à voir avec le code, et c'est là que le coût réel apparaît.
Le coût financier
Le vol direct d'abord, quand un accès permet de détourner de l'argent ou de consommer des ressources payantes à ta place. L'interruption ensuite : une application compromise doit souvent être coupée le temps de comprendre ce qui s'est passé, ce qui suspend l'activité pendant des heures ou des jours. La remise en état enfin, qui mobilise du temps de développement, parfois des prestataires, et un audit complet pour vérifier qu'aucune autre porte ne reste ouverte. Pour une petite structure, l'addition de ces postes suffit à mettre l'activité en danger.
Le coût légal
En Europe, dès qu'une application manipule des données personnelles, le RGPD s'applique. Une fuite déclenche des obligations précises : notifier l'autorité de contrôle, la CNIL en France, sous 72 heures dans les cas concernés, et informer les personnes touchées quand le risque pour elles est élevé. Le non-respect de ces obligations, ou une négligence manifeste dans la protection des données, expose à des sanctions. Les montants plafonds du RGPD montent jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires mondial annuel, le plus élevé des deux étant retenu. Une TPE ne se verra pas infliger un tel montant, mais l'échelle donne le ton du sérieux que le législateur attache au sujet.
Le coût de réputation
C'est souvent le plus durable. Un client dont les données ont fuité ne revient pas facilement. Un article de presse local, un fil de discussion sur les réseaux, une capture d'écran de la fuite, et la confiance construite pendant des années se dissout en quelques jours. Pour un freelance ou une jeune boîte, la réputation constitue le principal actif, et une faille rendue publique l'entame d'une manière que le paiement d'une amende ne répare pas.
Le coût humain
Derrière chaque fuite, il y a des personnes réelles dont les informations circulent. Une adresse, un numéro de téléphone, un mot de passe réutilisé sur dix autres sites. Une fuite de mots de passe mal protégés met en danger tous les comptes où la victime a employé la même combinaison. La responsabilité morale de celui qui a stocké ces données sans les protéger correctement est engagée, même si aucune loi ne le poursuit. Ce point pèse plus lourd que les autres pour beaucoup de développeurs une fois qu'ils y sont confrontés.
Le coût sur ta carrière
Il y a un dernier effet, moins visible, qui concerne les personnes en reconversion et les développeurs juniors. En entretien technique, la question de sécurité tombe souvent sous une forme détournée : on te montre un bout de code et on te demande ce que tu en penses. Un candidat qui repère l'entrée non filtrée dans la requête change de catégorie aux yeux du recruteur, parce que ce réflexe signale une compréhension de ce qui se passe réellement à l'exécution. Notre article sur l'entretien technique junior en 2026 revient sur ce type d'exercice.
Les pièges qui reviennent le plus souvent
Quelques raisonnements erronés circulent largement. Les nommer aide à les repérer chez soi.
"Mon projet est trop petit pour intéresser un attaquant."
Les attaques sont automatisées et ne trient pas selon la taille. Un serveur qui répond suffit à devenir une cible.
"Je sécuriserai plus tard, une fois que ce sera lancé."
La mise en ligne est justement le moment où l'application devient atteignable. Reporter la sécurité après le lancement revient à ouvrir la porte avant de poser la serrure.
"Le framework s'occupe de tout."
Un bon framework fournit des garde-fous, à condition de les utiliser. Contourner une protection par facilité annule le bénéfice. Les réglages par défaut ne couvrent pas non plus la logique métier, comme le contrôle d'accès à une ressource précise.
"J'ai supprimé le mot de passe du commit, c'est réglé."
L'historique Git garde tout. Un secret exposé doit être considéré comme compromis et remplacé immédiatement, pas simplement effacé.
Mon opinion, après des années à corriger des projets d'apprenants : la sécurité devrait s'enseigner en même temps que le CRUD, pas dans un module séparé placé en fin de parcours. Quand elle arrive à la fin, elle est perçue comme une couche à ajouter, et une couche à ajouter finit toujours par sauter faute de temps. Quand un formateur montre la requête préparée le jour même où il montre la première requête SQL, le réflexe s'installe sans effort supplémentaire.
La bonne nouvelle, c'est que la sécurité de base n'exige pas un niveau d'expert. Requêtes préparées, contrôle d'accès systématique sur chaque route, secrets sortis du code et rangés dans des variables d'environnement, dépendances tenues à jour, mots de passe hachés avec un algorithme prévu pour ça. Ces cinq réflexes couvrent déjà une grande partie des cas rencontrés en production. Ils s'apprennent en même temps que le développement backend et font partie de nos formations backend comme de notre parcours DevOps et déploiement.
Reste une question à laquelle personne n'a de réponse définitive : à partir de quel niveau de risque investir combien dans la protection. Un site vitrine et une application bancaire n'appellent pas le même effort. Ce curseur, chacun le règle selon ce qu'il manipule et ce qu'il a à perdre. Le seul mauvais réglage consiste à ne pas se poser la question du tout.
