Caroline B.
Cheffe de marques
Un audit de sécurité d’application
Un audit de sécurité d'une application part d'une question que rien dans votre outil ne posera à votre place : qui peut atteindre quoi, et par quel chemin. Nous y répondons accès par accès, puis nous classons ce que nous trouvons.
15 ans
d'expérience
250+
missions réalisées
+30
projets en activité
100%
sur-mesure
Ils nous font confiance
LE CONSTAT
Une application exposée se comporte exactement comme une application saine
Une panne se voit, et une erreur finit dans un ticket. Une faille de sécurité produit le comportement attendu : l’application répond, affiche, enregistre. Simplement, elle le fait pour quelqu’un qui n’aurait pas dû obtenir la réponse. Votre supervision reste au vert, et l’accès demeure ouvert aussi longtemps que personne ne le cherche.
Ce qui le trouve vient du dehors. Un ancien salarié ressaisit son mot de passe des mois après son départ et entre. Un utilisateur curieux essaie une adresse qu’aucun menu ne lui propose et obtient une page d’administration. Des programmes balaient en continu les adresses publiques à la recherche d’une porte déjà décrite ailleurs. Les trois vous devancent.
La question, elle, n’appartient à personne. Votre prestataire livre ce que le cahier des charges décrit, et un cahier des charges énumère les fonctions à obtenir. Les accès à interdire n’y figurent nulle part. Votre hébergeur tient la machine, ses accès et ses sauvegardes. Les règles qui décident qui voit quel dossier vivent, elles, dans votre application. Vos équipes métier se servent de l’outil sans avoir de raison d’en interroger les limites. Chacun travaille dans son périmètre, et le sujet tombe entre les périmètres.
Un audit de sécurité d’une application prend cette question à sa charge. Il établit qui détient un accès et ce qu’il porte réellement, tente d’atteindre depuis un compte ordinaire ce qui devait rester hors de portée, un test d’intrusion mené depuis l’intérieur plutôt que contre la porte d’entrée, relève ce qui répond en ligne autour de l’application, puis classe ce qu’il trouve selon la conséquence plutôt que selon la prouesse technique. L’exposition est une des questions que pose l’état d’une application, et pas la seule : la qualité du code et la capacité à évoluer se traitent dans un audit technique de votre application.
Vous vous reconnaissez ?
Ce qui déclenche un audit de sécurité d'une application
Ces situations vous arrivent par une personne, pas par une alerte technique : un utilisateur, un service achats en cours de négociation, un départ, un changement de main.
Un utilisateur a vu ce qui appartenait à un autre
Un client, un partenaire ou un salarié tombe sur un dossier qui ne le concerne pas. Le signalement vous arrive par la personne qui l'a vu.
Un grand compte conditionne sa signature à un questionnaire de sécurité
Le service achats de votre prospect demande comment vous séparez ses données de celles des autres. Répondre au jugé engage le contrat.
Quelqu'un est parti, ses accès sont restés
Salarié, stagiaire, prestataire : personne n'a fait le tour de ce que chacun pouvait encore atteindre après son départ.
Vous héritez d'une application développée ailleurs
Rachat, changement de prestataire, projet repris en interne : vous répondez désormais de choix techniques que vous n'avez pas faits.
Ces quatre entrées mènent au même travail préalable : établir ce que l’application fait aujourd’hui, et pour qui. La liste des rôles prévus se reconstitue en réunion, auprès de plusieurs personnes, et c’est elle qui manque le jour où il faut décider si un accès était légitime. Sur une application dont plus personne ne connaît le détail, une reprise de code sans documentation précède l’audit : elle rétablit ce que l’outil fait, avant d’examiner ce qu’il laisse faire.
NOS SERVICES
Les endroits par où une application laisse passer un accès
Chaque ligne est une vérification menée sur votre application, avec son constat écrit et le travail qu'elle demande.
Droits réellement portés par chaque compte
Ce que chaque compte peut atteindre, comparé à ce qu'en fait son titulaire.
Séparation entre vos utilisateurs
Nous tentons, depuis un compte ordinaire, d'atteindre les données d'un autre client, d'un autre service, d'un autre dossier.
Fichiers atteignables par leur seule adresse
Devis, factures, pièces jointes et exports : ce qui s'ouvre quand l'adresse circule hors de l'application.
Ce que vos formulaires acceptent
Le contenu envoyé par un champ de saisie, et ce que l'application en fait avant de l'enregistrer.
Entrée dans l'application
Règles de mot de passe, seconde vérification, blocage après échecs répétés, et ce que révèle une tentative ratée.
Ce qui répond en ligne autour de l'application
Copies de recette, versions remplacées, interfaces d'administration et pages de service encore accessibles de l'extérieur.
Conséquence chiffrée de chaque trouvaille
Ce que la faille ouvre, sur combien de personnes elle porte, et le travail que sa fermeture demande.
Nos dernières réalisations
Toutes nos réalisations 4,8
CE QU'ILS EN DISENT
Nous avons aidé des dizaines de clients dans leur transformation digitale
-
Equipe très à l'écoute, dynamique, réactive, de très bons conseils, très pro, à la fois très techniques mais qui sait aussi se mettre à la place de personnes non averties.
-
Laurence V.
Directrice Marketing
Nous ne pouvons que nous féliciter de notre choix d'agence web : une équipe sympathique, à l'écoute, professionnelle, rigoureuse, technique... présente tout en respectant nos contraintes.
-
Mirela O.
Reponsable Marketing
À l'écoute, disponibles et très créatifs, ils comprennent rapidement les besoins de leurs clients et leurs conseils sont opportuns.
-
Tiffany V.
Responsable Communication
Bonne compréhension des enjeux et attentes, couplée à de la créativité : tout est fluide. J'apprécie leur accompagnement, leur prise en charge et la disponibilité des équipes.
Qui peut lire les données de vos clients ce matin ?
Nous partons de la liste de vos comptes dès le premier échange pour mesurer l’écart avec ce qui devrait y être.
Une autorisation écrite d'abord, des tentatives qui échouent à la fin
-
Nous délimitons par écrit ce que nous avons le droit de tester, sur quels environnements et à quelles heures, et qui joindre si nous trouvons quelque chose de grave en cours de route. Cette autorisation couvre vos équipes autant que la nôtre. Le délai de la mission s'y fixe également : suivant ce que couvre le périmètre retenu, il va de quelques semaines à quelques mois, arrêté précisément une fois ce cadrage posé.
-
Nous décrivons avec vous ce que chaque rôle doit pouvoir atteindre, écran par écran. Cette carte des droits attendus devient la référence de tout l'audit : sans elle, un accès trouvé reste une observation, avec elle il devient un écart mesurable entre le prévu et l'autorisé.
-
Ce que l'interface retire de l'affichage reste parfois en place derrière elle, et c'est cet écart que nous relevons. Un menu masqué dont l'adresse répond encore, un bouton retiré de l'affichage dont l'action reste appelable, un message d'erreur qui confirme l'existence d'un compte : ces détails ouvrent des chemins que le code seul ne montre pas.
-
Chaque correctif part en développement accompagné de l'essai qui a révélé la faille. Le développeur travaille sur une tentative reproductible, et la livraison se valide sur ce même essai, qui doit désormais échouer. Cette remédiation reste comprise dans le forfait de l'audit, elle ne se facture pas à part. Ce qui reste ouvert figure au rapport avec ce que ça expose.
-
Le suivi que nous proposons ensuite porte sur deux choses. Nous surveillons pour vous les correctifs publiés sur les briques extérieures que votre application embarque. Et chaque nouvelle fonction repasse devant la carte des droits avant sa mise en ligne. Ce suivi relève d'un contrat de maintenance et d'évolution, distinct du forfait de l'audit et engagé à part.
Les sept questions qu'un dirigeant nous pose sur la sécurité de son application
La donnée directement monnayable est rare. Ce que porte une application de gestion se revend autrement. Un fichier de clients avec les montants engagés sert à monter des demandes de virement crédibles. Une liste de fournisseurs sert à se faire passer pour l’un d’eux. Un historique de dossiers renseigne un concurrent sur vos marges. Et un accès valide chez vous sert de point d’appui pour écrire à vos clients depuis une adresse qu’ils reconnaissent : le préjudice se joue chez eux, la question vous revient quand même.
.Chaque essai est classé avant d’être joué, selon ce qu’il laisserait derrière lui. Les essais qui se contentent de lire, de consulter une donnée hors de portée ou de tenter une entrée depuis un compte ordinaire se jouent sur votre application en service, sans rien y modifier. Ceux qui écrivent, suppriment ou saturent attendent une copie de votre environnement, ou une fenêtre horaire que vous fixez. Vous recevez cette seconde liste pour accord avant le premier essai, et vos équipes savent qui joindre pendant toute la durée des tests.
.Le cadenas atteste deux choses, et deux seulement : votre visiteur a bien joint le domaine qu’il visait, et ce qui passe entre son navigateur et votre serveur reste illisible pour qui l’intercepterait en route. C’est utile, et sans effet sur le reste. Le chiffrement s’applique à une demande abusive exactement comme à une demande légitime. Si un utilisateur connecté réclame le dossier d’un autre et que l’application le lui envoie, le cadenas protège cet envoi-là aussi. Le trajet était sûr, la décision d’envoyer ne l’était pas.
.Répondez d’abord, brièvement, pour accuser réception : le silence pousse un chercheur à publier de son côté, et vous perdez la main sur le calendrier. Réclamez ensuite la preuve technique, parce qu’une description seule ne distingue pas un vrai signalement d’une tentative de vous vendre une prestation. Et gardez tout versement pour après vérification. Nous reproduisons le chemin décrit et mesurons ce qu’il ouvre, ce qui vous dit si vous traitez un défaut isolé ou une règle absente partout ailleurs.
.C’est le document le plus sensible que produit l’audit, puisqu’il énumère les chemins avant qu’ils soient refermés. Nous le remettons nommément, à des destinataires que vous arrêtez au démarrage. Une synthèse de décision, sans mode opératoire, va au comité de direction ou au client qui exige une preuve de sérieux. Le détail technique, lui, reste réservé aux personnes qui poseront les correctifs, et il perd de sa sensibilité à mesure qu’elles avancent.
.Elles referment une catégorie de failles : celles que quelqu’un d’autre a découvertes et publiées sur une brique commune à quantité d’applications. Elles laissent intactes celles qui viennent de votre application, un droit accordé trop largement, un contrôle oublié sur une page ajoutée dans l’urgence, un export laissé accessible sans vérification. Personne ne publiera de correctif pour celles-là, puisqu’elles n’existent que chez vous. Et quand le socle cesse lui-même de recevoir des correctifs, la décision passe de l’audit au chantier, du côté de la modernisation de l’outil.
.Le cadrage écrit du premier point de notre méthode existe justement pour ça, posé avant le premier essai, pas après un incident. Il fixe les environnements concernés, les heures autorisées, et qui nous joignons si quelque chose dérape en cours de route. Les essais qui écrivent, suppriment ou saturent une donnée n’ont de toute façon jamais lieu sur l’application en service : ils attendent une copie de votre environnement, ce qui retire l’essentiel du risque avant même qu’il existe. Ce que couvre chaque partie si un incident survient malgré tout se fixe dans le contrat qui encadre la mission, avant sa signature.
. POUR ALLER PLUS LOIN
L'exposition d'une application se mesure depuis l'extérieur
Une faille se juge sur ce qu’elle ouvre, pas sur sa difficulté
Un rapport de sécurité qui classe par score technique laisse son lecteur sans décision à prendre. Un dirigeant tranche sur une phrase : depuis un compte client ordinaire, quelqu’un atteint les dossiers de tous vos autres clients.
Nous formulons donc chaque trouvaille dans le même ordre. Qui peut l’emprunter : n’importe qui depuis internet, un utilisateur connecté quelconque, ou un salarié déjà titulaire d’un accès. Ce qu’il obtient : une lecture, une modification, ou la main sur l’application entière. Sur combien de personnes ça porte : un dossier, un client, ou le fichier complet. Le classement qui en sort ressemble peu à celui d’un outil automatique, et une faille difficile à exploiter qui donne le fichier client complet y passe devant une faille triviale sur une page interne. C’est cet ordre qui devient votre plan de correction.
Un compte ouvert se referme rarement de lui-même
Votre effectif monte et descend. Le nombre de comptes valides dans votre application, lui, ne fait que monter.
Un compte partagé par plusieurs personnes change de mains sans qu’aucun mot de passe soit renouvelé, et l’application ne sait plus dire qui le détient vraiment. Un prestataire obtient un accès d’administration pour une intervention, et personne ne referme ensuite. Les droits suivent le même mouvement : qui change de poste obtient ce que son nouveau rôle demande et conserve ce que l’ancien lui avait donné. Après quelques mobilités, une poignée de comptes portent des droits que plus personne n’a décidés d’ensemble. L’audit reconstitue cette liste et la confronte à ce que chacun fait de ses journées, et le tri qui en résulte referme des accès sans qu’une ligne de code change.
Votre application répond à qui sait quoi lui demander
Le classement de référence des risques applicatifs, publié par la fondation OWASP à partir de plus de 2,8 millions d’applications analysées, place les défauts de contrôle d’accès en tête de son édition 2025. Cette catégorie couvre des dizaines de défauts distincts. Le plus simple d’entre eux ne demande aucune compétence technique.
Votre application affiche une facture. Son adresse contient un numéro. L’utilisateur remplace ce numéro par un autre, valide, et reçoit la facture d’un tiers. L’application a fait son travail : elle a vérifié que la personne était connectée, elle a trouvé le document, elle l’a envoyé. Le contrôle qui manque tient dans une question qu’elle ne pose jamais, celle de savoir si ce document appartient à cette personne.
La même mécanique se rejoue sur des chemins moins visibles : un paramètre de requête que l’interface ne propose jamais mais que le serveur accepte sans le vérifier, une action d’administrateur appelée sans passer par le bouton, un service qui alimente une application mobile et suppose que seul le programme prévu l’interrogerait. Ces chemins existent parce que la vérification a été posée dans l’écran plutôt que dans la fonction qui répond. Reconnaître qu’une réponse est illégitime suppose ensuite de savoir à qui appartient la donnée, information qui vit dans votre métier, pas dans le code. Cette part se teste avec vous, dossier par dossier.
Ce qui répond sur internet autour de votre application
L’application que vous avez commandée occupe une adresse. Autour d’elle vivent des choses que personne n’a commandées et que personne ne surveille : la copie de recette laissée accessible après validation d’une version, l’ancienne interface remplacée mais toujours servie, le sous-domaine créé pour une campagne terminée. Chacun répond à qui l’interroge et vieillit sans recevoir le moindre correctif.
Le code embarque de son côté des briques écrites ailleurs, qui évitent de tout réécrire. Elles arrivent avec une contrepartie : leurs failles sont publiques. Quand l’une d’elles est corrigée, le défaut est décrit en clair, et le correctif publié désigne du même coup ceux qui ne l’ont pas encore posé. Le rapport annuel de Verizon sur les compromissions de données, édition 2026, construit sur plus de 22 000 compromissions confirmées, place désormais l’exploitation d’une faille connue au premier rang des modes d’entrée, devant l’usage d’identifiants volés.
Dresser la liste de ce qui répond à votre nom est donc le premier geste de l’audit. Ce que l’entreprise croit avoir en ligne et ce qui répond réellement forment rarement la même liste. Ce même inventaire nourrit la revue technique d’ensemble du socle, qui le rapproche de l’état du code.
Deux livrables sortent de l’audit, et les deux sont à vous
Le code corrigé et la carte des droits établie pendant l’audit vous appartiennent, sans réserve. Aucun abonnement ne s’y attache : votre équipe ou un autre prestataire reprend l’un et l’autre sans dépendre de nous pour la suite.
