Consider a Laravel model with no $fillable or $guarded properties defined. What will happen if you try to create a new model instance using mass assignment with request data?
User::create($request->all());
Think about what happens if you don't specify which fields are allowed for mass assignment.
By default, Laravel sets $guarded = ['*'] if neither $fillable nor $guarded is explicitly defined on the model. This guards all attributes and throws a MassAssignmentException when attempting mass assignment.
Given a Laravel model, which of the following correctly protects the model from mass assignment vulnerabilities?
class Post extends Model {
// protection here
}Remember, $fillable defines allowed fields, $guarded defines disallowed fields.
Setting $fillable to an array of allowed fields explicitly permits only those fields for mass assignment, protecting the model.
Given this model and controller code, why does the mass assignment fail?
class Product extends Model { protected $guarded = ['id']; } // In controller Product::create(['id' => 5, 'name' => 'Book', 'price' => 10]);
Check which fields are guarded and what is being assigned.
The 'id' field is guarded, so including it in mass assignment causes Laravel to throw a MassAssignmentException.
Given this User model and code, what will be the value of $user->admin after creation?
class User extends Model { protected $fillable = ['name', 'email']; } $user = User::create(['name' => 'Alice', 'email' => 'alice@example.com', 'admin' => true]);
Check which fields are allowed in $fillable and what happens to others.
Since 'admin' is not in $fillable, it is ignored during mass assignment and remains null.
Which of the following best explains why Laravel uses mass assignment protection?
Think about what could happen if users could set any attribute freely.
Mass assignment protection prevents users from setting sensitive fields like 'is_admin' or 'balance' which could lead to security breaches.