Strict mode and FormRequest in Laravel for safer validation

Home » Python » Strict mode and FormRequest in Laravel for safer validation

Working with FormRequest classes in Laravel can get messy fast when your data types are loose, your validation rules are permissive, and your application silently casts values behind your back. PHP’s default weak typing tries to be helpful by converting strings to numbers, numbers to booleans, and more, but in real-world Laravel apps this often explodes later in business logic, not where the data first enters the system.

Enabling PHP’s strict typing and pairing it with Laravel’s FormRequest validation gives you a powerful safety net: types are checked aggressively, invalid data is rejected early, static analysis tools like PHPStan and Larastan can fully understand your code, and refactoring becomes far less risky. Instead of sprinkling is_numeric, is_null or defensive checks everywhere, you lean on the type system and well-structured validation layers.

Why strict types matter so much in Laravel applications

By default, PHP performs automatic type coercion, which seems convenient until your Laravel code relies on exact types for logic, comparisons, or calculations. The classic example is passing a string like "42" to a place where an int is expected: in weak mode, PHP happily converts it; in strict mode, it throws a TypeError and forces you to fix the source of truth.

The same problem appears with booleans and validation rules such as boolean, integer, or numeric in Laravel. Under the default loose behavior, values like "1", "0", 1, 0, true and false are often accepted or silently converted. That means a JSON payload like {"notifications_enabled": "1"} passes validation, but a strict comparison in your logic ($settings === true) fails because the stored value is actually a string.

This silent coercion is especially dangerous in large Laravel projects where values flow through controllers, services, jobs and events. A field that is “close enough” at the controller level might become an unexpected type deep inside a service layer, and debugging that mismatch costs hours. With strict types turned on, you get an immediate exception pointing at the exact file and line where the incompatible type was passed.

Numeric conversions are another major source of subtle bugs. If you pass 10.5 to a parameter typed as int in weak mode, PHP truncates the value to 10 without warning. In strict mode, this raises a TypeError, forcing you to decide explicitly if you should round, floor, ceil or reject the value. That is a huge win for financial calculations, reporting features, and any feature that relies on precise numeric values.

Type hints also protect you from nonsensical values that weak typing would accept. For example, if a function expects a bool but you accidentally pass a Closure or an array, weak mode might not complain immediately, leading to awkward behavior later. Under strict types, you get an error at the point of the wrong call, making the bug trivial to track down.

How PHP strict types work in practice

To enable strict types for a PHP file, you add the declaration declare(strict_types=1); right after the opening <?php tag. This declaration tells PHP that, for this specific file, scalar type hints (like int, string, float, bool) must be respected exactly for both parameters and return values. Consulte un tutorial de PHP desde cero para repasar los fundamentos si es necesario.

In strict mode, passing a value of the wrong scalar type to a function will throw a TypeError instead of letting PHP try to “fix” it. For instance, sending '10' (a string) to a method that expects an int is no longer accepted. Similarly, if a function declares a return type of int but actually returns 3.5, strict mode will raise an error rather than silently truncating to 3.

It is important to understand that strict_types works at a file level and affects calls made from that file. The strictness applies when the file with the declare statement is the caller. It does not retroactively force strictness on every file in your project, which is why real-world migrations are often gradual and per-file or per-directory.

Even in strict mode, PHP still allows some “safe” conversions. For example, passing an int where a float is expected is allowed because there is no loss of precision in that direction. The strict behavior is focused on avoiding dangerous, lossy, or ambiguous conversions (like string to number, float to int, or string to bool) that commonly cause logic errors in Laravel code.

From a Laravel perspective, this strictness dramatically improves the reliability of code using type-hinted controllers, services, DTOs and, of course, FormRequests. When your FormRequests guarantee specific types for input, and your application code requires those types, a mismatch reveals itself immediately instead of sneaking into production.

Enabling strict types across a Laravel project

The quickest manual way to enable strict typing is to add declare(strict_types=1); to the top of every PHP file you write, immediately after the opening tag. However, doing this file by file is repetitive and error-prone, especially in existing codebases.

Laravel gives you a more scalable option through stubs. By running php artisan stub:publish, you publish all of Laravel’s default stub files into a /stubs directory at your project root. Once there, you can open files such as controller.stub, model.stub, migration.stub, and others, and add the strict types declaration at the top. Any new controller, model, or other class you generate using Artisan commands will then include strict types automatically.

