In an Eloquent model, what is the difference between $fillable and $guarded, and what happens to a key neither allows?

## What mass assignment is **Mass assignment** means setting many model attributes from one array in a single call. In Eloquent it happens in `fill()`, in `new Reservation([...])`, in `Reservation::create([...])` and in `$reservation->update([...])`, and in helpers built on them. It is convenient, and it is dangerous: if the array comes from a request, a user can add keys you never meant to accept, such as `is_vip` or `rate_cents`. Eloquent therefore filters every mass-assigned array through two lists on the model. | Setting | Meaning | Style | |---|---|---| | `$fillable` / `#[Fillable([...])]` | only these keys may be mass assigned | allow-list | | `$guarded` / `#[Guarded([...])]` | every key except these may be mass assigned | deny-list | | `#[Unguarded]` or `$guarded = []` | every key may be mass assigned | no protection | Use one of the two lists per model. The allow-list is the safer habit because a column added later is closed until someone opens it. ## The defaults and the three outcomes A fresh model declares `$fillable = []` and `$guarded = ['*']`. That combination is **totally guarded**, and it changes how `fill()` reacts to a key it will not accept. For each key, `fill()` gives one of three outcomes: 1. **Accepted** — the key passes `isFillable()`, so `setAttribute()` runs. 2. **Exception** — the model is totally guarded (or strict discarding is on), so `fill()` throws `Illuminate\Database\Eloquent\MassAssignmentException` with the message "Add [guest_name] to fillable property to allow mass assignment on [App\Models\Reservation]." 3. **Silently dropped** — the model has a list, the key is not allowed, and nothing is thrown. The value simply never reaches the model. That third outcome surprises people: once `$fillable` names at least one column, an unlisted key disappears without a word. `Model::preventSilentlyDiscardingAttributes()` turns those silent drops into `MassAssignmentException` too, which is why the docs call it from `AppServiceProvider::boot()` for local development. ## How each list is evaluated - `$fillable` is checked first. When it is not empty, `fill()` intersects the incoming array with it, so only listed keys are even considered. - `$guarded = ['*']` blocks everything not listed as fillable. - A specific `$guarded` list blocks the named columns, case-insensitively, and also blocks any key that is not an actual column of the table (Eloquent reads the column listing from the schema once per model class, unless the key has a mutator or class cast). That stops keys such as `options->is_vip` from slipping past a deny-list. - Nested JSON keys such as `options->enabled` must be named in `$fillable`; the docs state they are not supported through `$guarded`. ## What it does not protect Mass-assignment protection only filters arrays. It never checks: - direct assignment, as in `$reservation->is_vip = true;` followed by `save()`; - `forceFill()` and `forceCreate()`, which exist to bypass the lists on purpose; - anything inside `Model::unguarded(fn () => ...)`, which disables the checks globally for the callback. `db:seed` runs seeders this way, so seeders can mass assign freely. ## Laravel 13 attributes Laravel 13 lets the same settings live in class attributes. The skeleton's `User` model now ships with `#[Fillable(['name', 'email', 'password'])]` instead of a `$fillable` property. `#[Fillable]` is merged into the `$fillable` array; `#[Guarded]` and `#[Unguarded]` only apply while `$guarded` still holds its default. Behaviour is the same as the properties. ## A worked reservation ```php #[Fillable(['guest_name', 'check_in', 'check_out'])] class Reservation extends Model {} $r = new Reservation([ 'guest_name' => 'Ana', 'check_in' => '2026-10-01', 'is_vip' => true, // not listed: silently dropped ]); ``` `$r->is_vip` is `null`; nothing was thrown because the model has a fillable list and strict discarding is off. ## Details that come up in follow-ups - **Pivot models** are the exception to the default: an `Illuminate\Database\Eloquent\Relations\Pivot` subclass starts with `$guarded = []`, because pivot rows are written by the relationship methods rather than from request arrays. - `isFillable('is_vip')`, `getFillable()` and `getGuarded()` let a test assert the model's policy directly, so a later edit that opens a sensitive column fails a test. - `totallyGuarded()` returns true exactly when the fillable list is empty and the guarded list is `['*']`; that is the state in which `fill()` throws rather than drops. - A key listed in both `$fillable` and `$guarded` is fillable, because the allow-list is consulted first, which is one more reason to keep a single list per model.