Vous préparez une mise en production
Vérifier les parcours qui exposeront des données ou donneront accès à de nouveaux utilisateurs.
Pentest SaaS · Web & API
Pentest SaaS : vérifiez les accès de vos clients.
Séparation entre clients, rôles et API : éprouvez votre application avant une mise en production, une nouvelle version ou pour répondre à une demande de votre client.
PNPT · HTB CWES · Paris & à distance
Le bon moment
Votre produit franchit une étape.
Votre produit change
Éprouver une nouvelle API, un nouveau rôle ou une évolution de l’authentification avant d’élargir son usage.
Un client demande un pentest
Clarifier ses attentes et le périmètre utile pour lui transmettre un rapport, avec les limites des vérifications.
Les tests utiles
Éprouver les frontières de votre application.
Les tests manuels partent des usages réels de votre produit. L’objectif : confirmer les risques exploitables et donner à votre équipe les corrections à prioriser.
Voir le pentest web & APISéparation entre clients
Un utilisateur peut-il consulter, exporter ou modifier les données d’un autre espace client en changeant une requête ou un identifiant ?
Rôles et permissions
Un membre peut-il agir comme un administrateur ? Les invitations, changements de rôle et accès support respectent-ils les droits prévus ?
API et sessions
Les contrôles restent-ils effectifs en appelant directement l’API ? Que permettent les jetons, sessions et mécanismes de récupération de compte ?
Parcours métier sensibles
Les règles tiennent-elles sur les exports, partages, abonnements ou opérations sensibles, y compris lorsque les étapes sont contournées ?
Ce que vous recevez
De quoi décider. De quoi corriger.
Une synthèse des risques pour vos décideurs. Pour vos développeurs : criticité, preuve, scénario d’exploitation, impact et recommandation. La restitution sert à discuter directement des constats et des priorités.
Après correction, le re-test consigne le statut des points convenus. Le rapport ci-contre illustre cette structure dans un laboratoire fictif.
Voir un exemple de rapport Yabee CorpExemple pédagogique
PENTEST WEB / ATELIER.LAB
Un salarié accède aux salaires de ses collègues.
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.
Technique illustréeIDOR · Accès direct à un document non autorisé
Modifier l’identifiant du document dans une requête authentifiée, puis vérifier les droits sur la ressource retournée.
01 / Confidentialité des documentsDémo fictive
200 OK · fichier de paie divulgué
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.
La requête révèle le défaut.
GET /api/documents/204200 OK · fichier de paie divulgué- 01Se connecter avec le compte de démonstration d’un salarié du service commercial.
- 02Remplacer le numéro d’un document commercial autorisé par celui du fichier de paie réservé aux RH.
- 03Constater que le serveur retourne les salaires alors que ce compte n’a aucun droit RH.
Vérifier le droit sur ce document.
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.
- Contrôle des droits sur chaque document demandé, et pas seulement de la connexion.
- Refus sans contenu ni métadonnée RH pour les comptes non habilités.
- Tests de régression avec un compte RH, un commercial et un compte sans session.
Protéger les RH. Garder leur accès.
GET /api/documents/204403 Forbidden · document RH protégé- Compte RH habilité200 · autorisé
- Salarié commercial403 · refusé
- Compte sans session401 · refusé
Ces résultats illustrent le re-test attendu. Ils ne correspondent pas à des tests réalisés chez un client.
Un bouton caché ne protège pas un export.
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.
Technique illustréeBFLA · Fonction accessible au mauvais rôle
Appeler directement une fonction d’administration avec un compte standard, même lorsque son bouton est masqué.
02 / Privilèges du compteDémo fictive
200 OK · export accessible
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.
La requête révèle le défaut.
GET /api/admin/users/export200 OK · export accessible- 01Se connecter avec un compte disposant uniquement du rôle standard.
- 02Appeler directement l’endpoint d’export de la console d’administration.
- 03Constater que masquer le bouton n’empêche pas l’API de retourner les données.
Contrôler la fonction côté serveur.
Centraliser les autorisations côté serveur et exiger le droit d’export sur l’endpoint d’administration.
- Refus par défaut pour les fonctions privilégiées.
- Contrôle du rôle et du droit spécifique avant d’exécuter l’export.
- Tests des endpoints d’administration pour chaque niveau de privilège.
Réserver l’export au bon rôle.
GET /api/admin/users/export403 Forbidden · rôle insuffisant- Administrateur autorisé200 · autorisé
- Utilisateur standard403 · refusé
- Session absente ou expirée401 · refusé
Le 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.
Le prix du panier ne se décide pas dans le navigateur.
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.
Technique illustréeParameter tampering · Manipulation du prix
Modifier le montant envoyé par le navigateur pour vérifier si le serveur le reprend ou le recalcule depuis son catalogue.
03 / Intégrité de la commandeDémo fictive
201 Created · commande à 1 €
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.
La requête révèle le défaut.
POST /api/orders
{ "productId": "AT-120", "quantity": 1, "unitPrice": 1 }201 Created · commande à 1 €- 01Ajouter au panier l’article fictif affiché à 120 €.
- 02Modifier le prix transmis par le navigateur à 1 €, sans changer le produit ni la quantité.
- 03Observer la commande créée à 1 € : le serveur a utilisé une valeur fournie par le client.
Recalculer depuis le catalogue.
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.
- Catalogue et règles de remise comme source des prix côté serveur.
- Validation des quantités et des remises applicables au compte.
- Montant cohérent entre commande et demande de paiement.
Facturer le montant autorisé.
POST /api/orders
{ "productId": "AT-120", "quantity": 1, "unitPrice": 1 }201 Created · prix recalculé à 120 €- Prix navigateur modifié à 1 €120 € · recalculé
- Quantité négative422 · refusée
- Remise autorisée de 10 %108 € · calculé
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.
Un contact direct
Vous échangez avec la personne qui réalise les tests.
Boris suit le cadrage, les tests, la restitution et le re-test. Vos développeurs peuvent discuter des scénarios et des corrections avec la personne qui a établi les constats.
PNPT
TCM Security · examen pratique
Un pentest réseau pratique, de la reconnaissance à l’exploitation d’un environnement Active Directory.
- Analyse du périmètre et des chemins d’attaque
- Rapport professionnel et restitution orale
Ce que cela apporte à votre mission
Présenter les preuves et expliquer les risques, avec un plan de correction compréhensible.
HTB CWES
Hack The Box · examen pratique
Un examen pratique consacré à l’exploitation d’applications web, de services et d’API.
- Failles web et enchaînement de vulnérabilités
- Preuves reproductibles et rapport exploitable
Ce que cela apporte à votre mission
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.
Le premier échange
Définir ce qui mérite d’être testé.
En 20 minutes, nous examinons votre contexte, les accès nécessaires et les parcours à couvrir. Vous n’avez pas besoin d’avoir déjà rédigé un périmètre technique.
- À préparer
- L’URL ou le type de produit, l’étape à venir et les attentes éventuelles de votre client.
- Avant les tests
- Périmètre, environnement, autorisation écrite, confidentialité et règles d’engagement validés ensemble.
- Sur devis
- La charge dépend des applications, API, rôles et parcours retenus.
Questions fréquentes
Avant de tester votre SaaS.
Questions / Réponses
05 points à éclaircir
Question 01 sur 05
Quels accès faut-il préparer pour un pentest SaaS ?
Selon le périmètre, des comptes correspondant aux différents rôles, au moins deux espaces clients de test, des données non sensibles et la documentation des API sont utiles. Nous précisons ensemble les accès nécessaires, les exclusions et l’autorisation écrite avant de commencer.
Peut-on tester une application en production ?
C’est possible si le contexte le permet. L’environnement, les horaires, les actions interdites et les contacts d’alerte sont convenus au cadrage. Les vérifications susceptibles de perturber le service peuvent être exclues ou réalisées sur un environnement de test. L’absence totale de perturbation ne peut pas être garantie.
Combien coûte et combien de temps dure un pentest SaaS ?
Le devis dépend du nombre d’applications et d’API, des rôles, des espaces clients et des parcours à vérifier. Le calendrier et les livrables sont précisés après ce cadrage. Une URL et une courte description de votre contexte suffisent pour lancer la discussion.
Le rapport peut-il être partagé avec un client ?
La synthèse présente les risques, les limites du périmètre et les priorités de correction. Les détails techniques peuvent contenir des informations sensibles : les destinataires, la confidentialité et les modalités de partage sont à convenir. Le rapport décrit les tests réalisés et ne constitue pas une certification de sécurité.
Que se passe-t-il après les corrections ?
Le re-test vérifie les constats corrigés prévus au périmètre et consigne leur statut. La fenêtre de 60 jours et les conditions exactes figurent dans la proposition. Une nouvelle fonctionnalité ou une modification importante peut nécessiter des tests complémentaires.
La prochaine étape
Quelle étape prépare votre SaaS ?
Décrivez votre application et le contexte. Nous définirons ensemble les tests utiles, les accès à prévoir et la suite du cadrage.