Sécurité Symfony : failles, attaques et bonnes pratiques

Introduction

Depuis plusieurs années, de nombreux frameworks PHP ont émergé, notamment Symfony, lancé en 2005. Aujourd’hui, ce framework est à sa version 7 et a beaucoup évolué depuis ses débuts.

Symfony intègre plusieurs mesures de sécurité pour protéger les applications sur différents fronts. Les audits montrent que les applications développées avec Symfony présentent généralement moins de vulnérabilités que celles créées en PHP natif.

Dans cet article, nous explorerons les mécanismes de sécurité offerts par Symfony. Nous verrons aussi comment un développeur peut, volontairement ou non, contourner ces protections, ce qui peut entraîner des failles. Enfin, nous aborderons les vulnérabilités potentielles dues à une mauvaise utilisation de certains composants du framework.

Pour cela, nous nous baserons sur Symfony 6.4, la dernière version LTS à la date de rédaction.

Guide complet sur la sécurité de Symfony

Exploitation du profiler Symfony

Bien que rarement observé en production, il est malheureusement fréquent de trouver des environnements de développement Symfony avec le profiler activé lors d’une phase de reconnaissance.

Cette exposition représente une vulnérabilité critique. Le profiler fournit des informations précieuses sur l’application, aidant un attaquant à mieux comprendre le code et l’architecture. Dans certains cas, cela peut même conduire à la compromission du serveur applicatif ou de la base de données.

Le profiler Symfony est un outil très utile pour le développement, mais il ne doit jamais être accessible publiquement. La documentation officielle de Symfony le précise clairement :

« Never enable the profiler in production environments as it will lead to major security vulnerabilities in your project ».

En effet, le profiler expose l’application à diverses exploitations, dont certaines seront examinées pour illustrer la gravité de cette vulnérabilité. À noter que l’outil EOS (Enemies Of Symfony) permet d’automatiser ces exploitations.

Récupération des mots de passe

Lorsque le profiler est accessible, l’un des premiers risques est la possibilité de récupérer des identifiants sensibles.

En effet, le profiler Symfony permet d’afficher les requêtes de la plateforme via une URL spécifique : https://yourdomain/_profiler/empty/search/results?limit=10.

Il suffit ensuite de localiser une requête de connexion, identifiable par un statut HTTP 302 et une URL de type /login.

Cela permet d’accéder aux données transmises via le formulaire, exposant ainsi des informations sensibles comme les identifiants utilisateur.

Dans cet exemple, on constate que l’administrateur utilise le mot de passe « UnMotDePasseSuperCompliqué ».

Si ce mot de passe est réutilisé en environnement de production, un attaquant pourrait exploiter cette donnée pour obtenir un accès administrateur permettant ainsi une élévation immédiate de privilèges.

Récupération de secret

Avec le profiler, il est possible de récupérer les secrets de l’application. Par exemple, cela peut se faire via la toolbar en accédant à l’option « View phpinfo() », ou directement à l’URL suivante : https://yourdomain/_profiler/phpinfo.

En exploitant la page phpinfo, un attaquant peut accéder à des informations sensibles, comme le secret Symfony. Si ce secret est compromis, il peut manipuler des mécanismes de sécurité critiques, tels que la génération de jetons CSRF ou la validation de signatures, augmentant considérablement les risques pour l’application.

Une autre exploitation liée au secret Symfony concerne les fragments, si cette fonctionnalité est activée. Avec ce secret, un attaquant peut falsifier des requêtes spécifiques pour manipuler les fragments.

Cela peut même conduire à des attaques graves, comme l’exécution de commandes sur le serveur.

Par ailleurs, si le secret de votre application est compromis, il est impératif de le régénérer immédiatement !

Accès à la liste des routes de l’application Symfony

En exploitant le profiler sur une requête renvoyant une erreur 404, un attaquant peut accéder à l’ensemble des routes de l’application Symfony.

Cette information offre une cartographie détaillée de l’application.

Lecture des fichiers

En exploitant l’URL /_profiler/open avec un chemin de fichier valide et une ligne de départ spécifiée, un attaquant peut accéder au contenu des fichiers du projet. Par exemple, l’URL ci-après permet de lire le code source du UserController.

Cette faille représente une menace critique, car elle divulgue des informations sensibles sur la logique métier et l’architecture de l’application, facilitant des attaques plus complexes.

