Nouvelle offre · Attaquer
Test d'intrusion SaaS : prouvez à vos clients que leurs données sont étanches.
Plateforme, application ou logiciel SaaS : vos clients partagent la même infrastructure, et une seule faille de cloisonnement suffit à exposer tous les autres. Nos experts seniors attaquent votre SaaS comme le ferait un client malveillant ou un attaquant externe, démontrent l'impact réel, puis vérifient vos correctifs. Vous repartez avec un rapport clair et une attestation à présenter à vos prospects.
L'enjeu
Une faille SaaS touchetous vos clients.
Changer un identifiant dans une requête et lire les factures d'une autre entreprise. Inviter un utilisateur et lui donner, sans le vouloir, les droits d'administrateur. Ces failles ne se voient pas dans un scanner automatique : elles se cachent dans la logique de votre produit. Et le jour où elles sont exploitées, ce n'est pas un client que vous perdez, c'est la confiance de tous. Les grands comptes le savent : ils exigent désormais un test d'intrusion récent avant de signer, et la directive NIS2 pousse leurs fournisseurs dans le même sens.
Ce que nous attaquons
Huit surfaces,propres au SaaS.
Notre méthode suit l'OWASP WSTG et l'API Security Top 10, mais elle ne s'arrête pas à une liste de contrôles : nous enchaînons les failles jusqu'à l'impact métier, comme le ferait un attaquant motivé.
-
Cloisonnement multi-tenant
Accès aux données, fichiers ou exports d'un autre client par manipulation d'identifiants, de sous-domaines ou de jetons.
Le risque : une fuite qui touche tous vos clients à la fois.
-
Authentification et SSO
Connexion, MFA, réinitialisation de mot de passe, sessions, fédération d'identité OIDC et SAML, provisioning SCIM.
Le risque : la prise de contrôle de comptes, jusqu'aux administrateurs.
-
Rôles et permissions
Élévation de privilèges entre rôles, invitations, délégations, comptes de support et accès internes à votre back-office.
Le risque : un simple utilisateur qui agit comme administrateur.
-
API publiques et internes
REST et GraphQL, clés d'API, limites de débit, objets exposés en trop, routes non documentées utilisées par vos applications.
Le risque : contourner l'interface et aspirer les données en masse.
-
Logique métier et facturation
Abonnements, quotas, essais gratuits, paiements, workflows de validation : tout ce qu'un client malin pourrait détourner.
Le risque : une perte de revenus et des fonctions payantes obtenues gratuitement.
-
Intégrations et webhooks
Imports de fichiers, connecteurs tiers, webhooks, génération de PDF et aperçus de liens qui font appeler vos serveurs.
Le risque : rebondir de votre application vers votre cloud interne.
-
Fonctions d'IA embarquées
Assistants, résumés et agents intégrés à votre produit : injection de prompt, fuite de données entre clients, actions non autorisées.
Le risque : une IA qui révèle ce qu'elle n'aurait jamais dû voir.
-
Cloud, secrets et CI/CD
Stockage exposé, secrets dans le code ou les images, droits cloud trop larges, chaîne de déploiement et environnements de recette oubliés.
Le risque : la compromission de toute la plateforme, pas d'un seul compte.
Le déroulé
Du cadrage à l'attestation,sans surprise.
Un périmètre écrit, des règles d'engagement signées et un interlocuteur unique du premier échange au re-test. Vos équipes savent à chaque étape ce qui est testé, quand et comment.
Cadrage
Périmètre, environnements, fenêtres de test et contacts d'urgence fixés dans une convention d'audit.
Comptes de test
Au moins deux tenants et plusieurs rôles par tenant, pour attaquer le cloisonnement dans les deux sens.
Attaque
Tests manuels par des experts seniors, en boîte noire, grise ou blanche, appuyés par nos propres outils.
Restitution
Rapport chiffré, synthèse pour la direction et séance de travail avec vos développeurs.
Re-test et attestation
Vérification des correctifs, puis attestation à présenter à vos clients et prospects.
Les failles critiques sont signalées dès leur découverte, sans attendre le rapport final.
Ce que vous recevez
Un rapport pour votre CTO,une preuve pour vos clients.
Vos développeurs trouvent de quoi reproduire et corriger chaque faille. Votre direction comprend le risque en une page. Vos commerciaux ont enfin une réponse solide à la question « avez-vous fait un test d'intrusion ? ».
- Synthèse pour la direction, sans jargon
- Chaque faille avec score CVSS, preuves et impact métier
- Correctifs priorisés, adaptés à votre stack
- Attestation de test et de re-test pour vos clients
Accès aux documents d'un autre client par modification d'identifiant
L'API vérifie que l'utilisateur est connecté, mais pas que le document demandé appartient à son organisation. En faisant varier l'identifiant, un client peut télécharger les documents de tous les autres.
Le bon moment
Quand la sécuritéfait signer.
Un test d'intrusion n'est pas qu'une dépense de sécurité. Pour un éditeur SaaS, c'est souvent la pièce qui débloque une signature ou un financement.
-
Avant un grand compte
Questionnaire sécurité, annexe contractuelle, exigences NIS2 ou DORA de votre client sur sa chaîne d'approvisionnement.
Vous obtenez une preuve indépendante et récente, prête à joindre.
-
Avant une levée ou une cession
Les fonds et les acquéreurs regardent de près la dette de sécurité pendant la due diligence.
Vous arrivez avec vos failles déjà connues, corrigées et documentées.
-
Après une évolution majeure
Nouvelle architecture, nouvelle API, ouverture du SSO ou ajout de fonctions d'IA générative.
Vous livrez sans ouvrir de porte que personne n'a encore vue.
-
Pour votre certification
ISO 27001, SOC 2 ou NIS2 : le test d'intrusion régulier fait partie des preuves attendues par l'auditeur.
Vous cochez l'exigence avec un livrable que l'auditeur reconnaît.
- Production préservéetests calibrés, recette possible, fenêtres convenues
- Experts seniorspas de scanner revendu comme un test d'intrusion
- Confidentialitérapport chiffré, données détruites en fin de mission
- Re-test inclusla preuve que vos correctifs tiennent
Questions fréquentes
Vos questions,nos réponses.
Une question qui n'est pas ici ? Écrivez-nous à contact@soya-cyber.fr.
Qu'est-ce qu'un test d'intrusion SaaS ?
C'est un test d'intrusion centré sur ce qui est propre aux plateformes SaaS : le cloisonnement entre clients (multi-tenant), l'authentification et le SSO, les rôles, les API, la logique métier et la facturation, les intégrations et l'infrastructure cloud. Des experts attaquent votre application avec des comptes de test sur plusieurs tenants pour vérifier qu'un client ne peut jamais accéder aux données d'un autre.
Combien de temps dure un test d'intrusion d'application SaaS ?
Le plus souvent entre cinq et quinze jours de test, selon le nombre de fonctionnalités, de rôles et d'API. La durée exacte est fixée lors du cadrage, avant tout démarrage, et le re-test des correctifs est planifié dès le départ.
Faut-il tester en production ou en recette ?
Les deux sont possibles. Un environnement de recette fidèle à la production est idéal pour les tests les plus intrusifs. Si le test a lieu en production, les techniques, les fenêtres d'intervention et les contacts d'urgence sont définis par écrit pour préserver la disponibilité du service et les données de vos clients.
De quoi avez-vous besoin pour commencer ?
D'un périmètre (URL, API, applications mobiles éventuelles), d'au moins deux tenants de test avec plusieurs rôles chacun, et d'une documentation d'API si elle existe. En boîte blanche, un accès au code source permet d'aller plus loin dans le même temps.
L'attestation est-elle acceptée par nos clients ?
L'attestation précise le périmètre, les dates, la méthode et le statut des failles après re-test, sans révéler de détail exploitable. Elle répond aux demandes habituelles des questionnaires sécurité, des annexes contractuelles et des audits ISO 27001, SOC 2 ou NIS2.
Testez-vous aussi les fonctions d'IA intégrées au produit ?
Oui. Assistants, agents et résumés automatiques sont testés contre l'injection de prompt, la fuite de données entre clients et les actions non autorisées, avec la même exigence de cloisonnement que le reste de la plateforme.