Audit & pentest web
Un site à examiner, une application SaaS à éprouver ou une API dont les accès doivent être vérifiés. Je définis avec vous le périmètre, puis je relie les constats à des preuves et à des corrections.
PNPT · HTB CWES · Paris et à distance
Cartographier l’application, ses API et ses rôles pour définir les tests.
Suivre les requêtes et éprouver les autorisations, y compris entre comptes et rôles.
Fermer les accès indus, puis re-tester les parcours autorisés et interdits.
Prestations
Faire le point sur un site ou un périmètre web défini : configuration, accès et faiblesses courantes. Vous repartez avec des constats expliqués et des corrections à prioriser.
Voir le périmètreAvant une mise en production ou après une évolution sensible, vérifiez ce qu’un attaquant pourrait exploiter. Je teste les rôles, les accès aux données et les parcours métier, puis votre équipe reçoit les preuves et les corrections à prioriser.
Voir le périmètreUne application multi-clients ? Voir le pentest SaaS ↗
Choisir
Un audit donne une vue structurée de votre sécurité. Un pentest met à l'épreuve les accès et les parcours d'une application.
Définir mon périmètre ↗Livrable
Synthèse pour les décideurs, constats reproductibles pour les développeurs, corrections classées par priorité.
Voir un exemple de rapport ↗Dans le portail d’une même entreprise, un salarié du service commercial peut ouvrir le fichier de paie réservé aux RH en changeant le numéro du document dans la requête. Être connecté ne lui donne pas ce droit.
Modifier l’identifiant du document dans une requête authentifiée, puis vérifier les droits sur la ressource retournée.
Le fichier RH est lisible avec un simple compte commercial.
Impact illustréConfidentialité : les noms et salaires des collègues deviennent accessibles à une personne qui n’est pas habilitée à les consulter.
GET /api/documents/204200 OK · fichier de paie divulguéVérifier côté serveur que le compte dispose du droit de lecture sur ce document précis. L’accès au portail et l’appartenance à la même entreprise ne suffisent pas.
GET /api/documents/204403 Forbidden · document RH protégéCes résultats illustrent le re-test attendu. Ils ne correspondent pas à des tests réalisés chez un client.
Le bouton d’export des comptes est masqué pour les utilisateurs standards. Pourtant, l’API exécute leur demande d’export, car elle ne vérifie pas le rôle du compte.
Appeler directement une fonction d’administration avec un compte standard, même lorsque son bouton est masqué.
L’interface masque l’action, mais le serveur livre quand même l’export.
Impact illustréConfidentialité : export de données de comptes depuis une fonction d’administration.
GET /api/admin/users/export200 OK · export accessibleCentraliser les autorisations côté serveur et exiger le droit d’export sur l’endpoint d’administration.
GET /api/admin/users/export403 Forbidden · rôle insuffisantLe périmètre du re-test réel dépend des accès fournis et des corrections disponibles. Les limites sont consignées dans le rapport.
Un article coûte 120 € au catalogue. Le navigateur envoie le montant de la commande et le serveur lui fait confiance : un acheteur peut le remplacer par 1 € et créer une commande à ce prix.
Modifier le montant envoyé par le navigateur pour vérifier si le serveur le reprend ou le recalcule depuis son catalogue.
Le montant modifié dans le navigateur devient le prix de la commande.
Impact illustréIntégrité commerciale : une commande est enregistrée avec un montant non autorisé. Cet exemple s’arrête avant tout paiement réel.
POST /api/orders
{ "productId": "AT-120", "quantity": 1, "unitPrice": 1 }201 Created · commande à 1 €Calculer le total côté serveur depuis le catalogue et les remises autorisées. Les montants transmis par le navigateur ne constituent jamais la référence du prix.
POST /api/orders
{ "productId": "AT-120", "quantity": 1, "unitPrice": 1 }201 Created · prix recalculé à 120 €Montants et article fictifs. Les règles de TVA, de remise et de paiement d’une application réelle demandent des cas de test adaptés.
La méthode
Définir le périmètre, les accès et les conditions d’intervention. Autorisation écrite avant les tests.
Examiner les points d’entrée et la logique métier. Confirmer les failles par des tests contrôlés.
Expliquer les impacts et les preuves. Livrer une synthèse et un plan de correction priorisé.
Re-tester les points corrigés selon les conditions de la mission. Documenter ce qui reste à traiter.
Vous êtes un cabinet cyber ? Un renfort indépendant pour vos missions, avec un cadre de collaboration défini.
Travailler ensemble ↗Quand intervenir
Votre interlocuteur
TCM Security · examen pratique
Un pentest réseau pratique, de la reconnaissance à l’exploitation d’un environnement Active Directory.
Présenter les preuves et expliquer les risques, avec un plan de correction compréhensible.
Hack The Box · examen pratique
Un examen pratique consacré à l’exploitation d’applications web, de services et d’API.
Relier un défaut technique à son impact applicatif et aux corrections attendues.
Ces certifications attestent de compétences évaluées en examen pratique. Le périmètre de votre mission reste défini selon votre besoin.
Questions fréquentes
Questions / Réponses
08 points à éclaircir
Question 01 sur 08
Le devis dépend du périmètre : application, API, comptes, rôles et fonctions à tester. Les accès disponibles et la profondeur des vérifications comptent aussi. Un premier échange sert à préciser ces éléments avant de proposer une mission chiffrée.
La durée dépend du périmètre et des accès disponibles. À titre indicatif : 3 à 5 jours ouvrés pour un audit de site, 5 à 10 jours pour un pentest web. Un re-test des points convenus peut être prévu après correction, avec ses conditions dans la proposition.
Un audit examine un périmètre défini et ses faiblesses courantes. Un pentest inclut des tentatives d’exploitation contrôlées pour vérifier l’impact des failles et des défauts de logique métier. Le choix dépend de ce que vous devez comprendre ou faire vérifier.
La taille seule ne suffit pas à décider. Un espace client, des données sensibles ou une application exposée peuvent justifier des vérifications ciblées. Le premier échange sert à évaluer votre exposition et à choisir un périmètre proportionné.
La mission prévoit une synthèse pour la direction et des constats techniques avec preuves, impacts et corrections prioritaires. Le format, la restitution et les conditions du re-test sont précisés dans la proposition. Un exemple pédagogique est consultable sur ce site.
Boris est titulaire du PNPT, délivré par TCM Security, et du HTB CWES, délivré par Hack The Box. Ces certifications comprennent des examens pratiques en sécurité offensive. Les liens de vérification sont accessibles dans la présentation du consultant.
Les tests sont encadrés par un périmètre et une autorisation écrite. La fenêtre d’intervention, les actions exclues et les conditions d’arrêt sont convenues avant la mission. Un environnement de préproduction représentatif peut être privilégié. Aucun test actif n’est présenté comme dépourvu de risque.
Oui, systématiquement. Un NDA (accord de confidentialité) et une lettre d'autorisation de test signée sont établis avant toute intervention. Ces documents protègent les deux parties : vous êtes assurés que les résultats restent strictement confidentiels, et nous disposons de l'autorisation écrite légalement nécessaire pour conduire les tests.
La prochaine étape
Une application, une API ou un site à vérifier. Commençons par définir les tests utiles.
Autoriser PostHog à mesurer les pages et actions pour améliorer le site ? Des identifiants de navigateur et de session sont utilisés. Les champs du formulaire et les enregistrements de session sont exclus.
En savoir plus. Vous pouvez changer ce choix en bas de chaque page.
Votre navigateur demande de ne pas être suivi. PostHog reste désactivé.