https://yourdomain/_profiler/open?file=src/Controller/UserController.php&line=1

En abusant de ce comportement, il est possible de récupérer l’ensemble du code source de l’application.

Comment sécuriser le mode développement et le profiler Symfony ?

Il est assez simple de vérifier si une application est vulnérable. La présence de la toolbar Symfony peut indiquer que la plateforme fonctionne en mode développement. Cependant, cet indicateur n’est pas toujours fiable.

Désactiver la toolbar et le profiler

En effet, il est possible de désactiver la toolbar tout en maintenant le profiler actif, comme le montre la configuration suivante :

Ici, bien que la toolbar ne soit pas visible, le profiler reste accessible, ce qui peut laisser l’application vulnérable si aucune autre mesure de sécurité n’est implémentée pour limiter son accès.

Ainsi, il reste possible d’accéder directement au profiler via l’URL suivante :

https://<yourdomain>/_profiler/empty/search/results?limit=10

Le mode dev a aussi des erreurs assez spécifiques. Par exemple une page 404 aura la forme suivante :

À l’inverse, en production elle aura cette forme :

Note : Ceci est le fonctionnement par défaut, mais peut changer si la page 404 a été customisée.

Il est aussi possible de directement tenter l’accès à la page : https://localhost:8000/_profiler/empty/search/results?limit=10

Cependant, il est possible de modifier l’URL du profiler via le fichier config/routes/web_profiler.yaml :

La méthode la plus fiable pour vérifier si le mode développement est activé consiste à analyser le fichier .env ou la variable d’environnement APP_ENV. Cette variable indique clairement si l’application est configurée en mode dev ou prod.

Examiner les routes de l’app pour vérifier l’accès au profiler

Il est également conseillé d’examiner les routes de l’application pour vérifier si l’accès au profiler est autorisé. La disponibilité du profiler dans un environnement où il ne devrait pas être actif augmente les risques.

Vous pouvez afficher la liste des routes avec la commande suivante :

Note : Il peut être tentant de miser sur une stratégie de protection par l’obscurité, par exemple en utilisant des URLs difficiles à deviner pour le profiler et en désactivant la toolbar. Toutefois, cette approche est fortement déconseillée, car elle repose sur une sécurité fragile pouvant être contournée.

Si l’exposition d’un environnement de développement est nécessaire, il est recommandé de le restreindre à des adresses IP autorisées ; cela via des règles de filtrage strictes afin de réduire considérablement les risques d’accès non autorisé.

Sécuriser le contrôle d’accès sur les applications Symfony

L’absence ou le manque de contrôle des droits est l’une des vulnérabilités les plus courantes lors des tests d’intrusion sur des applications web.

Bien que cela dépende largement de la logique métier de l’application, Symfony propose des outils pour implémenter ces contrôles.

Ces fonctionnalités permettent aux développeurs de définir et de vérifier précisément les rôles des utilisateurs, réduisant ainsi les risques d’accès non autorisé à des ressources sensibles.

Restreindre les accès en fonction des rôles utilisateur

Une problématique fréquente en matière de contrôle des droits consiste à restreindre l’accès à certaines fonctionnalités ou pages en fonction des rôles. Par exemple, une page réservée à l’administration devrait être accessible uniquement aux utilisateurs ayant le rôle d’administrateur.

Ainsi, un utilisateur comme [email protected] ne devrait pas pouvoir accéder à la page suivante :

Plusieurs méthodes peuvent être utilisées pour protéger cette page.

Une solution consiste à configurer le fichier config/packages/security.yaml. En définissant la configuration suivante, vous pouvez vous assurer que seules les personnes ayant le rôle admin peuvent accéder à toutes les pages commençant par /admin/ :

Via les attributs php, il est possible de fixer les règles au niveau du controller/route :

Directement dans le code du Controller :

La gestion des rôles dans Symfony est à la fois complète et flexible. Par exemple, il est possible de définir une hiérarchie des rôles. Un rôle supérieur, tel que SUPER_ADMIN, peut hériter automatiquement des permissions d’un rôle inférieur, comme ADMIN.

Cette hiérarchie peut être configurée facilement via le fichier de configuration, comme le montre l’exemple ci-dessous :

