Un pentest SaaS utile commence par des questions métier testables et des accès fonctionnels. La préparation détermine si l’auditeur pourra examiner rôles, tenants et workflows critiques plutôt que reconstruire des comptes pendant la mission.
L’exemple suivant est un SaaS de rapports fictif. Domaines et comptes sont des placeholders de cadrage, pas des systèmes à tester. Le NIST SP 800-115 fournit une référence pour planifier les évaluations, analyser les constats et préparer la réduction des risques ; la matrice proposée est une application illustrative.
Définir la décision et la version
Remplacer « tester l’application » par une décision : cette version peut-elle exposer l’export de rapports aux clients entreprise ? Identifier les parcours associés : login, invitations, création, publication, génération d’export et téléchargement.
Relever release/build, configuration, feature flags et écarts entre staging et production. Un test staging ne démontre pas implicitement la sécurité d’un autre fournisseur d’identité, d’une autre politique de stockage ou d’un autre déploiement de worker en production.
Rendre le périmètre concret
Notre exemple utilise le staging et des données synthétiques. Production et prestataires tiers sont exclus. Les intégrations côté application restent évaluées ; l’infrastructure propre d’un prestataire de paiement ou d’identité ne l’est pas.
| Surface | Préparation et limite |
|---|---|
app.example.test |
Membre A, admin A, membre B. Objectif : login, invitations, rôles. Aucun compte client réel. |
api.example.test |
Jetons distincts pour les trois identités. Objectif : isolation et champs privilégiés. Objets A/B préparés uniquement. |
| worker d’export | Mise en file et corrélation des logs. Objectif : autorisation avant production. Jobs synthétiques bornés. |
| stockage | Liens de test émis par l’application. Objectif : isolation et expiration. Bucket de test désigné. |
Ajouter chemins de base API, protocoles et responsables. Un wildcard ne suffit pas à identifier services sous-traités et infrastructure partagée. Définir explicitement actions exclues et collecte de preuves permise.
Construire la matrice comptes et données
Le nom du rôle ne suffit pas. Préparer appartenances et objets pour distinguer les frontières de rôle et de propriété :
| Identité | Appartenance, droits et données |
|---|---|
member_A |
A ; lire A et modifier ses brouillons. Préparer son brouillon et un autre rapport A. |
admin_A |
A ; publier/exporter A. Préparer un brouillon prêt à publier. |
member_B |
B ; lire B et modifier ses brouillons. Préparer un brouillon B avec ID connu. |
Ces droits fictifs correspondent à l’exemple multi-tenant. Préparer aussi invitation, appartenance révocable et artefacts jetables pour les transitions.
Employer des comptes dédiés avec MFA et récupération réalistes. Transmettre les secrets par le canal convenu, jamais dans un rapport public ou un ticket ouvert. Confirmer les refresh tokens et la révocation finale des comptes.
Définir les conditions de test
Documenter fenêtres, IP sources, limites de requêtes et concurrence, WAF, rate limiting, uploads permis et jobs asynchrones. Ne pas désactiver globalement les contrôles sans documenter la couverture perdue. Si le rate limiting de production n’est pas représentable, le préciser.
Nommer un contact applicatif et un suppléant pouvant arrêter les tests. Définir des conditions observables : données client rencontrées ou pression de ressources inattendue. Déterminer qui autorise la reprise et comment annuler ou vider les jobs en attente.
Conserver les logs avec IDs de corrélation, vérifier les sauvegardes pertinentes et attribuer le nettoyage. « Supprimer les données de test » inclut artefacts, messages en file, invitations et identifiants temporaires.
Vérifier la préparation
Avant le début de l’évaluation, contrôler que :
- Chaque identité réalise son login et son MFA prévus.
- Les opérations légitimes fonctionnent sur les données préparées.
- A et B ont des objets distincts, aux propriétaires et états connus.
- Build, périmètre, exclusions et limites sont documentés.
- Une requête est corrélable à son export et à son artefact.
- Contacts d’urgence et procédure d’arrêt ont été exercés.
- Nettoyage, responsables de correction et accès de retest sont convenus.
Un compte admin indisponible empêche d’évaluer correctement sa frontière ; cela ne constitue pas un contrôle de sécurité réussi. Avancer sur les tests indépendants, documenter la couverture réduite et restaurer l’accès avant de déclarer cet objectif évalué.
Préparer la correction avant le rapport
Définir le contenu du ticket : build affecté, preuve minimale nettoyée, cause racine, impact, responsable et critères de clôture. Conserver les comptes pour le retest, puis les révoquer et supprimer les données préparées.
Le guide constat-remédiation-retest aide à définir la preuve de clôture. La préparation réussit quand la mission teste les frontières prévues, explique ses limites et fournit un travail vérifiable.