Votre application métier sur-mesure Symfony, Laravel ou PHP est en production depuis plusieurs années. Elle gère des données clients, des flux financiers, des accès RH. Et elle n’a probablement jamais fait l’objet d’un audit de sécurité structuré.
Ce n’est pas une hypothèse. C’est le constat que nous faisons sur la quasi-totalité des applicatifs métier que nous auditons.
Les failles que l’OWASP Top 10 documente, que les scanners automatiques détectent en 20 minutes, votre application métier les porte peut-être depuis le premier sprint.
Ce qu’un pentest standard ne voit pas dans une application métier
Il existe une différence fondamentale entre un pentest d’infrastructure (scan de ports, analyse réseau, test de configuration serveur) et un audit applicatif de sécurité centré sur le code métier.
Un pentest généraliste identifie les vulnérabilités de surface : headers HTTP mal configurés, certificats expirés, ports ouverts. Il est utile. Il n’est pas suffisant.
Une application Symfony en production depuis 2019 peut avoir :
- Des IDOR (Insecure Direct Object References) : un utilisateur qui modifie un ID dans l’URL et accède aux données sensibles d’un autre client, visibles uniquement si l’on comprend le modèle de données de l’application
- Des injections SQL dans des requêtes DQL non paramétrées que les scanners automatiques ne testent pas car elles nécessitent une connaissance des routes métier internes
- Une couche de communication inter-applicative sans authentification : chaque service fait mutuellement confiance aux autres, sans jeton : une porte d’entrée unique qui rend tous les autres défauts atteignables depuis l’extérieur
- Des clés de signature JWT triviales (de type « 12345 ») dupliquées dans plusieurs applications : les tokens inter-services sont forgeables par n’importe qui connaissant la clé
- Des vulnérabilités de timing sur les endpoints d’authentification : exploitables par des attaques par timing qui mesurent les différences de temps de réponse pour déduire si un identifiant est valide
- Des dépendances PHP avec des CVE critiques (score CVSS ≥ 7.0) jamais mises à jour depuis le déploiement initial
Ces catégories correspondent exactement aux items A1, A3, A7, A9 et A6 de l’OWASP Top 10 2021. Elles ne sont pas détectables par un outil externe qui ignore la logique métier de l’application.
Pourquoi l’agence qui a construit l’app n’a pas résolu le problème
Premier réflexe d’un DSI : « le prestataire qui a développé l’application saura bien l’auditer. »
Deux problèmes à ça.
D’abord, l’agence de développement n’a pas forcément les compétences en sécurité applicatif. Développer une application fonctionnelle et savoir identifier les vecteurs d’attaque OWASP sont deux métiers distincts. Écrire un contrôleur Symfony ne garantit pas de connaître les règles CVSS de scoring des vulnérabilités.
Ensuite, même si les compétences existent, il y a un conflit d’intérêt structurel : l’agence qui audite son propre travail est incitée à minimiser les problèmes. Ce n’est pas une question de mauvaise foi : c’est un biais cognitif documenté dans toute démarche d’assurance qualité.
Un audit applicatif sérieux suppose une séparation nette entre l’équipe qui a construit et l’équipe qui évalue.
Ce que contient un audit applicatif OWASP
L’audit applicatif couvre quatre niveaux :
Analyse statique du code source (SAST). Lecture ligne à ligne du code PHP (Symfony, Laravel), JavaScript et des requêtes SQL/DQL. Outils : PHPStan, PHPCS, PHPCPD, Rector. Aucune interaction avec la production, zéro risque opérationnel.
Analyse des dépendances (SCA : Software Composition Analysis). Inventaire complet des librairies tierces (Composer, npm) croisé avec les bases CVE. Score CVSS v3.1 attribué à chaque vulnérabilité. Un applicatif Symfony non maintenu depuis 2 ans peut cumuler plusieurs dizaines de CVE ouvertes, dont certaines au-dessus du seuil critique (CVSS ≥ 7.0).
Tests dynamiques sur environnement de recette. Simulation des vecteurs d’attaque OWASP Top 10 sur un environnement cloisonné : injection SQL, IDOR, XSS stocké, CSRF, exposition d’API non protégées. Chaque vulnérabilité confirmée est documentée avec proof-of-concept.
Rapport de remédiation priorisé. Livrable structuré par criticité CVSS (Critique / Élevé / Moyen / Faible), avec pour chaque finding : description technique, impact métier concret, correction recommandée avec exemple de code. Ce n’est pas un export de scanner automatique, c’est une analyse rédigée par un développeur qui connaît votre stack.
Cas concret : 61 findings sur 18 applications PHP pour un groupe industriel régional
En 2026, Mink a réalisé l’audit d’un parc de 18 applications métier PHP (CodeIgniter, Symfony, Laravel) pour un groupe industriel régional multi-sites. Le périmètre couvrait également 6 serveurs, 18 bases de données MySQL et SQL Server, et une bibliothèque partagée entre applications. Les données en jeu : comptabilité analytique consolidée, RH, données personnelles de catégorie particulière, flux financiers.
Résultats (méthode SAST et SCA, CVSS v3.1, OWASP Top 10) :
15 findings critiques (CVSS 9,0 à 10,0), dont une couche de communication inter-applicative sans authentification (CVSS 10,0, exploitable à distance, sans compte, avec propagation à l’ensemble du parc), des clés JWT de type « 12345 » dupliquées dans 12 applications, et des injections SQL dans les requêtes financières consolidées.
29 findings élevés, dont la vérification JWT entièrement commentée dans le code, des données personnelles énumérables sans authentification, et 14 applications exposées à une faille RCE via phpspreadsheet (SSRF/RCE via IOFactory::load, exploitable sans authentification préalable).
17 findings moyens : dette technique, 255 532 violations PSR-12, configurations divergentes.
Impact chiffré
486 CVE héritées dans les dépendances Composer : phpseclib 1.x/2.x, guzzle 6.5.x, socle PHP 7.x et CodeIgniter 3 en fin de vie. Un composer audit lancé aujourd’hui sur un parc non maintenu depuis 18 mois donne une première estimation en moins de cinq minutes.
La trajectoire de remédiation définie après l’audit : 5 phases sur 22 mois, maintien du parc existant en parallèle de la réécriture pour préserver la continuité sur les applications financières critiques. Un accompagnement en Tierce Maintenance Applicative a été mis en place dès la phase 0 pour assurer la continuité de service pendant la transition.
Quand déclencher un audit applicatif ?
Reprise d’application. Vous récupérez une application développée par une autre agence ou un développeur seul qui détient toute la connaissance du code. Vous ne savez pas ce qu’il y a dans le code.
Préparation ISO 27001. L’audit couvre directement les exigences A.14.2 (sécurité dans les processus de développement), A.12.6 (vulnérabilités techniques) et A.8.8 (gestion des dépendances).
Après un incident ou une tentative d’intrusion. L’audit mesure l’exposition réelle et identifie les autres vecteurs potentiellement exploités.
Avant une levée de fonds ou une acquisition. La due diligence technique des investisseurs inclut systématiquement une revue sécurité. Mieux vaut arriver avec un rapport propre.
Application critique sans audit depuis plus de 2 ans. Chaque mois sans mise à jour de dépendances, c’est de nouvelles CVE publiées sur des librairies que vous utilisez en production.
Besoin d’un audit applicatif ?
Cartographions ensemble les risques sur votre application PHP métier.
Pourquoi Mink aborde l’audit différemment
Mink n’est pas une société de cybersécurité pure-play. C’est une agence de développement applicatif avec Symfony, Laravel, React, Vue.js et qui travaille sur des applicatifs métier complexes depuis 2015, avec 18 développeurs et consultants à Bordeaux.
Quand un auditeur Mink analyse un contrôleur Symfony, il ne cherche pas des signatures dans un scanner : il comprend pourquoi le développeur a pris tel raccourci, quel contournement métier a introduit la faille, et comment corriger sans casser les flux existants. C’est ce qui permet d’identifier les vulnérabilités logiques : IDOR, mauvaises règles d’autorisation, expositions de données indirectes, que les outils automatiques ignorent par construction.
Le tarif indicatif d’un audit applicatif de sécurité Mink : entre 8 000€ et 15 000 € HT selon la taille et la complexité du périmètre.
