Livewire public property exposure: accidental sensitive data leakage?

Question

Livewire public property exposure
In Livewire, any property declared as public on a component class is automatically serialized and sent to the browser. If a developer inadvertently marks a sensitive value—such as a user ID, API token, or an Eloquent model—as public, that data becomes available to any client that can trigger the component.
There is no built‑in guard to prevent the serialization of non‑scalar types, and the framework’s documentation only recommends using protected or private visibility and exposing data through getters. Recent discussions suggest a configurable strict‑mode that would reject public properties containing complex objects, but no stable release currently implements it.
Given that route middleware does not affect this serialization, the question remains how to reliably detect and avoid accidental public exposure before deployment.

What detection mechanisms can be employed to flag public properties that hold sensitive or non‑scalar data?
Does Livewire offer a strict‑mode configuration that rejects or warns about such properties?
How can developers enforce visibility rules programmatically across multiple components?

Muntasir · Answer

What happens and how to detect it
Livewire sends every public component property to the browser as part of the page snapshot. A public property holding a user ID, API token, or Eloquent model is therefore visible to any client that can render or update that component. Route middleware does not prevent this serialization because it happens after authorization, during response rendering.

Detection mechanisms

Static analysis: Run PHPStan with a custom rule that scans classes extending Livewire\Component and flags public properties typed as non-scalar (objects, arrays, resources) or inferred to hold complex values.
Snapshot test: In a feature test, render the component, capture the Livewire XHR response, decode the snapshot payload, and assert that sensitive keys such as token or api_key are absent.
Browser check: Open DevTools -> Network, trigger a component update, and inspect the livewire/message payload for unexpected values.

Strict-mode status
No stable Livewire 3.x release includes a strict_mode setting that rejects or warns about sensitive public properties. Community proposals exist, but they are not released behavior. Treat any strict-mode reference as a proposal, not a feature you can enable today.

Programmatic enforcement across components
Require components to extend a secure base class that intercepts public assignments:
abstract class SecureComponent extends \Livewire\Component
{
    public function __set(string $name, $value): void
    {
        if ($this->isAllowedPublic($name, $value)) {
            parent::__set($name, $value);
            return;
        }

if (!is_scalar($value) && $value !== null) {
            \Log::warning('Blocked non-scalar public property', [
                'component' => static::class,
                'property' => $name,
                'type' => gettype($value),
            ]);
            return;
        }

parent::__set($name, $value);
    }

protected function isAllowedPublic(string $name, $value): bool
    {
        return in_array($name, $this->publicAllowlist(), true);
    }

protected function publicAllowlist(): array
    {
        return [];
    }
}

Child components override publicAllowlist() to whitelist intentional public scalars such as ['search', 'page']. Models, collections, and tokens stay protected or private and are exposed only through public getters or computed properties.

Verification steps

Create a component with public $token and public $user assigned an Eloquent model.
Render it, open DevTools -> Network, trigger an update, and confirm the snapshot contains the token and serialized model.
Run the PHPStan rule; it should flag both properties.
Switch the component to extend SecureComponent and confirm the log warning appears while the payload no longer includes the blocked values.

Assumptions and uncertainty

Assumes Livewire 3.x; Livewire 2.x serialization internals differ and may require a different base-class approach.
Intercepting __set does not catch properties assigned before the base constructor runs or set through magic methods.
Static analysis can produce false positives for intentionally public scalar arrays; whitelist them in publicAllowlist().

Missing diagnostic detail: Which Livewire major version are you targeting? The enforcement code above targets 3.x.

Livewire public property exposure: accidental sensitive data leakage?