Peut-on sécuriser une application Livewire sans rien installer de plus ? Oui : Livewire fournit déjà de quoi verrouiller ses propriétés. Un paquet communautaire propose d'aller plus loin en bloquant tout par défaut. L'idée est séduisante, mais le paquet est trop jeune pour qu'on l'installe les yeux fermés.
Le cas : un identifiant que le navigateur peut réécrire
Livewire sert à construire des écrans qui réagissent sans recharger la page. Le composant vit sur le serveur, et son état (ses propriétés publiques) fait des allers-retours avec le navigateur. Selon la documentation officielle de Livewire, ces propriétés sont traitées comme une entrée utilisateur : un $id public peut être modifié depuis le navigateur, même sans champ de formulaire.
Prenons une PME de négoce dont l'écran de gestion des utilisateurs garde un $role en propriété publique. Si rien ne valide la requête, un utilisateur averti peut envoyer "admin" à la place. L'auteur de l'article dev.to à l'origine du sujet donne exactement cet exemple.
Livewire signe pourtant l'état de chaque composant avec un checksum, une empreinte qui détecte les altérations. Cela protège la forme des données, pas le droit de les changer. Une valeur bien formée peut très bien être interdite.
Ce que propose le verrouillage par défaut
Par défaut, les propriétés sont modifiables côté client. Seuls les modèles Eloquent affectés à une propriété sont verrouillés automatiquement, pour protéger leur ID, d'après la documentation des propriétés. Pour le reste, Livewire offre trois défenses : typer la propriété avec un modèle, poser l'attribut #[Locked], appeler $this->authorize() dans l'action.
Le paquet janecodelife/livewire-secure-properties inverse la logique : tout est verrouillé, sauf ce qui porte #[Unlocked]. Une mise à jour interdite lève une erreur 403. Il demande Livewire 4, il est gratuit (licence MIT) et s'installe d'une commande, selon son dépôt GitHub.
Reste la maturité. Packagist affiche une version 1.0.1, 17 installations et 2 étoiles. Le "secure by default" est l'affirmation de l'auteur : nous n'avons trouvé ni audit, ni test indépendant, ni avis d'utilisateurs. Les cas limites, comme les formulaires dédiés ou wire:model.live, ne sont pas documentés.
Sécuriser un composant, étape par étape
On part du plus sensible. Repérer d'abord les propriétés qui touchent aux droits : identifiants, rôles, prix, statuts.
Ensuite, les verrouiller avec #[Locked] ou les typer avec un modèle. Attention : #[Locked] ne bloque que le client. Le code serveur peut toujours changer la valeur, donc on n'y injecte jamais une donnée non fiable.
Vient l'étape que beaucoup oublient : chaque action vérifie l'autorisation avec une Policy. Même un wire:click="delete(12)" peut être réécrit dans le navigateur.
Enfin, les prix et les droits ne sont pas des propriétés à protéger mais des valeurs à recalculer côté serveur.
Prenons un portail de commande où la commande part seule en facturation et chez le logisticien, comme celui que nous avons créé pour un de nos clients, fabricant d'objets personnalisables. Personne ne relit chaque ligne à la main : c'est le serveur qui doit décider. Pour l'audit, une extension PHPStan comme wirestan signale les propriétés publiques sans #[Locked].
Faut-il installer le paquet ? Notre avis
Pas en production tant que personne n'a relu son code. Un composant de sécurité maintenu par une seule personne est une dépendance de plus à surveiller. Et le verrouillage généralisé peut casser des formulaires existants : il faudrait tester chaque composant et ajouter #[Unlocked] là où c'est voulu.
Sur un projet neuf, ou comme filet pendant un audit, l'essayer en environnement de test se défend. À condition de ne pas s'en servir pour sauter les contrôles d'autorisation : le verrouillage ne remplace pas les Policies, et il ne couvre pas les paramètres d'action.
Ce qu'une PME peut en retenir
Si votre application Livewire a été livrée il y a quelques années, demandez à votre prestataire un audit de ses composants. C'est un chantier court et ciblé, dans l'esprit de la reprise d'une application existante. Nous accompagnons des entreprises de Provence, autour de Lambesc comme ailleurs, sur ce genre de vérification dans une application sur mesure.
La question à poser : quelles propriétés sensibles sont publiques, et quelle action vérifie les droits ? Pour en parler, contactez-nous.
- Une propriété publique Livewire se modifie depuis le navigateur : traitez-la comme une saisie utilisateur.
#[Locked], le typage par modèle etauthorize()suffisent à couvrir l'essentiel, sans paquet.- Le paquet de verrouillage par défaut est gratuit mais récent (17 installations sur Packagist), sans test indépendant : à relire avant la production.
- Prix, rôles et droits se recalculent côté serveur, jamais en propriété modifiable.
Questions fréquentes
Livewire verrouille-t-il les propriétés automatiquement ?
Non, sauf pour les modèles Eloquent affectés à une propriété, dont l'ID est protégé. Les autres propriétés publiques restent modifiables depuis le navigateur tant qu'on ne les verrouille pas.
Le verrouillage d'une propriété suffit-il à protéger une action ?
Non. Il bloque les changements venant du client, mais ne dit rien sur le droit de l'utilisateur à agir. Chaque action doit aussi vérifier l'autorisation côté serveur, par exemple avec une Policy.
Le paquet de verrouillage par défaut est-il payant ?
Non, il est gratuit (licence MIT) et s'installe avec une commande Composer. Il exige Livewire 4. Nous n'avons trouvé ni avis de clients ni retour d'usage en production.