Laravel Security

Use this when writing or reviewing code that touches user input, models, raw queries, Blade output, or authorization.

This pack has no evidence/citation registry (no SOURCES.md-equivalent exists in this repo). The guidance below is written directly from Laravel's documented behavior; if a claim needs a citation for a specific PR, verify it against the installed framework version rather than assuming an ID exists here.

Mass Assignment

• $fillable/$guarded control what Model::create()/update()/fill() accept, but they are not the first line of defense — a Form Request that only allows specific validated keys through is. Never pass $request->all() into fill()/create()/update(); pass $request->validated() (or an explicit array) so an attacker can't add unexpected keys the request happens to receive even if the model's fillable list is later loosened.
• forceFill() and forceCreate() bypass $fillable/$guarded entirely. Only use them for trusted, hardcoded internal values (e.g. system-set fields in a job or seeder) — never with any value derived from request input.
• Relationship-scoped create() sets the relation foreign key from the relationship, not from the request. Treat ownership changes as a separate authorization boundary: never pass request input into associate(), dissociate(), or a direct update() of a foreign key/owner column without authorizing the target relationship. Keep relationship-scoped writes to only the columns the relationship should accept — validate requests against an explicit allowlist, not the model's full fillable set.
• Prefer $fillable (allowlist) over $guarded for any model reachable from user input. protected $guarded = [] disables mass-assignment protection entirely — treat it as equivalent to no protection, not a stricter default.

SQL Injection