Quand je conduis un audit de sécurité sur un SaaS, ma grille de référence est invariable : c'est le Top 10 OWASP. Maintenu depuis 2003 par la fondation OWASP, ce référentiel international classe les dix catégories de vulnérabilités les plus critiques sur les applications web. Pour un éditeur SaaS, c'est à la fois un outil de cadrage interne, un argument commercial face à un client B2B exigeant, et la base de toute démarche de durcissement structurée. Voici les 10 catégories de l'édition 2021 (toujours en vigueur), comment Symfony en traite nativement une partie, et un zoom sur les trois plus critiques pour un éditeur SaaS en 2026.
Le Top 10 OWASP en un coup d'œil
Voici les dix catégories de l'édition 2021, avec pour chacune une explication courte et la manière dont Symfony en couvre nativement une partie.
| Code | Catégorie | En une ligne | Traitement Symfony |
|---|---|---|---|
| A01 | Broken Access Control | Un utilisateur accède à des ressources qui ne lui appartiennent pas | Voters Symfony Security, attribut #[IsGranted] |
| A02 | Cryptographic Failures | Données sensibles non chiffrées ou mal chiffrées | Hashage de mot de passe via UserPasswordHasher, TLS imposé |
| A03 | Injection | Injection SQL, NoSQL, OS command, LDAP | Doctrine ORM avec requêtes paramétrées par défaut, escape Twig auto |
| A04 | Insecure Design | Faille structurelle dans la conception, pas dans le code | Pas de bundle magique : impose une revue d'architecture |
| A05 | Security Misconfiguration | Headers manquants, debug en prod, secrets exposés | nelmio/security-bundle, APP_ENV=prod, secrets vault |
| A06 | Vulnerable and Outdated Components | Dépendances avec CVE connues | composer audit, Dependabot, npm audit |
| A07 | Identification and Authentication Failures | Authentification faible, session non sécurisée | Symfony Security, rate limiter natif, 2FA via scheb/2fa-bundle |
| A08 | Software and Data Integrity Failures | Mises à jour non vérifiées, désérialisation non sécurisée | Composer signe les paquets, sérialisation contrôlée par symfony/serializer |
| A09 | Security Logging and Monitoring Failures | Pas de log des événements sécurité, pas d'alertes | Monolog + canal sécurité dédié, Sentry pour les alertes |
| A10 | Server-Side Request Forgery (SSRF) | Le serveur fait des requêtes vers des URLs contrôlées par l'attaquant | Validation des URLs, allowlist côté http_client |
Symfony couvre nativement une bonne partie des défenses, mais aucun framework ne résout le Top 10 tout seul. La conception (A04) et la configuration (A05) restent à la charge de l'éditeur.
Les 3 catégories les plus critiques pour un SaaS éditeur
Sur tous les audits que j'ai conduits ces dernières années, trois catégories concentrent la majorité des incidents réels. Ce sont aussi celles qui sont en tête du Top 10 OWASP, et ce n'est pas un hasard.
A01 - Broken Access Control : le piège du multi-tenant
C'est le numéro un dans les SaaS multi-tenant. Un utilisateur du tenant A modifie l'identifiant dans l'URL et accède aux données du tenant B. L'OWASP estime que 94 % des applications testées ont au moins un défaut de contrôle d'accès. La parade en Symfony est claire : Voters systématiques sur chaque ressource, attribut #[IsGranted] sur les contrôleurs, et filtres Doctrine SQL qui imposent le tenant_id à toutes les requêtes. Cette défense en profondeur est détaillée dans mon article sur l'architecture multi-tenant SaaS.
A02 - Cryptographic Failures : chiffrement des données sensibles
Les défaillances cryptographiques recouvrent trois fronts : le mot de passe (qui doit être hashé avec un algo moderne type Argon2id ou bcrypt), les données sensibles en base (chiffrement au niveau colonne ou disque selon la criticité), et le transport (TLS 1.2 minimum, idéalement 1.3, sans cipher faible). Symfony hashe correctement par défaut. Mais le chiffrement des colonnes sensibles (numéros de sécurité sociale, IBAN, données médicales) reste à coder explicitement. C'est typiquement le terrain où l'éditeur SaaS se croit protégé alors qu'il ne l'est pas.
A03 - Injection : SQL, command, template
L'injection est la catégorie historiquement la plus médiatisée. Sur un SaaS Symfony, l'usage strict de Doctrine ORM avec requêtes paramétrées et l'auto-escape de Twig couvrent l'essentiel. Les pièges résiduels : les requêtes natives en DBAL mal paramétrées, les command injections via Process sans validation, et les SSTI (Server Side Template Injection) si on rend du Twig avec une chaîne contrôlée par l'utilisateur. Une revue de code orientée injection prend 2 à 4 heures sur un SaaS de taille moyenne et lève l'essentiel des risques.
Les outils d'audit OWASP utilisables sur un SaaS Symfony
Trois outils complémentaires couvrent la majorité des besoins.
- OWASP ZAP : scanner gratuit et open source, maintenu par la fondation OWASP. C'est mon premier réflexe sur tout SaaS pré-production. Il détecte les défauts de configuration, les XSS classiques, les injections les plus visibles. Bien adapté à un usage récurrent en CI.
- Burp Suite : la référence côté pentest professionnel. La version Community suffit pour un audit ciblé, la version Pro est utile pour le scan automatisé avancé. Plus puissant que ZAP sur les flux complexes (multi-step, JWT, GraphQL).
- Audit manuel orienté code : aucun scanner ne remplace une lecture humaine du code. Sur un SaaS Symfony, je relis systématiquement les Voters, les Listeners de sécurité, les requêtes natives DBAL, et les appels à
ProcessouHttpClient. C'est typiquement là que se cachent les défauts qu'aucun outil ne voit.
Pour la chaîne de dépendances (A06), composer audit et npm audit sont à intégrer en CI. Sur les SaaS que je maintiens, ils tournent à chaque pull request, et un échec bloque la fusion.
De l'OWASP à l'audit complet : le pas suivant
Le Top 10 OWASP est un excellent point d'entrée, mais ce n'est qu'un référentiel parmi d'autres. Sur un SaaS B2B, il se complète avec : un audit RGPD (voir ma checklist RGPD SaaS 2026), un audit cybersécurité opérationnel (voir ma checklist cybersécurité TPE), et selon le secteur, une analyse de conformité sectorielle (HDS pour la santé, PCI-DSS pour le paiement).
D'expérience, sur les SaaS B2B éditeurs, le combo OWASP + RGPD + checklist opérationnelle couvre plus de 90 % du risque exploitable. Les 10 % restants sont des risques résiduels qui demandent un pentest ciblé conduit par un cabinet spécialisé, à programmer une fois la base solide.
Cadrer un audit OWASP formalisé sur votre SaaS
Un audit OWASP formalisé débouche sur un rapport hiérarchisé par criticité, des correctifs priorisés en sprints courts, et un plan de durcissement à 3 et 6 mois. Sur un SaaS Symfony de taille moyenne, ça tient sur quelques jours, avec un livrable que vous pouvez présenter à un client B2B exigeant ou à un prospect grand compte.
Comme tous mes audits, le périmètre est défini sur devis personnalisé après un échange initial gratuit de 30 minutes. Pour comprendre comment la sécurité s'inscrit dans le cycle complet d'un projet SaaS, mon guide du développement SaaS sur-mesure détaille les six étapes de cadrage, conception, développement, sécurisation, mise en production et maintenance. Le formulaire de contact permet de prendre date.