You can also configure your IDE or editor to inject the strict declaration into new PHP files. In PhpStorm, that means adjusting the File and Code Templates so that any new PHP class or interface includes declare(strict_types=1);. In VS Code, you can define custom User Snippets that serve as the boilerplate whenever you create a new file, making strict types the default for your workspace.

For existing code, automated tools are invaluable. Laravel Pint, the framework’s official opinionated code style tool, can be configured to add strict type declarations for you. By creating a pint.json file in your project and enabling the "declare_strict_types": true rule, you can run ./vendor/bin/pint to automatically insert declare(strict_types=1); at the top of your PHP files.

If you want to roll this out cautiously, you can aim Pint at a subset of your project first. Running ./vendor/bin/pint app/ focuses the strict types addition only on your application code, ignoring vendor packages or legacy modules that you are not ready to touch. This sort of scoped rollout is particularly useful when you are working in a monolith with mixed-quality code.

Once you start enforcing strict types, it is wise to ensure that new files never regress. PHP CodeSniffer (PHPCS) can help here: adding the Generic.PHP.RequireStrictTypes rule to your standard ensures that every new or modified file must include the strict declaration, or your CI pipeline will fail. That way, you can allow untouched legacy files to remain as they are, while guaranteeing that any new or updated code adheres to strict typing.

Strict validation vs flexible validation in Laravel

Laravel’s built-in validation rules are powerful, but many of them are designed around PHP’s flexible typing model. Rules like integer, numeric, and boolean willingly accept a wide variety of inputs: '25' passes as an integer, "1" and "0" pass as booleans, and numeric strings are treated as numbers without complaint.

When your application logic later performs strict comparisons or expects a concrete type, that flexibility becomes a liability. A field validated as integer might still be a string if your code never casts it, and a boolean-like flag stored as "1" instead of true can fail identity checks, break array uniqueness operations, or cause subtle bugs when serializing or caching.

The difference between “loose” and “strict” behavior is especially visible when comparing how values are treated at validation time versus runtime. For example, in flexible mode, returning 3.5 from a function that declares : int silently truncates the decimal; in strict mode, that mismatch triggers a TypeError. The same philosophy should extend to your validation layer: accepting "25" as a number may let a request pass, but it means downstream code receives a value that does not actually match its type expectations.

Boolean validation is another classic pitfall. Laravel’s boolean rule, by default, treats true, false, 1, 0, "1", and "0" as valid. While this is convenient for HTML forms, it can be treacherous in JSON APIs and SPA backends, where you usually expect genuine booleans. Having a flag come through as "0" might accidentally pass a validation rule but fail in application logic that checks === false.

Even array uniqueness checks behave differently under loose vs strict comparisons. With weak typing, values like 1 and "1" are treated as equal in scenarios like checking uniqueness in arrays, which can cause subtle logic errors when you rely on keys or unique identifiers that must preserve their type.

In a strict setup, you aim to accept only exactly-typed values at the application boundary. That usually means communicating clear JSON contracts to clients (for APIs) and casting or transforming data during validation so that, by the time the request touches your domain logic, the value types are predictable and enforced.

FormRequest: structuring validation and authorization

Laravel’s FormRequest classes are tailor-made for centralizing complex validation, authorization, and redirection logic away from controllers. Instead of cluttering controller methods with long validation arrays, you move all of that into a dedicated class that intercepts the HTTP request before the controller action executes.

You create a FormRequest using Artisan with a command like php artisan make:request ProductCreateRequest. Laravel then generates a file in app/Http/Requests that extends Illuminate\Foundation\Http\FormRequest. This base class brings along a rich set of methods and properties that you can override to fine-tune how validation behaves.

Every FormRequest ships with two core methods: authorize() and rules(). The authorize() method decides whether the authenticated user is allowed to perform the action represented by the request. Returning true means “go ahead”; returning false automatically triggers a 403 response and the controller action never runs.

One common gotcha is that new FormRequests default to authorize() returning false. If you are deferring authorization logic to policies, gates, or elsewhere, you must explicitly set authorize() to return true; otherwise, all requests using that FormRequest will be rejected with a forbidden response.

The rules() method defines the validation rules for the incoming data. It returns an associative array mapping field names to rule strings or arrays. For example, a product creation request might declare that name is required and price is required with a minimum value of 0. These rules are executed automatically before your controller method is called.

