Audit de sécurité d'application web
Revue de code, dépendances et configuration de votre application PHP, avec un plan de correction que vos développeurs peuvent appliquer
La plupart des intrusions dans une application web ne viennent pas d'une attaque sophistiquée : un compte qui accède aux données d'un autre, une bibliothèque jamais mise à jour, un fichier de configuration oublié en ligne. Ce sont des failles qu'un audit de sécurité applicatif trouve en quelques jours.
N-SENS audite des applications web et des API écrites en PHP, sur Symfony, Laravel, CakePHP ou sans framework. Parce que nous sommes développeurs, le rapport ne s'arrête pas au constat : chaque faille vient avec sa correction.
Référentiel OWASP
Ce que vérifie notre audit
Contrôle d'accès
Un utilisateur peut-il lire ou modifier les données d'un autre compte en changeant un identifiant dans l'URL ? Les rôles et les droits d'administration se contournent-ils ? C'est la première faille du classement OWASP, et la plus fréquente dans les applications métier.
Injections et entrées utilisateur
Requêtes SQL construites à la main, sorties non échappées (XSS), envoi de fichiers, désérialisation : chaque point où une donnée extérieure entre dans l'application est relu dans le code.
Authentification et sessions
Stockage des mots de passe, réinitialisation, limitation des tentatives, durée et protection des sessions, jetons d'API, double authentification sur les comptes sensibles.
Versions et dépendances
Version de PHP, du framework et de chaque bibliothèque Composer ou npm, comparées aux avis de sécurité publiés. Une version en fin de vie n'est plus corrigée : elle figure en tête du rapport.
Configuration et hébergement
Mode debug en production, fichiers exposés (.env, .git, sauvegardes), en-têtes de sécurité, HTTPS, droits sur le serveur, réglages de PHP, secrets dans le dépôt de code.
Données personnelles
Quelles données sont stockées, chiffrées, journalisées, conservées et pour combien de temps. Le volet sécurité rejoint ici la conformité RGPD de l'application.
Sécurité d'une application PHP : l'urgence d'octobre 2026
Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques permettant d'exécuter du code à distance sans authentification, sur toutes les installations qui servent des pages web. Le CERT-FR a émis une alerte et a connaissance de preuves de concept.
Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les versions 8.1 et antérieures n'ont pas de correctif officiel. Notre article détaille les versions touchées et les mesures à prendre ; si votre application ne peut pas monter de version facilement, notre offre de migration PHP s'en charge.
Comment se déroule l'audit
- 1
Cadrage
Périmètre (application, API, back-office), comptes de test pour chaque rôle, accès au code et à un environnement de recette. Nous n'auditons jamais une production sans accord écrit.
- 2
Analyse automatisée
Analyse statique du code (PHPStan, règles de sécurité Psalm), audit des dépendances (composer audit), scan de la configuration et des en-têtes. Elle trouve vite les failles connues et dégage du temps pour le reste.
- 3
Revue manuelle et tests
Lecture du code des parcours sensibles et tests en boîte grise depuis chaque rôle : c'est là que se trouvent les failles de logique, invisibles pour un outil.
- 4
Rapport et plan de correction
Chaque faille est décrite, prouvée, notée selon sa gravité et accompagnée de sa correction. Une synthèse d'une page pour la direction, le détail pour les développeurs.
Après l'audit : rester sécurisé
Une application sûre le jour de l'audit ne l'est plus six mois plus tard si personne n'applique les mises à jour. Nos contrats de tierce maintenance applicative incluent la veille et l'application des correctifs de sécurité de PHP, du framework et des dépendances. Pour une application sans mainteneur, notre offre de reprise d'application PHP commence par cet audit.
Si votre application traite des données personnelles, l'audit sert aussi de base à sa mise en conformité RGPD : l'article 32 du règlement impose des mesures de sécurité adaptées au risque.
Questions fréquentes
Quelle différence entre un audit de sécurité et un test d'intrusion ?
Un test d'intrusion (pentest) attaque l'application de l'extérieur, comme le ferait un pirate, en boîte noire ou grise. Un audit de sécurité applicatif ajoute la lecture du code, des dépendances et de la configuration : il trouve davantage de failles et indique directement la ligne à corriger. Nous réalisons des audits de code et des tests en boîte grise. Si un test d'intrusion par un prestataire qualifié PASSI vous est imposé, nous préparons l'application et corrigeons ses constats.
Combien coûte un audit de sécurité d'une application web ?
Il dépend surtout de la taille du code et du nombre de rôles. Pour une application PHP de taille moyenne, comptez de 3 à 8 jours, rapport compris. Nous le chiffrons au forfait après un premier échange et un coup d'œil au dépôt.
Auditez-vous une application que vous n'avez pas développée ?
Oui, c'est le cas le plus courant. Nous auditons des applications Symfony, Laravel, CakePHP, Drupal, Magento, Zend Framework ou en PHP sans framework, quel que soit le prestataire d'origine.
Corrigez-vous les failles trouvées ?
Oui, si vous le souhaitez : nous développons en PHP depuis plus de dix ans et pouvons appliquer le plan de correction, puis le vérifier. Vous pouvez aussi transmettre le rapport à votre équipe ou à votre prestataire actuel.
À quelle fréquence faut-il auditer une application ?
Avant une mise en production importante, après une refonte, à la reprise d'une application par une nouvelle équipe, et au moins une fois par an pour une application qui manipule des données personnelles ou des paiements. Entre deux audits, une maintenance qui applique les mises à jour de sécurité fait l'essentiel du travail.
Notre application tourne sur une ancienne version de PHP : est-ce grave ?
Oui. Les versions 8.1 et antérieures ne reçoivent plus de correctifs : les failles critiques publiées en octobre 2026 n'y ont pas de correction officielle. Un audit le signalera en premier, et la migration vers PHP 8.4 ou 8.5 est souvent la correction la plus rentable.
Votre application est-elle exposée ?
Indiquez-nous son framework et sa version de PHP, ou appelez-nous au +33 (0)1 84 80 48 01 : nous cadrons l'audit avec vous.
Demander un audit de sécurité