Symfony permet également de vérifier les droits d’accès, que ce soit dans des services ou directement dans des templates Twig.

Pour approfondir vos connaissances sur la gestion de la sécurité dans Symfony, nous vous recommandons de consulter la documentation officielle.

Limiter les accès aux ressources et prévenir les failles IDOR (Insecure Direct Object Reference)

Dans la section précédente, nous avons surtout parlé des contrôles d’accès aux pages. Cependant, il est tout aussi important de gérer les droits d’accès aux ressources spécifiques au sein de ces pages pour prévenir des failles IDOR.

Par exemple, dans une application de gestion de factures, un utilisateur doit pouvoir consulter ses propres factures, mais pas celles des autres. Ainsi, même si un utilisateur a le droit d’accéder à la page /invoice/{id}, cet accès doit être conditionné à une vérification supplémentaire pour s’assurer qu’il est bien le propriétaire de la facture liée à cet identifiant.

Utiliser les voters symfony pour gérer l’accès aux ressources

Symfony propose des outils comme les voters pour gérer efficacement ce type de logique.

Ici par exemple notAdmin arrive à accéder à la facture de l’admin :

Pour renforcer le contrôle des droits et garantir qu’un utilisateur n’accède qu’aux ressources qui lui sont autorisées, il est possible d’ajouter une contrainte directement sur la route à l’aide d’un attribut.

Dans cet exemple, l’attribut #[IsGranted] utilise deux arguments :

• invoice-view : représente l’action ou la permission à vérifier, ici l’autorisation de visualiser une facture.
• invoice : désigne le sujet sur lequel la vérification est appliquée, dans ce cas une instance de l’entité Invoice.

Ensuite, un voter correspondant sera défini dans le fichier src/Security/Voter/InvoiceVoter pour gérer cette logique.

Dans cet exemple simplifié, le voter est conçu uniquement pour gérer l’autorisation de visualiser des factures. Bien que limité à cet usage, il illustre bien le fonctionnement général d’un voter dans Symfony.

Ce voter repose sur deux méthodes principales :

• supports() : Cette méthode vérifie si le voter doit intervenir pour une demande donnée. Ici, le voter ne s’applique que si l’attribut est invoice-view et que la ressource concernée est une invoice.
• voteOnAttribute() : Cette méthode contient la logique pour déterminer si l’utilisateur est autorisé à accéder à la ressource. Par exemple, elle vérifie si l’utilisateur est bien le propriétaire de la facture. Si oui, elle retourne true ; sinon, false.

Avec ce voter en place, un utilisateur comme notadmin ne pourra plus accéder aux ressources appartenant à admin.

À l’inverse, l’utilisateur admin peut toujours accéder à ses propres ressources, ce qui correspond au comportement attendu.

Notez que vous pouvez construire la base d’un voter via le symfony/maker-bundle avec la commande suivante : php bin/console make:Voter.

Analyser les résultats des voters via le profiler

Il est également possible de voir le résultat des voters sur le _profiler :

La stratégie utilisée ici est définie comme affirmative. Cela signifie qu’un seul voter doit retourner une réponse positive (true) pour accorder l’accès à la ressource. Cette approche est idéale lorsque plusieurs règles peuvent s’appliquer, mais qu’une seule validation positive suffit pour autoriser l’accès.

C’est le fonctionnement par défaut de Symfony. Cependant, il est possible de modifier cette stratégie et d’en choisir une autre, selon vos besoins :

• consensus : L’accès est accordé s’il y a plus de votants qui l’autorisent que de votants qui le refusent.
• unanimous : L’accès est accordé uniquement si aucun voter ne s’y oppose.

Il est également envisageable d’implémenter une stratégie personnalisée pour répondre à des besoins spécifiques en gestion des droits.

Avec ces bases, vous pouvez sécuriser efficacement les accès à votre application.

Se prémunir des vulnérabilités Cross-site scripting (XSS)

Les XSS sont parmi les vulnérabilités les plus courantes observées lors des audits.

Utiliser le moteur de templates Twig pour encoder automatiquement les données

L’un des grands avantages de Symfony réside dans l’utilisation du moteur de templates Twig, qui rend les vues sécurisées par conception.

Par défaut, Twig encode automatiquement les variables insérées dans les templates, réduisant ainsi le risque d’injections XSS.