Because FormRequest extends Laravel’s base request class, it can also override a variety of other methods. You can customize validation error messages via messages(), rename attributes for nicer error strings via attributes(), and even modify the way redirection works after a validation failure by tweaking specific protected properties.

Customizing messages, attributes and redirection behavior

When validation fails, Laravel builds default error messages using language entries stored in lang/en/validation.php (or equivalent per locale). FormRequest allows you to override those defaults on a per-request basis using the messages() method, which returns an array keyed by field.rule notation.

Within messages() you can tailor the tone and clarity of feedback. For example, you might define a custom message for name.required to say that the product name is mandatory, or for price.min to state that the price cannot be negative. These custom messages are extremely useful when a single request has many fields and you want friendly, domain-specific wording.

Similarly, the attributes() method lets you rename field identifiers for error output. Internally you may favor short or snake_case keys like items_per_page, but you can expose human-friendly labels such as “items per page” or “sale price” in messages. Laravel will replace the :attribute placeholder with the custom names you return from this method.

FormRequests also give you control over where users are redirected after validation fails. Besides the default behavior (redirecting back to the previous URL), you can set protected properties like $redirect (explicit URI), $redirectRoute (named route), or $redirectAction (controller action) on the FormRequest. Laravel’s internal getRedirectUrl() method inspects those properties and decides which location to send the user to when validation does not pass.

The $dontFlash property is another valuable tool. It holds an array of input keys that should not be flashed to the session when redirecting back after a validation error. By default, this includes sensitive fields like password and password_confirmation. You can expand this list to cover other confidential data that you never want to reappear in forms, even temporarily.

If you need to fully change how the failed validation response works, you can override lower-level hooks. Recent versions provide attributes like StopOnFirstFailure and FailOnUnknownFields that you can apply to the FormRequest class, as well as attributes for custom error bags or different redirect targets. Under the hood, these integrate with Laravel’s validation system and the 422 JSON response format used for XHR requests.

Preparing and normalizing input around validation

Real-world HTTP input is rarely in the exact format or type your domain logic expects. That is why FormRequest includes lifecycle hooks to manipulate or normalize data before and after validation runs, helping you bridge the gap between external payloads and internal expectations.

The prepareForValidation() method runs before any rules are applied. This is the perfect spot to merge default values, adjust field names, cast strings to the proper types, or reshape arrays. For example, you might lower-case an email, convert numeric strings to integers, split a comma-separated list into an array, or map camelCase JSON keys to snake_case request keys used in your rules.

After validation succeeds, passedValidation() gives you a hook to further massage already-validated data. If you need to normalize something that depends on rules having passed, or you wish to construct derived values and add them to the request, this method is where you would do it. Because validation is already complete, you are dealing with trusted data.

These hooks are especially powerful when combined with strict types in your controllers and services. You can ensure that values are cast to the correct types inside prepareForValidation() or passedValidation(), and then confidently rely on type hints in your method signatures. The result is a cleaner boundary: all messy external inputs are handled in a single dedicated layer, and everything beyond that is strongly and consistently typed.

Behind the scenes, failed validation still follows the same Laravel semantics for both browser and API clients. In a classic browser flow, the user is redirected back, the validation errors are flashed to the session, and the previous input (excluding keys in $dontFlash) is also flashed so that you can repopulate the form with old(). In XHR or JSON-expected requests, Laravel responds with a 422 status code and a JSON payload of validation errors in “dot notation” for nested keys.

Using FormRequest in controllers with strict typing

Once you have defined a FormRequest, using it inside a controller is straightforward and plays nicely with strict types. Instead of type-hinting Illuminate\Http\Request in your controller action, you type-hint your custom FormRequest class. Laravel resolves the FormRequest, runs authorization and validation, and only if everything passes will it call your controller method.

This means your controller code can safely assume that the request data is valid according to the rules declared in the FormRequest. There is no need to call $this->validate() or use the Validator facade inside the controller method. If validation fails, your controller is never executed; instead, Laravel automatically handles redirecting or returning a JSON error response.

In legacy code, you often see validation done directly in controllers, either via $this->validate($request, ) or manually building a validator through Validator::make(). While that approach works for simple forms, it leads to bloated controllers with duplicated rules when you need the same validation logic in multiple places (for example, create vs update flows).

Switching to FormRequest centralizes that validation logic, making it reusable across endpoints and easier to test in isolation. When combined with strict types, you end up with controller actions that are small, explicit, and type-safe: they receive a properly validated request object, possibly with transformed input, and immediately move into business logic without worrying about malformed data.

