Why is a Livewire public property the wrong place for an API token or an employee's bank details, even with a checksummed snapshot?

## Where Livewire state lives A **Livewire component** has no server-side session of its own. Between requests its state lives in the browser as a **snapshot**: a JSON object with `data` (the public property values), `memo` (id, name, path and other metadata) and a `checksum`. - On the **first render**, Livewire puts that JSON into an HTML attribute on the component's root element, `wire:snapshot`. - On every **update**, the response carries a new snapshot, and the browser sends it back with the next request. So every public property value, including nested arrays and the output of synthesizers for collections, enums and models, is plainly visible in view-source, in devtools, in the network tab and in any browser extension with page access. ## What the checksum does and does not do The checksum is an **HMAC-SHA256** of the snapshot, keyed with the application's `APP_KEY`. It lets the server detect edits to the snapshot. It is not encryption: the data is sent as-is next to the signature. | Property | Readable by the user? | Changeable by the user? | |---|---|---| | plain public property | Yes | Yes, through an update | | `#[Locked]` public property | Yes | No, the update throws | | public model property | Class (or alias) and key only | No, rebuilt from signed meta | | `protected` / `private` property | No | No, but not persisted either | | `#[Computed]` method | Only what the view renders | No | ## Why protected properties are not the answer Livewire persists **only public properties**. A protected `$apiToken` set in `mount()` is not in the snapshot, but it is also gone on the next request, because the component is rebuilt from the snapshot each time. Protected properties suit constants or values you re-derive in `boot()` on every request. ## Safer patterns 1. **Read secrets where they are used.** An action that calls a payroll provider reads `config('services.payroll.token')` inside the method; the token never becomes state. 2. **Store identity, not data.** Keep `public Employee $employee` or a locked `$employeeId`; load the bank details only in the action that needs them. 3. **Compute what the view needs.** A `#[Computed]` method runs on the server each request and is not part of the snapshot; only the HTML the template prints reaches the browser. Mask values there, printing the last four digits of an IBAN, for example. 4. **Hide class names if they matter.** A model property's snapshot entry includes its class, `App\Models\Payroll\BankAccount`, unless a `Relation::morphMap()` alias is registered. 5. **Mind arrays.** `public array $employee = $model->toArray()` publishes every attribute that `toArray()` returns, far more than the view shows. ## Before and after on a payroll screen ```php // Leaks: both values are in wire:snapshot on every response public string $providerToken; public array $bankDetails; public function mount(Employee $employee) { $this->providerToken = config('services.payroll.token'); $this->bankDetails = $employee->bankAccount->toArray(); } ``` The fixed component keeps `public Employee $employee` for identity, reads the token inside the `pay()` action, and exposes a `#[Computed]` method returning only a masked account number for the view. The browser now receives the employee's class and key, plus the four digits the template prints. ## What reviewers look for - Public properties named `*token*`, `*secret*`, `*password*`, `*iban*`, or holding `->toArray()` output. - Arrays built from `toArray()` of whole records, where the array, not the view, decides what ships. - Assumptions that `#[Locked]` or the checksum hides data. The general rule that a server-rendered page must not serialize server-only values applies to every framework; the Livewire-specific part is knowing that **public means shipped**, and that the snapshot is the vehicle.