NEW in Laravel 13.5: Strict Mode for Form Requests

Laravel Daily| 00:06:48|Apr 16, 2026

Chapters8

Introduces the new Laravel 13.5 feature and how it enforces strict validation by disallowing unknown fields.

Laravel 13.5 adds form request strict mode to block unknown fields, but it’s not a one-size-fits-all fix—watch how it behaves with CSRF tokens and global settings.

Summary

Laravel Daily’s latest look at Laravel 13.5 focuses on the new form request strict mode. The video demonstrates the core idea: when you enable strict mode, Laravel will flag fields that aren’t explicitly defined in your form request rules, serving as a safeguard against mass assignment leaks. Denis (the creator) walks through a practical example using a User table with an is_admin column that isn’t in the form, showing how relying on request all can let hidden fields slip through. He contrasts this with request validated, which returns only fields that pass the rules. He also shows how to enable strict mode on a single form request via the fail on unknown fields PHP attribute, and how to enable it globally from a service provider. The discussion isn’t just positive press; Denis raises caveats about real-world edge cases, like CSRF tokens (underscore_token) being flagged as unknown by default and the potential for over-strict behavior in production. The overall takeaway is that strict mode is a powerful tool, but you should test it thoroughly in your app’s specific context before flipping every project to it. As always, he hints at premium Laravel Daily content to come, including new tutorials and a deeper dive into Laravel packages like the Laravel Debug Bar’s AI features.

Key Takeaways

Using request validated instead of request all ensures only validated fields reach the controller, preventing hidden form fields from being saved.
Enabling strict mode with fail on unknown fields flags any field not defined in the form request rules, acting as a firewall for unexpected input.
The is_admin field example demonstrates a real security risk when using request all alongside a global field like is_admin that isn’t present in the form.
You can enable strict mode on a per-form-request basis with the fail on unknown fields attribute, or enable it globally (e.g., in a service provider) for broader protection.
Underscore_token (CSRF) can be incorrectly flagged as unknown by strict mode, requiring a workaround with prepareForValidation to avoid breaking legitimate requests.
Denis points out that global strict mode can have unintended consequences and should be tested in real-world scenarios before adopting broadly.
The video also teases premium Laravel Daily tutorials, including new content for premium members and coverage of tools like the Laravel Debug Bar’s AI features.

Who Is This For?

Essential viewing for Laravel developers who are considering enabling strict mode in Laravel 13.5 or who want to understand the risks of using request all. It’s especially helpful for those responsible for form security and protecting against mass assignment in production.

Notable Quotes

""new feature of Laravel framework called form request strict mode released in the newest version 13.5 this week.""

— opening note about the feature and version.

""first the correct way of doing that is not use request all instead use request validated all the time in the controllers""

— core recommendation against mass assignment risk.

""is admin field is prohibited""

— demonstration of strict mode catching unknown fields.

""fail on unknown fields""

— naming the global feature and its intent.

""underscore token field which is flagged as unknown""

— CSRF token edge case that complicates strict mode usage.

Questions This Video Answers

How does Laravel 13.5 strict mode protect against mass assignment?
When should I enable strict mode for form requests in Laravel?
What happens to CSRF tokens like underscore_token with form request strict mode in Laravel?
Can strict mode be enabled globally, and what are the trade-offs?
Why should I prefer request validated over request all in Laravel controllers?

Laravel 13.5Form Request Strict Moderequest validatedrequest allfail on unknown fieldsCSRFunderscore tokenprepareForValidationLaravel Daily premium content

Full Transcript

