Pentest web

Test d’intrusion d’application web, avant que les attaquants ne le fassent.

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.

En bref
Cibles
Applications web · API · portails clients
Approche
Boîte noire, grise ou blanche
Référentiel
OWASP WSTG · OWASP Top 10
Livrable
Rapport, restitution et contre-audit
01 / Périmètre

Ce que je teste

La couverture suit le guide de test OWASP (WSTG), adaptée à ce que fait réellement votre application.

Authentification et sessions

Connexion, réinitialisation du mot de passe, MFA, gestion des sessions : tous les moyens de prendre le contrôle d’un compte.

Contrôle d’accès

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 et saisies

Injections SQL, de commandes et de templates, cross-site scripting, téléversement de fichiers malveillants, redirections non maîtrisées.

API et logique métier

Points d’accès REST et GraphQL, limites de débit, et les parcours que les attaquants détournent : paiements, codes promo, validations.

02 / Méthode

Le déroulé d’un test d’intrusion web

Périmètre fixe, prix fixe, aucune surprise.

  1. Cadrage. URL, rôles utilisateurs, environnements, comptes de test et créneaux, validés par écrit.
  2. Cartographie. Chaque page, rôle et appel d’API est recensé pour comprendre ce que l’application expose vraiment.
  3. Tests manuels. Les scanners servent seulement à couvrir le terrain. Chaque faille est vérifiée à la main et prouvée : aucun faux positif dans le rapport.
  4. Rapport. Une synthèse pour la direction, puis chaque constat classé par risque, avec les étapes pour le reproduire et un correctif concret pour vos développeurs.
  5. Restitution et contre-audit. Nous passons les résultats en revue ensemble, puis je vérifie vos corrections pour prouver que le risque est fermé.
03 / Constats fréquents

Ce que les applications de PME ratent souvent

Les failles les plus graves sont rarement exotiques. Celles-ci reviennent sans cesse.

Contrôle d’accès défaillant

Modifier un identifiant dans l’URL affiche les données d’un autre client. Facile à exploiter, facile à rater en revue de code.

Administration mal protégée

Interfaces d’administration accessibles depuis Internet, sans MFA, parfois avec des identifiants par défaut ou partagés.

Secrets exposés

Clés d’API dans le code front, messages d’erreur trop bavards, points de test oubliés et sauvegardes en ligne.

Composants obsolètes

Frameworks, bibliothèques et extensions avec des vulnérabilités publiques, recherchées automatiquement par les attaquants.

04 / FAQ

Test d’intrusion web : vos questions

Le test peut-il casser mon application ?

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.

Faut-il tester la production ou la préproduction ?

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.

Avez-vous besoin du code source ?

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.

Le contre-audit est-il inclus ?

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é.

Prêt à tester votre application ?

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.