Note : Dans cette section, la valeur de la variable text sera <img src=x onerror=alert(1) />.

Par exemple, la vue suivante n’est pas vulnérable au XSS grâce à la gestion automatique de l’encodement par Twig.

En accédant a la page nous pouvons voir que le texte est bien encodé :

Code HTML du body :

Ne pas utiliser le filtre raw qui retire l’encodage par défaut

Twig propose un tag pour ne pas encoder par défaut via le filtre raw. Ainsi le code suivant devient vulnérable :

Il est donc vivement déconseillé d’utiliser le filtre raw dans vos applications, pour prévenir le risque d’injection XSS. S’il est nécessaire, il est crucial de s’assurer que les données sont sécurisées.

Contrer les XSS via texte enrichi

L’un des cas les plus courants d’attaques XSS concerne l’utilisation de texte enrichi.

Lorsqu’une application permet aux utilisateurs d’insérer des éléments tels que des images, du texte en gras ou des liens, elle peut être tentée d’utiliser le filtre |raw pour afficher ces données dans le format souhaité.

Cependant, cette approche ouvre une porte aux attaquants. Un utilisateur malveillant pourrait injecter du code JavaScript dans ces données enrichies, qui serait ensuite exécuté par le navigateur, compromettant ainsi la sécurité du site.

Si vous utilisez Twig pour générer vos vues, nous vous conseillons d’utiliser le HTML Sanitizer de Symfony.

Par exemple, si vous souhaitez uniquement autoriser l’attribut src dans les balises <img>, vous pouvez appliquer la configuration suivante :

Et nous aurons le fichier Twig suivant :

Ce qui retournera uniquement le code html suivant :

Il est crucial de noter que la sécurité de votre application dépend largement de la configuration du sanitizer. Il est donc recommandé de limiter cette configuration aux éléments et attributs strictement nécessaires au bon fonctionnement de l’application.

Note : Le sanitizer Symfony n’est pas exclusif à Symfony, vous pouvez donc l’utiliser dans d’autres projets PHP.

Par ailleurs, si votre application gère le rendu côté client, vous pouvez également utiliser DomPurify pour renforcer la sécurité.

Contrer les vulnérabilités SSTI (Server-Side Template Injection)

L’utilisation de Twig présente des avantages significatifs, notamment des protections intégrées contre les attaques XSS.

Cependant, dans certains cas, Twig peut être détourné pour permettre aux utilisateurs de créer ou modifier des templates dynamiques. Cette pratique peut introduire des vulnérabilités de type SSTI (Server-Side Template Injection), permettant à un attaquant d’injecter et d’exécuter du code malveillant directement sur le serveur.

Exemple d’exploitation d’une SSTI

Prenons par exemple le cas où l’application permet à un manager de définir un message personnalisé sur la page principale.

Voici un exemple de vue Twig vulnérable :

Cette vulnérabilité se manifeste lorsqu’un rendu Twig est effectué à partir d’une entrée arbitraire fournie par un utilisateur.

Dans notre cas, le manager soumet un template via un formulaire, lequel est ensuite stocké dans la base de données. Par la suite, ce message est récupéré et un rendu Twig est effectué sur celui-ci.

Ce type de code vulnérable est fréquemment rencontré lorsqu’on cherche des exemples pour effectuer un rendu d’une chaîne de caractères venant d’un string ou d’une base de données.

L’idée ici est par exemple de permettre au manager de définir un message comme : Hello {{ app.user.email }}

Ainsi, un utilisateur accédant à la page verra un message de bienvenue personnalisé.

Ainsi, un utilisateur malveillant ayant accès à cette fonctionnalité peut l’exploiter pour exécuter du code arbitraire sur le serveur.

Par exemple, en injectant des instructions spécifiques dans le template, l’attaquant peut détourner le fonctionnement de l’application et compromettre sa sécurité.

Voici quelques exemples de messages pouvant être utilisés pour exploiter cette vulnérabilité :

• {{ '/etc/passwd'|file_excerpt(1,30) }} : Permet la lecture de fichiers arbitraires, comme le fichier /etc/passwd sur un serveur Unix, exposant potentiellement des informations sensibles.

• {%block U%}cat /etc/passwd{%endblock%}{%set x=block(_charset|first)|split(000)%}{{[x|first]|map(x|last)|join}} permet l’exécution de commande