Hello guys, in this video I want to show you a new feature of Laravel framework called form request strict mode released in the newest version 13.5 this week. A lot of people were happy about this change. So see amount of up votes on GitHub. But also with that, I want to show you an example of a feature that you shouldn't be quick to adopt something very new if it touches global things like global strict mode or something because to me it didn't fully work as intended. And let me show you maybe you will tell me I'm holding it wrong so to speak. However, the idea is very good and useful. So let me show you. Imagine you have a table of users database table with column is admin true or false. And then you have a simple invitation form or create user form with just name and email. So that is admin field is not in the form and this is managed elsewhere. But if it's not in the form, can it be still used in a hidden way? And this is one of the well-known security issues and how developers may use Laravel wrong if you're not careful and if in the controller of that form you use request all. So let me show you why it is a security issue. What is a better way to fix that? And what that new feature does globally for form requests. So in the form request in here we have validation proper. It seems to be name and email. We don't even mention that is admin column anywhere. Now look what happens if some malicious hacker tries to edit the HTML on the form. And this is done in a browser. just inspect and then you can on any field for example here edit as HTML and you start editing and you put something like this input type checkbox is admin checked and there we go we have checkbox checked now question will it be saved in the database let's try it out let's use fake filler chrome extension to fill those checkbox it's not aligned visually but it doesn't matter in this case we send the invitation we submit the form user invited successfully. Now look at the database. We have a new user with is admin one. So what has just happened? Why our form request didn't catch that? Because it didn't look for is admin. In the rules we have only name and email and in the controller we use request all and request all contains all the request even before the validation. So first the correct way of doing that is not use request all instead use request validated all the time in the controllers never use request all unless you really know what you're doing and why request validated is the way to go. It will return only those fields that pass through the rules. So if someone passes is admin password some token stuff like that it will not get returned into request validated. And this is where we get to that feature of form request strict mode. In case of someone forgets or by mistake or something if you still have request all in the controller that new feature in the form request would catch any field that is not in that list and would flag that as not validated prohibited. So you can enable that on a specific form request in this case with PHP attribute fail on unknown fields. And let's try to do that again. So I refreshed the form, added that is admin again in another place again fake filler Chrome extension and I send invitation and now look at the validation error. The is admin field is prohibited. So that form request detected some unknown field passing through the form and we have a firewall to not allow it through. Great. And also another way you can enable that even more globally instead of one form request you can do that in app service provider something like this form request fail on unknown fields not in production so similar condition like you would enable model should be strict or prohibit destructive commands something like that I'm not sure if it should be not in production it actually should fail on production to protect from the hackers but here's the thing with good intentions to be strict that command seems seems to be too strict. So in the issues of Laravel framework, I have this issue that fail on unknown fields actually flags the fields in get request which are not supposed to be flagged. They're kind of legit by their definition. But it's not only about those fields like per page expires or something. To me that feature didn't work at all at first because in the form I have a typical CSRF protection which under the hood creates underscore token field which is flagged as unknown. So for that to even work I had to make a workar around which is this prepare for validation remove the token from validation which doesn't make much sense. But if I comment that out and I try to just fill in the form without is admin or anything send invitation the token field is prohibited. So I'm not sure maybe I'm holding it wrong so to speak and maybe I'm missing something here but by default it seems to flag underscore token as also prohibited field. So that's what I meant in the beginning of this video that you shouldn't be too quick with applying something global from Laravel framework because the author of the pull request which may be from the core Laravel team has good intentions for their specific cases but for something global there may be totally different cases which the author may not know about and which tests may not catch but I'm not sure maybe it's something on my side but I've just installed it as a new Laravel 13.5 project totally fresh today. But in general, what do you think about this new feature? Is it in the right direction? I think it is. And if you tried it, let me know if it worked for you. And finally, in this video, I want to announce my plans to shoot more videos on Laravel Dailycom as premium tutorials. So, some of the things that I will try for new packages or something like that will go to premium tutorials here for premium members because I want to thank you guys who support me financially for premium. So, it's not just courses. It will be shorter videos. And I published just new video. Laravel debug bar has a new AI skill. Here's a tweet by Barry. I tried it out. And if you want to see how it works and did it work for me and how exactly in the premium tutorials, there's a 9-minute video which is uploaded only on Laravel daily website for premium members and I will not publish that on YouTube. So I will differentiate. I thought that one video per week minimum should be for premium members because they paid money for membership. So yeah, if you want to watch that video and other premium tutorials and courses, the link will be in the description below.