Les vulnérabilités les plus fréquentes dans les applications SaaS

Les applications SaaS partagent une architecture similaire (API REST ou GraphQL, front en JavaScript, base relationnelle multi-tenant, services managés) et, avec elle, une famille de défauts récurrents. Ce qui suit décrit les mécanismes et les causes, sans détailler de procédure d’exploitation.

1. Le contrôle d’accès horizontal défaillant (IDOR)

C’est, de loin, le constat le plus fréquent. Un identifiant de ressource circule dans une URL, un paramètre ou un corps de requête ; le serveur vérifie que l’utilisateur est authentifié, mais oublie de vérifier qu’il a le droit d’accéder à cette ressource précise.

Le mécanisme est simple, mais sa cause l’est moins. Elle est presque toujours architecturale : la vérification d’appartenance est écrite point d’entrée par point d’entrée, à la main. Sur une application de trente endpoints, la discipline tient. Sur trois cents, une omission finit par se produire, généralement dans une fonctionnalité secondaire ajoutée tardivement : export CSV, prévisualisation de pièce jointe, endpoint de duplication, webhook de rappel.

La correction durable ne consiste pas à ajouter la vérification manquante, mais à déplacer le contrôle : filtrer systématiquement par organisation au niveau de la couche d’accès aux données, de sorte qu’une requête oubliée ne renvoie rien plutôt que de tout renvoyer. Le défaut par défaut doit être le refus.

2. L’authentification et la gestion des sessions

Les défauts d’authentification les plus courants ne concernent pas l’algorithme de hachage des mots de passe, aujourd’hui correctement choisi dans la plupart des projets, mais les parcours périphériques :

• La réinitialisation de mot de passe : jeton à durée de vie trop longue, jeton non invalidé après usage, jeton prévisible, ou fuite du jeton dans l’en-tête Referer vers un service tiers.
• L’invalidation de session : la déconnexion supprime le cookie côté navigateur mais le jeton reste valide côté serveur ; un changement de mot de passe ne révoque pas les sessions existantes.
• Le second facteur contournable : l’étape de vérification est appliquée à l’interface web mais pas à l’API, ou pas aux jetons applicatifs de longue durée.
• L’énumération de comptes : les messages d’erreur ou les temps de réponse permettent de savoir si une adresse est enregistrée, ce qui alimente les campagnes de bourrage d’identifiants.

Sur un SaaS B2B, il faut y ajouter la surface introduite par le SSO. Une intégration SAML ou OIDC mal validée (signature non vérifiée, audience non contrôlée, association de compte fondée uniquement sur l’adresse e-mail) permet dans certains cas de se faire passer pour un utilisateur d’une autre organisation.

3. La séparation multi-tenant

Distincte de l’IDOR classique, cette catégorie couvre les cas où la frontière entre clients est franchie par un chemin détourné : cache partagé dont la clé n’intègre pas l’identifiant d’organisation, tâche de fond exécutée sans contexte de tenant, index de recherche global, moteur de rapports acceptant un filtre fourni par le client, fichier stocké sous un nom prévisible dans un espace commun.

Ces défauts échappent souvent aux tests automatisés parce qu’ils ne se manifestent qu’avec deux organisations réellement peuplées de données. Ils justifient à eux seuls de fournir aux auditeurs deux jeux de comptes dans deux tenants distincts.

4. Les requêtes côté serveur non maîtrisées (SSRF)

Dès qu’une application accepte une URL fournie par l’utilisateur et va la consulter elle-même (import depuis un lien, webhook sortant, vérification d’un domaine, génération d’aperçu, récupération d’un avatar distant), elle offre un point d’appui pour atteindre des ressources internes normalement inaccessibles depuis Internet.

Le risque est particulièrement élevé en environnement cloud, où des services de métadonnées internes sont joignables depuis les instances. Les protections partielles sont nombreuses et peu fiables : une liste noire d’adresses privées est contournable par redirection, par notation alternative ou par un nom de domaine qui résout vers une adresse interne. Les approches robustes reposent sur une liste blanche de destinations, la résolution DNS effectuée en amont puis figée, l’usage d’un proxy sortant dédié, et le refus des redirections.

5. Les dépendances et la chaîne de construction

La majorité du code exécuté par une application SaaS n’a pas été écrite par l’équipe. Les constats récurrents portent moins sur des bibliothèques spectaculairement vulnérables que sur l’absence de processus : aucune surveillance des avis de sécurité, versions figées depuis deux ans, dépendances de développement embarquées dans l’image de production, ou fichier de verrouillage absent, ce qui rend les builds non reproductibles.

Le pipeline de construction lui-même mérite attention : jetons d’accès trop permissifs, exécution de code arbitraire depuis une contribution externe, artefacts non signés.

6. Les données exposées sans intention

Trois classes reviennent régulièrement : les secrets dans le dépôt (clés d’API, identifiants de service, jetons de webhook, y compris dans l’historique Git après « suppression ») ; les réponses d’API trop bavardes, où un endpoint sérialise l’objet entier alors que l’interface n’en affiche que trois champs, exposant au passage des adresses, des identifiants internes ou des indicateurs de facturation ; et les environnements de recette accessibles publiquement, souvent peuplés d’une copie des données de production.

7. L’injection, sous ses formes actuelles

L’injection SQL classique a nettement reculé grâce aux ORM et aux requêtes préparées, mais elle réapparaît dans les zones où le développeur reprend la main : construction dynamique d’une clause de tri, filtres avancés, requêtes de reporting, recherche plein texte.

À côté, deux formes se sont banalisées avec les architectures modernes. L’injection de template côté serveur, quand un modèle de document ou d’e-mail personnalisable est rendu par un moteur trop puissant. Et les injections dans les moteurs NoSQL ou de recherche, où un objet transmis en JSON est interprété comme un opérateur plutôt que comme une valeur.

Pourquoi ces défauts persistent

Aucune de ces catégories n’est nouvelle ; toutes figurent dans les référentiels publics depuis des années. Leur persistance s’explique par trois facteurs structurels.

D’abord, la sécurité applicative est un problème de couverture, pas de connaissance. Une équipe peut parfaitement savoir ce qu’est un IDOR et en laisser passer un sur le trois-centième endpoint.

Ensuite, les outils automatisés détectent mal les défauts de logique métier. Un scanner sait repérer une bibliothèque obsolète, pas qu’un utilisateur « lecteur » peut modifier la facturation.

Enfin, la dette de sécurité est invisible tant qu’elle n’est pas exploitée. Contrairement à un bug fonctionnel, elle ne génère aucun ticket de support. C’est précisément ce que l’audit rend visible.