Comment se protéger ?

Interdire la saisie de templates

La solution la plus radicale, mais également la plus efficace, consiste à interdire à un utilisateur de saisir directement des templates interprétés par Twig.

Si cette fonctionnalité est indispensable, il est recommandé de mettre en place un système de remplacement contrôlé. Par exemple, vous pouvez utiliser des expressions régulières (regex) pour identifier et remplacer certains contenus par leurs valeurs avant le rendu.

Cette approche limite les possibilités d’exécution de code arbitraire tout en conservant une certaine flexibilité pour l’utilisateur.

Implémenter une sandbox avec Twig

Une autre solution consiste à mettre en place une sandbox avec Twig. Par exemple, nous pouvons modifier le controller pour appliquer une politique de sécurité stricte.

Mettre en place une sandbox peut constituer une solution intéressante, car elle permet de limiter les actions exécutables dans le template. Cependant, une mauvaise configuration de la sandbox peut laisser place à des contournements exploitables par un attaquant.

Il est également crucial de contrôler les méthodes et propriétés accessibles via la sandbox. Par exemple, si l’application autorise la lecture du champ hash d’un utilisateur, cela pourrait permettre à un attaquant de récupérer le hash de son mot de passe.

Une attention particulière doit donc être portée à la configuration de la sandbox et aux objets autorisés.

Utiliser un moteur de template logic-less

La dernière solution consiste à utiliser un moteur de template logic-less comme Mustache, qui sépare au maximum le rendu visuel de l’interprétation de code.

Dans les templates Mustache, il n’y a pas de mécanismes explicites pour gérer le flux de contrôle, car tout le contrôle est déterminé par les données transmises. De plus, il est impossible d’intégrer directement une logique métier ou applicative dans les templates.

Ce design minimaliste limite considérablement les possibilités d’exploitation, notamment les attaques les plus critiques, telles que l’exécution de code à distance (RCE). En conséquence, le risque global d’attaques est significativement réduit.

Prévenir les attaques de type Host Header Poisoning

Il est fréquent de constater qu’une application Symfony est vulnérable à des attaques de type Host Header Poisoning.

Cette vulnérabilité peut se manifester dans des fonctionnalités telles que la réinitialisation de mot de passe.

Prenons l’exemple d’une application où l’hôte est configuré sur localhost. L’application génère un lien de réinitialisation de mot de passe en se basant sur l’en-tête Host.

Un attaquant pourrait exploiter ce comportement en envoyant un lien de réinitialisation à l’administrateur, redirigeant celui-ci vers un domaine qu’il contrôle.

POST /reset-password HTTP/2
Host: evil-localhost:8000
Cookie: PHPSESSID=5setp64tm5gjqbc0l9pkmgcsn1; main_auth_profile_token=734949
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://localhost:8000/reset-password
Content-Type: application/x-www-form-urlencoded
Content-Length: 206
Te: trailers

reset_password_request_form%5Bemail%5D=admin%40local.dev&reset_password_request_form%5B_token%5D=677a3.RDMh-XGfZIRgCx2wovHAWGa3UDxpn7ZS5yTstAj-Rac.CgVSngfZDfQIYEvl-MiZMgL_KXAk7cIjvxe72V2WP_AOYXHIOe0PwhFKTA

L’admin va recevoir le lien suivant :

Si l’administrateur clique sur le lien, l’attaquant pourra récupérer le token de réinitialisation. Avec ce token, il pourra effectuer une demande de changement de mot de passe sur l’application légitime, ce qui entraînera le vol du compte de l’administrateur.

Pour corriger cette attaque au niveau applicatif, il est possible d’ajouter le champ trusted_hosts dans le fichier framework.yaml.

Implémenter un rate limiting

Cette vulnérabilité, bien que souvent considérée comme moins critique, peut néanmoins être exploitée dans de nombreuses applications qui ne mettent pas en place de rate limiting pour limiter le nombre de requêtes qu’un utilisateur peut effectuer sur une période donnée.

Une exploitation typique consiste à soumettre un grand nombre de combinaisons d’identifiants et de mots de passe sur une page de connexion dans le but de découvrir des accès valides.

Symfony offre un rate-limiter qui permet de définir et de configurer des limites sur le nombre de requêtes qu’un utilisateur peut envoyer dans un laps de temps :

