Locked public properties vs server-side re-fetching for resource IDs in Livewire v3

Question

Trade-off: client-held locked IDs versus server-side re-fetching
Livewire v3 components often need a stable resource identifier (for example, a post ID) to authorize mutations such as delete() or update(). Two documented patterns exist:

Expose the ID as a public property marked #[Locked] so the client cannot tamper with it; Livewire's checksum validates integrity on each request.
Keep the ID only in a protected property and re-fetch the model from the database (or cache) on every server-side request, discarding any client-supplied value.

The first approach avoids an extra query per request but relies on Livewire's tamper-resistance mechanism. The second adds a query but ensures the authoritative record is always loaded fresh, providing defense-in-depth if the checksum logic ever changes or is bypassed.
Both patterns satisfy the requirement that $this->authorize('delete', $post) receives a trusted model instance. The choice affects latency, database load, and the trust boundary between client and server.
Questions

In a high-traffic admin panel, does the query overhead of re-fetching outweigh the checksum trust assumption for locked properties?
Are there documented failure modes where a locked property's checksum passes but the underlying record has been deleted or reassigned?
Does the Form object pattern in Livewire v3 shift this trade-off by centralizing the model resolution?

Tasadduq Burney · Answer

Answer
For most admin panels the extra SELECT query needed to re‑fetch a model adds only a few milliseconds per request, so the latency cost rarely outweighs the trust assumption behind a #[Locked] property.
Confirmed facts

A #[Locked] public property guarantees that the value sent by the client matches the value originally serialized; Livewire validates this with a checksum on every request.
The checksum does **not** verify that the referenced row still exists in the database, so a record can be deleted or reassigned after the page renders and the locked ID will still pass validation.
When a Livewire Form is bound to a model ($form->model($post)), the Form’s bind() method loads the model from the database on each request, implementing the server‑side re‑fetch pattern automatically.

Likely explanation / assumptions

In a warm MySQL/PostgreSQL buffer pool an indexed primary‑key lookup typically costs <2 ms, which is small compared with typical network round‑trip times (often 20‑50 ms) and Livewire’s own processing overhead.
Therefore, under normal traffic the query overhead of re‑fetching is unlikely to become a bottleneck; the decision hinges more on how much weight you give to defense‑in‑depth versus reliance on Livewire’s integrity check.
If the checksum algorithm were weakened or a misconfiguration disabled it, a malicious client could tamper with the locked ID and gain unauthorized access to any record.

Steps for this case

Measure the current query latency for a primary‑key fetch on your production DB (e.g., with Laravel Debugbar or clockwork) under peak load.
If the average latency stays below ~5 ms, keep the #[Locked] property for simplicity and lower DB load.
If you observe higher latency or want an extra safety layer, switch to a protected property and re‑fetch the model in each request, or use a Form object bound to the model.

If you can share the observed average query time for a Post lookup under your peak traffic, I can confirm whether the latency threshold is met.

Locked public properties vs server-side re-fetching for resource IDs in Livewire v3

Trade-off: client-held locked IDs versus server-side re-fetching

Questions

1 answer

Answer

Confirmed facts

Likely explanation / assumptions

Steps for this case

Your perspective belongs here.

0 question comments