Votre site, portail client, logiciel SaaS ou API, testé comme le ferait un vrai attaquant : manuellement, chaque faille prouvée et accompagnée d’un correctif concret. Pensé pour les PME qui traitent des données clients en ligne et doivent prouver que leur application tient. La couverture suit le guide de test OWASP (WSTG), adaptée à ce que fait réellement votre application. Connexion, réinitialisation du mot de passe, MFA, gestion des sessions : tous les moyens de prendre le contrôle d’un compte. Un client peut-il voir les factures d’un autre ? Un simple utilisateur peut-il accéder aux fonctions d’administration ? La faille critique la plus fréquente. Injections SQL, de commandes et de templates, cross-site scripting, téléversement de fichiers malveillants, redirections non maîtrisées. Points d’accès REST et GraphQL, limites de débit, et les parcours que les attaquants détournent : paiements, codes promo, validations. Périmètre fixe, prix fixe, aucune surprise. Les failles les plus graves sont rarement exotiques. Celles-ci reviennent sans cesse. Modifier un identifiant dans l’URL affiche les données d’un autre client. Facile à exploiter, facile à rater en revue de code. Interfaces d’administration accessibles depuis Internet, sans MFA, parfois avec des identifiants par défaut ou partagés. Clés d’API dans le code front, messages d’erreur trop bavards, points de test oubliés et sauvegardes en ligne. Frameworks, bibliothèques et extensions avec des vulnérabilités publiques, recherchées automatiquement par les attaquants. Les tests sont conçus pour l’éviter. Les actions dangereuses comme la suppression massive ou le déni de service sont exclues sauf demande de votre part, et les créneaux et contacts sont validés à l’avance. Une préproduction fidèle à la production est idéale. À défaut, la production peut être testée avec des comptes dédiés et des précautions convenues ensemble. Non. Un test en boîte noire ou grise avec des comptes utilisateurs est le point de départ habituel. L’accès au code ou à la documentation (boîte blanche) permet d’aller plus loin dans le même temps. Oui. Une fois les failles corrigées, je vérifie les corrections et mets le rapport à jour, pour que vous puissiez prouver à vos clients ou auditeurs que le risque est fermé. Dites-moi ce que fait l’application et qui l’utilise. Vous recevez une proposition à prix fixe après un appel gratuit de 30 minutes.Test d’intrusion d’application web, avant que les attaquants ne le fassent.
Ce que je teste
Authentification et sessions
Contrôle d’accès
Injections et saisies
API et logique métier
Le déroulé d’un test d’intrusion web
Ce que les applications de PME ratent souvent
Contrôle d’accès défaillant
Administration mal protégée
Secrets exposés
Composants obsolètes
Test d’intrusion web : vos questions
Le test peut-il casser mon application ?
Faut-il tester la production ou la préproduction ?
Avez-vous besoin du code source ?
Le contre-audit est-il inclus ?
Prêt à tester votre application ?
Pentest web
En bref
01 / Périmètre
02 / Méthode
03 / Constats fréquents
04 / FAQ
