Vous avez mis à jour Filament, et vos widgets restent peut-être exposés
Le 8 octobre, l'équipe Filament a publié quatre avis de sécurité, avec des correctifs livrés deux jours plus tôt dans les versions 5.10.0 et 4.15.0. Tous sont classés en gravité moyenne, et pour la plupart des applications la consigne tient en un mot : mettre à jour. Un de ces avis mérite pourtant une attention particulière, car la mise à jour ne couvre qu'une partie du problème. Cet article s'appuie sur l'analyse publiée par Filament 5.10 Security Fixes: The Livewire Scope Gap Your Upgrade Doesn't Close.
Les quatre avis en bref
- GHSA-6p72-cx74-63f5 : des enregistrements restent accessibles après un changement de scope ou de tenant (versions 4.x et 5.x, corrigé en 4.15.0 et 5.10.0).
- GHSA-jpwg-8rw9-v3jj : contournement de l'authentification multifacteur par email dans les applications multi-panels, lorsque des identifiants d'utilisateurs entrent en collision (4.x et 5.x, corrigé en 4.15.0 et 5.10.0).
- GHSA-q2ph-j76w-c7qx : le composant FileUpload conservait l'extension fournie par le client, de sorte qu'une image pouvait être stockée en
.html (3.x, 4.x et 5.x, corrigé en 3.3.56, 4.15.0 et 5.10.0).
- GHSA-9g92-9qj5-cqjc : des blocs personnalisés collés dans le RichEditor pouvaient exécuter du JavaScript (4.x et 5.x, corrigé en 4.15.0 et 5.10.0).
Les versions de correctif les plus récentes sont la 5.10.1 et la 4.15.1, publiées le 7 octobre. Pour les trois derniers avis, la mise à jour suffit. Le premier est celui qui demande un travail supplémentaire.
Pourquoi le correctif sur le scope est incomplet
La cause racine de cette faille se situe dans Livewire, pas dans Filament. Un composant Livewire conserve en mémoire, côté client, l'identifiant d'un enregistrement. Si le contexte change entre deux requêtes (l'utilisateur bascule vers un autre tenant, par exemple), l'enregistrement précédemment chargé peut rester atteignable alors qu'il n'appartient plus au périmètre courant de l'utilisateur.
Filament 5.10 verrouille ce comportement pour les pages de ressources. Le projet précise toutefois que les relation managers, les widgets et vos propres composants ne sont pas couverts. Autrement dit, tout composant Livewire que vous avez écrit, ou tout widget qui manipule des enregistrements par identifiant, reste dans la situation d'avant la mise à jour.
L'auteur de l'analyse source a installé Filament 5.9.0 sur un projet Laravel 13.35 vierge et reproduit le problème avec un composant Livewire ordinaire. Il a aussi testé deux correctifs contre ce scénario. Autre point gênant : composer audit ne signale rien sur une installation concernée. L'outil compare vos dépendances aux avis publiés, mais il ne sait pas si votre code applicatif réintroduit le même défaut de son côté.
Auditer vos composants personnalisés
La démarche est manuelle, mais elle est simple à structurer.
1. Recenser les composants à risque
Listez tout ce qui n'est pas une page de ressource Filament : relation managers, widgets, composants Livewire écrits à la main, actions personnalisées. Retenez ceux qui reçoivent ou stockent l'identifiant d'un enregistrement dans une propriété publique.
2. Revérifier le scope à chaque requête
Ne faites jamais confiance à un enregistrement chargé lors d'une requête précédente. À chaque interaction (action, rafraîchissement, soumission), rechargez-le via une requête qui applique le scope du tenant ou de l'utilisateur courant, plutôt qu'avec un simple find() sur l'identifiant.
// Fragile : l'identifiant seul ne dit rien du périmètre courant
$record = Invoice::find($this->recordId);
// Plus sûr : on repasse par une requête scopée au tenant courant
$record = Invoice::query()
->whereBelongsTo(Filament::getTenant())
->findOrFail($this->recordId);
3. Tester le changement de contexte
Écrivez un test qui charge un composant dans un tenant, change de tenant, puis déclenche une action sur l'ancien enregistrement. Le résultat attendu est un refus, pas un succès. Ce test devient un garde-fou permanent dans votre CI.
4. Ajouter une autorisation explicite
Une policy appelée sur chaque action sensible fournit une seconde barrière, indépendante du scope des requêtes. Les deux mécanismes se complètent : le scope limite ce qui est visible, la policy contrôle ce qui est permis.
Ce qu'il faut retenir
Mettre à jour vers Filament 5.10.1 ou 4.15.1 reste indispensable : cela corrige les quatre avis pour les pages de ressources, et intégralement les trois autres. Mais un audit de dépendances au vert ne prouve pas que vos composants sur mesure sont protégés. Le défaut vient de Livewire, et seul un contrôle de scope écrit dans votre propre code le referme là où Filament ne passe pas. Prévoyez donc une revue ciblée de vos widgets, relation managers et composants maison, accompagnée d'un test de bascule de tenant.
Ce que ça change pour vous
Si votre application est utilisée par plusieurs clients ou plusieurs entités, un utilisateur pourrait, dans certains écrans développés sur mesure, continuer à consulter ou modifier des données qui ne sont plus les siennes après un changement de contexte. Les outils de vérification automatique ne le signalent pas. La mise à jour corrige une grande partie du risque, mais pas les écrans spécifiques à votre activité. Demandez à votre prestataire une revue ciblée de ces écrans : c'est un travail limité, qui protège la confidentialité des données de vos clients.
