Zero Trust pour petite équipe SaaS : les failles à tester

La faille de fond : la confiance implicite

Une petite équipe SaaS se construit vite, et la sécurité repose souvent sur des hypothèses non écrites : « cette route n’est appelée que par notre front », « ce service n’est pas exposé », « seuls les développeurs ont ce lien ». Chaque hypothèse de ce type est une porte ouverte le jour où elle devient fausse. Voici les cinq formes qu’on rencontre le plus.

1. Les API dites internes

Un endpoint d’administration, un cron appelé en HTTP, un webhook de traitement : ils sont souvent déployés sur le même domaine que l’application, sans authentification, en comptant sur le fait que personne ne connaît l’URL. Les URL fuient par le bundle JavaScript, les sitemaps, les journaux d’un outil tiers ou un simple scan.

Variante fréquente : un contrôle basé sur un en-tête que le client peut forger (X-Forwarded-For: 127.0.0.1, X-Internal: true) ou sur l’adresse IP source derrière un proxy.

2. Une clé de service partagée

La clé service_role de Supabase, une clé AWS administrateur ou un jeton de base de données copié dans le .env de chaque développeur, dans la CI et parfois dans le front. Cette clé ignore toutes les règles d’autorisation. Une seule copie qui fuit suffit. Voir les variables NEXT_PUBLIC qui exposent des secrets et les secrets dans l’historique Git.

3. Les accès permanents à la production

Tous les développeurs ont un accès direct à la base de production, sans limite de durée. Un poste compromis par un infostealer donne alors l’accès complet aux données clients.

4. Des environnements qui se font confiance

Les déploiements de préproduction ou de prévisualisation utilisent la même base, les mêmes clés ou le même fournisseur d’identité que la production, mais avec des protections plus faibles (pas d’authentification, mode debug).

5. Des comptes d’outils sans MFA

GitHub, l’hébergeur, le tableau de bord Supabase ou Firebase, la messagerie : un seul de ces comptes sans second facteur donne la main sur l’infrastructure.

Comment le tester

Ces tests se font avec un navigateur, curl et vos consoles d’administration :

1. Cartographie des routes. Extrayez toutes les URL d’API présentes dans votre bundle front (recherche de /api/ dans les fichiers .js servis). Appelez chacune sans session. Toute réponse autre que 401 ou 403 sur une route qui manipule des données est une faille.
2. En-têtes de confiance. Rejouez une requête refusée en ajoutant X-Forwarded-For: 127.0.0.1, X-Real-IP: 127.0.0.1 ou un en-tête interne que votre code consulte. Si le résultat change, l’autorisation dépend d’une donnée contrôlée par le client.
3. Recherche de clés. Cherchez dans le bundle front, les dépôts et la CI les chaînes service_role, AKIA, sk_live, postgres://. Une clé de service dans le front est une faille critique.
4. Inventaire des accès production. Listez les personnes et les jetons qui peuvent lire la base de production. Comparez avec la liste de ceux qui en ont réellement besoin cette semaine.
5. Préproduction. Ouvrez une URL de prévisualisation sans être connecté. Vérifiez qu’elle n’utilise pas la base ou les clés de production.
6. MFA des outils. Dans GitHub, l’hébergeur et le fournisseur cloud, exportez la liste des membres et vérifiez que le second facteur est imposé au niveau de l’organisation.
7. Journaux. Faites un export de test depuis la base de production et vérifiez que l’événement apparaît dans un journal consulté par quelqu’un.

Comment corriger

• Authentifiez chaque route, y compris les crons et webhooks (secret partagé, signature HMAC, jeton de service à portée limitée). Ne fondez jamais une décision d’accès sur l’IP ou un en-tête forgeable.
• Retirez les clés de service des postes. Gardez-les dans un gestionnaire de secrets (Doppler, Infisical, le coffre de votre cloud), limitées au serveur, et faites-les tourner.
• Accès production à la demande : une ou deux personnes par défaut, accès temporaire validé pour les autres, avec un outil type Teleport ou un script maison.
• Séparez réellement les environnements : bases, clés et projets distincts, prévisualisations protégées par authentification.
• Imposez le MFA au niveau de l’organisation sur chaque outil. Voir aussi les erreurs IAM sur AWS, GCP et Azure.
• Revue trimestrielle des accès, avec révocation de ce qui ne sert plus.

Ce que ça change quand un agent IA entre dans l’équipe

Un agent IA qui a accès au dépôt, au ticketing, à la base ou à la messagerie est un nouvel acteur à qui l’on accorde souvent une confiance implicite maximale : une clé administrateur « pour que ça marche », des outils qui exécutent ce que le modèle demande sans autre contrôle. Or le modèle lit des contenus extérieurs (e-mails, tickets, pages web, documents) qui peuvent contenir des instructions cachées.

Le principe Zero Trust s’applique donc à l’agent comme à un prestataire : identité propre, droits minimaux par outil, aucune clé de service, autorisation vérifiée dans l’outil et non dans le prompt, confirmation humaine pour les actions irréversibles, et journalisation de chaque appel. Notre article sur la surface d’attaque du function calling détaille ces points.

Pour vérifier qu’un agent ne contourne pas ces barrières, le Red Team Agent Express l’attaque pendant cinq jours avec les techniques d’injection réellement utilisées.