From a maintenance perspective, this separation improves readability for your whole team. Developers know that validation and authorization rules live in FormRequest classes, domain logic lives in services or controllers, and type hints are trustworthy throughout the stack. That clear separation pays dividends as the application grows and new teammates join.

Static analysis, IDE support and type coverage

Enabling strict types becomes significantly more powerful when you introduce static analysis tools like PHPStan and its Laravel-focused extension Larastan. These tools inspect your codebase without executing it, looking for type mismatches, unreachable code, invalid method calls and other issues that traditional testing might miss.

PHPStan offers 11 levels of strictness, from a very forgiving level 0 up to an extremely rigorous level 10. Teams often start low and ramp up over time, fixing issues iteratively. Some organizations even maintain multiple configuration files: a “learning” level for new developers, a “development” level for everyday work, and a “strict” level enforced in CI/CD pipelines.

The baseline feature is a key strategy for large or older codebases. You run PHPStan once, export the current list of errors into a phpstan-baseline.neon file, and configure PHPStan to ignore those baseline issues while still flagging any new ones introduced in subsequent code changes. This lets you improve type safety incrementally without freezing feature development.

For Laravel specifically, Larastan teaches PHPStan how to understand framework features like facades, Eloquent relations, dynamic properties, and container resolution. Without Larastan, a lot of Laravel idioms look suspicious or magical to a static analyzer; with it, most of your typical patterns become fully analyzable, and you gain insight into type issues in models, FormRequests and controllers.

Real-world teams have reported strong results using such tools. One case involved a long-lived Laravel application with more than 100 endpoints and over 2,000 tests: even with a comprehensive test suite, adopting PHPStan with Larastan still uncovered numerous subtle type issues that tests had not exposed. By defining type aliases for complex validation structures in FormRequests, they achieved high type coverage and made future refactors far safer.

Integrating tests into this quality pipeline brings even more confidence. You can configure PHPStan to analyze not only your app/ directory but also tests/, and declare typed properties and method signatures in your test classes, for example public User $user; or public function test_example(): void. A convenient pattern is to add a Composer script (often named “quality”) that runs both static analysis and your test suite in one go.

Gradual adoption in legacy Laravel projects

Introducing strict types and strong validation into a mature Laravel codebase can be intimidating, but it does not have to be an all-or-nothing move. The most sustainable strategy is incremental, focusing first on critical or frequently-touched areas like app/, then progressively extending coverage to tests, database-related code, and feature-specific modules.

Many teams start by enabling strict types and static analysis on new code only. You configure tools like Pint, PHPCS and PHPStan to run against changed files (for example through Git hooks using Husky and lint-staged), ensuring that anything you touch is upgraded to the new standard while untouched legacy code remains functional.

Another effective tactic is to define PHPStan type aliases for recurring structures, especially for complex FormRequest validation schemas. Instead of repeating huge docblocks for each request class, you define a single alias that describes the shape of a validated payload and reuse it across the project. That keeps your documentation DRY and helps PHPStan understand the exact types involved.

Static analysis levels can be mapped to different phases of your adoption journey. Lower levels (0-2) focus on basic issues like unknown classes or missing functions. Middle levels (3-5) start enforcing return types and identifying dead code. Around level 6, you get stronger type coverage including generics (such as Collection<Model>). At higher levels (8-11), you begin tracking null-safety, mixed usage, and stricter rules about implicit casting.

Teams that have gone through this process in large Laravel apps have found that a measured, stepwise approach is far more manageable than trying to jump straight to maximum strictness. By picking an initial level, enabling baselines, and gradually raising requirements, you keep progress steady while minimizing disruption for active development and production stability.

Combined with FormRequest-based validation and strict type declarations, this methodical adoption leads to code that is easier to reason about, safer to refactor, and far more resistant to subtle data-related bugs. It transforms type safety from a theoretical ideal into a practical guardrail woven through every layer of your Laravel application.

Bringing all these ideas together, strict typing in PHP, carefully designed FormRequests, and robust static analysis form a synergistic trio that dramatically improves reliability in Laravel projects: requests are validated and normalized early, types are enforced both at runtime and at analysis time, IDEs provide richer autocompletion and error hints, and the entire team can refactor or extend functionality with much greater confidence that regressions will be caught before they hit production.