composer require symfony/rate-limiter

Ensuite, il suffit de modifier le fichier security.yaml pour activer le rate limiting. En définissant login_throttling: null, la configuration par défaut sera activée. Cependant, il est possible de personnaliser davantage les réglages ou même de créer votre propre rate limiter selon vos besoins.

La configuration par défaut autorise jusqu’à 5 tentatives par minute et par utilisateur depuis une même adresse IP, ce qui limite les risques de bruteforce ciblé sur un compte spécifique. Par ailleurs, une adresse IP est limitée à 25 tentatives par minute, afin de dissuader les attaques de force brute sur plusieurs comptes simultanément.

Si vous souhaitez personnaliser les paramètres, vous pouvez consulter la documentation pour explorer les différentes options.

Contrer les attaques CSRF

Pour rappel, une attaque CSRF (Cross-Site Request Forgery) consiste à inciter un utilisateur authentifié à effectuer une action sur une application à son insu.

Prenons, par exemple, un formulaire de création d’utilisateur, qui n’est accessible qu’aux administrateurs. L’objectif de l’attaquant serait de diriger l’administrateur vers un site qu’il contrôle, où un formulaire malveillant serait conçu pour soumettre ce formulaire à l’insu de l’administrateur. Cela permettrait à l’attaquant d’exploiter les privilèges de l’administrateur pour créer un utilisateur malveillant.

Voici un exemple de la forme d’un formulaire malveillant que l’attaquant pourrait inciter l’administrateur à exécuter :

Nativement Symfony est protégé contre ce type d’attaque comme le révèle la réponse suivante après soumission du formulaire :

Cela est possible grâce au fait que les formulaires Symfony ajoutent, par défaut, un paramètre _token. Ce token agit comme une protection efficace contre les attaques CSRF en s’assurant que seules les requêtes provenant de l’application légitime sont acceptées.

Il est possible de désactiver le token de manière globale :

Ou directement sur un formulaire précis :

Attention, désactiver le token CSRF n’est pas une bonne pratique sécurité. Ce mécanisme constitue une barrière essentielle contre les attaques CSRF. Si vous envisagez de le désactiver, il est impératif de bien évaluer les implications et de s’assurer que des mesures compensatoires adéquates sont mises en place.

Surveiller les composants vulnérables de vos applications Symfony avec Composer

Symfony utilise Composer pour gérer ses paquets, ce qui simplifie l’installation et la gestion des dépendances. Cependant, des vulnérabilités sont régulièrement découvertes dans certains paquets, ce qui peut compromettre la sécurité de vos applications.

Il est donc crucial de mettre en place une politique de mises à jour régulières pour garantir la sécurité de vos dépendances. Un avantage majeur de Composer est sa commande intégrée qui permet de détecter les vulnérabilités dans les paquets utilisés par votre application.

Tout comme Composer, npm offre une commande pratique pour gérer les vulnérabilités dans les dépendances JavaScript. La commande npm audit permet de lister les vulnérabilités connues dans votre projet, d’indiquer leur gravité et de proposer des correctifs ou des actions à entreprendre pour les résoudre.

Utiliser Doctrine pour contrer les injections SQL

La plupart des projets Symfony utilisent Doctrine pour interagir avec la base de données. Doctrine préfère l’utilisation de méthodes abstraites et sécurisées plutôt que l’écriture directe de requêtes SQL.

Ainsi, les injections SQL sont rares dans les projets utilisant Doctrine, car les développeurs passent généralement les paramètres par le biais de méthodes dédiées, ce qui permet à Doctrine de générer automatiquement des requêtes préparées.

Conclusion

Dans cet article, nous avons abordé les vulnérabilités courantes identifiées lors d’un audit de sécurité. Symfony offre, par défaut, une protection efficace contre de nombreuses vulnérabilités. Lorsque la protection n’est pas intégrée, le framework met à disposition des outils pour l’implémenter.

En termes de sécurité en PHP, nous recommandons fortement l’utilisation de frameworks reconnus comme Symfony. L’utilisation de tels frameworks améliore significativement la sécurité par rapport aux applications développées sans framework, grâce aux mécanismes intégrés et aux bonnes pratiques qu’ils imposent.

Auteur : Thomas DELFINO – Pentester @Vaadata