Versions et dépendances
6 constats, dont 1 critique. Symfony et PHP hors support, 14 dépendances vulnérables.
Exemple de rapport d’audit Symfony
Voici ce que vous recevez à l’issue d’un audit Symfony : la structure, le niveau de détail et le ton d’un rapport réel.
Exemple représentatif
Ce rapport est construit à partir de constats que nous rencontrons régulièrement. L’application décrite est un cas type : elle ne correspond à aucun client, et aucune donnée réelle n’y figure. Nos audits sont couverts par un accord de confidentialité.
1. L’application auditée
- Type : extranet métier, avec gestion de dossiers et exports
- Taille : environ 120 000 lignes de PHP
- Socle : Symfony 4.4, PHP 7.4, MySQL 5.7
- Ancienneté : en production depuis 7 ans
- Historique : deux prestataires successifs, le dernier n’est plus disponible
- Documentation : partielle, non tenue à jour
- Tests automatisés : quasi inexistants
Demande du client : savoir si l’application peut être reprise et remise à niveau, ou s’il faut la réécrire.
2. Synthèse de direction
L’application fonctionne et rend le service attendu. Sa base de code est saine dans l’ensemble : une réécriture n’est pas justifiée.
Elle repose en revanche sur un socle qui n’est plus maintenu, et l’audit relève 29 constats, dont 3 critiques :
- Le socle technique ne reçoit plus de correctifs de sécurité (SYM-02)
- Des identifiants de production sont lisibles dans le dépôt de code (SYM-07)
- L’export des dossiers n’est pas cloisonné entre utilisateurs (SYM-08)
Les deux derniers se corrigent en quelques jours et doivent l’être sans attendre. Le premier demande une remise à niveau par paliers, à préparer par des tests.
Charge totale estimée : 25 à 35 jours, répartis sur 3 mois, hors améliorations de fond traitées ensuite en maintenance.
3. État par domaine
29 constats au total, dont 3 critiques.
Sécurité applicative
5 constats, dont 2 critiques. Secrets dans le dépôt, export non cloisonné.
Architecture
7 constats. Logique métier dans les contrôleurs, code mort.
Données et performance
4 constats. Requêtes coûteuses, index manquants.
Tests et qualité
3 constats. Parcours critiques non testés.
Exploitation
4 constats. Déploiement manuel, sauvegardes non testées.
Lecture des états : « Critique » signale un risque avéré pour la production ou les données. « À corriger » demande une action dans les prochains mois. « À surveiller » est sans urgence, à traiter en maintenance.
4. Plan d’action priorisé
La criticité d’un constat mesure le risque. La priorité d’une action fixe l’ordre de traitement, en tenant compte des dépendances entre actions.
À traiter immédiatement
- 1. Renouveler les secrets et les sortir du dépôt Git (SYM-07) : 1 jour, immédiat
- 2. Cloisonner l’export des dossiers et revoir les accès voisins (SYM-08) : 2 jours, sous 15 jours
- 3. Écrire les tests fonctionnels des 8 parcours critiques (SYM-23) : 5 jours, avant la migration
À traiter sous 3 mois
- 4. Monter Symfony et PHP par paliers, 5.4 puis 6.4 puis 7.4 (SYM-01, SYM-02) : 10 à 14 jours, après l’action 3
- 5. Remplacer les paquets abandonnés (SYM-03, SYM-04) : 2 jours, après l’action 4
- 6. Optimiser les 5 requêtes les plus coûteuses et ajouter les index (SYM-19, SYM-20) : 3 jours
- 7. Mettre en place un déploiement reproductible (SYM-26) : 2 jours
- 8. Externaliser les sauvegardes et tester une restauration (SYM-27) : 1 jour
- 9. Désactiver l’affichage des erreurs détaillées en production (SYM-09) : 1 jour
- 10. Ajouter l’analyse statique au processus de livraison (SYM-24) : 1 jour
Au fil de l’eau, en maintenance
- 11. Extraire la logique métier des contrôleurs (SYM-12 à SYM-15)
- 12. Supprimer le code mort et les bundles inutilisés (SYM-16, SYM-17)
- 13. Centraliser les logs et poser des alertes (SYM-28, SYM-29)
- 14. Mettre à jour la documentation technique (SYM-18)
Total P1 et P2 : 28 à 32 jours. Les actions P3 ne sont pas chiffrées : elles sont absorbées progressivement par la maintenance.
5. Fiches de constat
Chaque constat du rapport fait l’objet d’une fiche identique. Voici les trois fiches critiques.
SYM-02 : Socle hors support de sécurité
Constat : L’application tourne sous Symfony 4.4 et PHP 7.4, deux versions qui ne reçoivent plus de correctifs de sécurité. 14 dépendances présentent des vulnérabilités publiées, dont 3 classées élevées.
Comment nous l’avons vu : Analyse du composer.lock, audit des dépendances, relevé des dépréciations dans les logs.
Risque : Les failles découvertes ne seront plus corrigées. Plus la montée de version est repoussée, plus elle coûte cher, et l’hébergeur finira par retirer cette version de PHP.
Recommandation :
- Monter par paliers : 5.4, puis 6.4, puis 7.4
- Traiter les dépréciations à chaque étape
- Pas de migration directe
Charge estimée : 10 à 14 jours Priorité : P2. Le risque est critique, mais la migration ne peut pas démarrer sans les tests de l’action 3.
SYM-07 : Secrets de production dans le dépôt Git
Constat : Le fichier .env.prod est versionné. Il contient le mot de passe de la base de production, la clé APP_SECRET, les identifiants SMTP et la clé d’une API tierce. Ces valeurs figurent aussi dans l’historique du dépôt depuis 4 ans.
Comment nous l’avons vu : Recherche de secrets dans le code et dans l’historique Git, relevé des personnes ayant accès au dépôt.
Risque : Toute personne ayant eu accès au dépôt, y compris d’anciens intervenants, peut se connecter à la base de production ou utiliser les services tiers au nom de l’entreprise. Supprimer le fichier ne suffit pas : les valeurs restent lisibles dans l’historique.
Recommandation :
- Renouveler tous les secrets concernés, sans exception : c’est la seule mesure qui annule le risque
- Les sortir du dépôt (coffre de secrets Symfony ou variables d’environnement du serveur)
- Revoir la liste des accès au dépôt et retirer les comptes inactifs
- Ajouter une détection automatique de secrets avant chaque livraison
Charge estimée : 1 jour Priorité : P1, immédiat.
SYM-08 : Export des dossiers non cloisonné
Constat : La fonction d’export CSV vérifie que l’utilisateur est connecté, mais pas son périmètre. En modifiant un paramètre de l’adresse, un utilisateur exporte les dossiers d’une autre agence, coordonnées des clients comprises.
Comment nous l’avons vu : Revue du contrôleur d’export, puis vérification avec deux comptes de test de périmètres différents sur l’environnement de préproduction.
Risque : Fuite de données personnelles entre entités. Si la faille a été exploitée, elle entraîne une obligation de notification à la CNIL et aux personnes concernées.
Recommandation :
- Filtrer l’export côté serveur selon le périmètre de l’utilisateur, via un mécanisme d’autorisation unique (Voter)
- Revoir les autres points d’accès construits sur le même modèle : 4 ont été identifiés
- Ajouter un test automatisé qui vérifie le cloisonnement
- Analyser les logs pour savoir si la faille a été utilisée
Charge estimée : 2 jours Priorité : P1, sous 15 jours.
6. Ce que contient le rapport livré
Le rapport complet de ce cas type fait une quarantaine de pages.
- Synthèse de direction de 2 pages, lisible sans connaissance technique
- Périmètre et méthode : ce qui a été examiné, avec quels outils, et ce qui n’a pas pu être vérifié
- État par domaine : les 6 domaines, avec leur évaluation argumentée
- Les 29 fiches de constat, toutes au format présenté ci-dessus
- Plan d’action priorisé et chiffré, avec les dépendances entre actions
- Annexes : inventaire des dépendances et de leurs versions, résultats bruts des outils, schéma des composants
Le rapport est remis en PDF 48 heures avant la restitution, puis présenté en visioconférence : d’abord la synthèse pour la direction, ensuite le détail pour les équipes techniques. Il vous appartient : vous pouvez le confier à l’équipe de votre choix.
Pour aller plus loin
Notre audit Symfony : ce que nous examinons, les accès nécessaires et le déroulement. Et ce qui s’est passé après ce rapport : de l’audit à la reprise d’une application Symfony. Sur la montée de version : mettre à jour une ancienne version de Symfony.