Validate nested Laravel input without accepting surprise admin fields

A profile form exposes a name and email address. A visitor adds an is_admin field to the request. If the controller passes broad request data into persistence, the server may accept fields the form never displayed.

Describe the allowed shape

$validated = $request->validate([
    'profile' => ['required', 'array:name,email'],
    'profile.name' => ['required', 'string', 'max:120'],
    'profile.email' => ['required', 'email', 'max:254'],
]);

$user->fill([
    'name' => $validated['profile']['name'],
    'email' => $validated['profile']['email'],
])->save();

This example assumes the current user is already authorized to edit this profile. Email changes may need a verification workflow; validation alone does not confirm ownership.

Keep three boundaries distinct

Validation establishes accepted input. Authorization establishes who may perform the operation. Model assignment rules limit which attributes can be assigned in bulk. Each has a different job.

An explicit assignment list makes this small operation easy to review. A future developer adding a form field must also decide whether it belongs in persistence. Do not use the existence of a frontend field as proof that every caller is trusted.

Test the extra key

Send the valid payload, then send the same payload with profile.is_admin added. Expect validation failure for the restricted shape. Assert that the database role remains unchanged.

Also test a profile array replaced with a string, a missing email, and an unauthorized user. A test that only confirms the form renders cannot protect these server-side boundaries.

If you intentionally allow optional nested fields, define those keys and rules explicitly. Avoid a growing collection of ad hoc exclusions that misses the next sensitive column. Laravel's array validation documentation explains how to restrict allowed keys.