One of the most common security pitfalls in Livewire is assuming that public properties are safe from client-side tampering. Since Livewire dehydrates public properties to the frontend, a savvy user can modify them using browser DevTools.

The Vulnerability

Imagine a component that manages an order:

 1class UpdateOrder extends Component
 2{
 3    public $orderId;
 4 
 5    public function delete()
 6    {
 7        $order = Order::find($this->orderId);
 8        // ...
 9    }
10}

If a malicious user changes the orderId in the HTML payload before the delete action is called, they could potentially delete an order that doesn't belong to them.

The Solution: #[Locked]

Livewire 3 introduced the #[Locked] attribute to solve this exact problem. By adding this attribute to a property, you tell Livewire that this value cannot be updated from the frontend.

 1use Livewire\Attributes\Locked;
 2use Livewire\Component;
 3 
 4class UpdateOrder extends Component
 5{
 6    #[Locked]
 7    public $orderId;
 8 
 9    public function mount($orderId)
10    {
11        $this->orderId = $orderId;
12    }
13 
14    // ...
15}

How it works

If a user attempts to modify a #[Locked] property via JavaScript or the payload, Livewire will throw a Livewire\Exceptions\PropertyIsLocked exception, halting the request immediately.

Best Practices

Use #[Locked] for:

• Database IDs (primary keys).
• User roles or permission flags.
• Any state that determines ownership or authorization logic.

It is a simple addition that drastically improves the security posture of your TALL stack applications.