Optional middleware to prevent POST-only routes without functional GET (CSRF misuse guardrail)

[selimwdev]

Laravel Version

12

PHP Version

8.2

Database Driver & Version

No response

Description

Many Laravel applications have POST-only routes, especially for resource controllers (e.g., admin registration), without providing the corresponding GET (create) route or form.

This creates a potential security risk: an attacker could use a CSRF token from a completely unrelated form to submit to the POST route, performing unintended actions like creating admin accounts.

Resource controllers usually avoid this issue because store normally has a corresponding create GET route. However, in custom POST endpoints or scaffolded routes generated by laravel/ui, the GET form may be missing, leaving the POST route exposed.

Proposed Solution

Introduce an optional middleware that ensures POST requests are allowed only if the corresponding GET route exists and is functional (HTTP 200).

• Middleware should be optional to avoid breaking existing applications.
• Can apply to:
  • Resource controllers (recommended)
  • Individual POST endpoints if desired
• Optional configuration to map POST routes to GET routes if URIs differ.
• Cache GET route check results to prevent performance/DOS issues.
• Behavior: warn or block POST requests if GET is missing/non-functional.

This approach prevents CSRF misuse while remaining developer-friendly and backward-compatible.

Steps To Reproduce

1. Scaffold a resource controller using laravel/ui, for example an admin registration resource.
2. Remove or disable the GET create route for this resource, leaving only the POST (store) route active.
3. Open any unrelated form in the same application that has a valid CSRF token.
4. Using a tool (Postman, curl, or browser automation), submit a POST request to the admin/register POST route reusing the CSRF token from the unrelated form.
5. Observe that the POST request succeeds, creating a new admin account, even though no GET form exists for the admin registration route.
6. Apply an optional middleware that:
   • Checks if the GET create route exists and is functional (returns 200).
   • Blocks or warns the POST request if GET is missing or non-functional.
7. Retry the POST request → it fails or is blocked, preventing CSRF misuse.

Notes

• Resource controllers normally avoid false positives since store has a corresponding create GET route.
• This issue mostly affects custom POST endpoints or scaffolded routes from laravel/ui where GET forms may be missing.
• Middleware should be optional, cache GET checks, and configurable to avoid DOS or high-load performance issues.

[selimwdev]

Regarding the architectural philosophy of this proposal

I would like to clarify that the core of this proposal isn't about the technical robustness of Laravel's CSRF protection—we all agree it is solid and session-based. The real issue lies in the architectural integrity of the application structure.

In a standard web environment (non-API), a POST (store) action without a corresponding GET (create) is almost always a sign of misdevelopment, an oversight, or a forgotten route by the developer. For instance, if a resource like AdminRegistration exists, having a store endpoint active while the create view is missing or disabled creates an unnecessary surface for misuse.

Currently, even though the CSRF token is valid for the session, it can be "repurposed" from a generic form to hit these exposed POST-only routes that shouldn't even be reachable without a functional UI.

The core argument is that Laravel should enforce a "Resource Integrity Contract":

• For a store operation within a web resource context, the framework should verify the existence and functionality of the corresponding create route.
• The same applies to update requiring a functional edit route.
• This isn't just a security guardrail; it’s a structural constraint that ensures the POST request is part of a legitimate, intended user flow.

If a developer defines a resource but forgets to disable the store route after removing the create view, the framework should act as the last line of defense. By ensuring the GET route isn't "broken" or missing, we enforce a Secure by Design philosophy, preventing the execution of sensitive actions that have no legitimate entry point.

[shaedrich]

Optional configuration to map POST routes to GET routes if URIs differ.

That's quite a lot for finding one missing line in a route file.

Maybe, this would be better suited as a rector rule or the like 🤔

an attacker could use a CSRF token from a completely unrelated form to submit to the POST route, performing unintended actions like creating admin accounts.

I don't see why this problem should exist exclusively with non-existing matching GET routes 🤨

Blocks or warns the POST request if GET is missing or non-functional.

How would that look in practice? Which HTTP response status code would you use?

[selimwdev]

Just to clarify, this isn’t really about Laravel’s CSRF protection itself CSRF is solid and works with sessions, so the token changes per session. Even if someone tried to reuse a token from another form, it would only work in the same session/browser.

The real thing I’m pointing out is POST endpoints that don’t have a real form behind them.

For example, if you have a resource with all the usual methods (create, store, etc.) but the GET/create route is missing or broken, then a POST request to store is probably not coming from a real user flow.

For single POST-only endpoints (like /register), we could optionally add middleware, like:

• /register => middleware (block if there’s no GET/form for this UI)
• ResourceRegister => middleware (block if the create/GET route is missing or broken)

For the middleware, I’d suggest returning 403 Forbidden if it blocks a POST without a real GET/form.

And of course, this middleware should be optional, so existing apps don’t break. The goal is just to add a little extra guardrail to make sure POST requests actually come from real user flows and not from “hidden” endpoints.

[selimwdev]

Just to clarify my point: the issue isn’t that every POST should always have a GET at the same URL. That only really makes sense for resources, because their pattern is clear if a resource doesn’t have a create route, then store shouldn’t exist either. That’s the main proposal.

For regular POST endpoints inside web routes (like /register), you could optionally add a check or middleware that requires a GET at the same URL, but it’s not the main focus.

So, the suggestion is really about resources, where the flow is predictable: no create → no store. For other single POST-only endpoints, the middleware could be optional if someone wants extra safety.

[shaedrich]

For the middleware, I’d suggest returning 403 Forbidden if it blocks a POST without a real GET/form.

Why should a POST return 403 Forbidden (4xx: Something went wrong on the user's end) when the dev has forgotten to add a corresponding GET route? It feels like we shift the responsibility to the wrong addressee here.

I mean, if you know, you always want them to come in pairs and you for some reason don't add the GET yet, shouldn't you just explicitly return your response status code of choice from the POST request (controller action) directly?

Just to clarify my point: the issue isn’t that every POST should always have a GET at the same URL. […] if a resource doesn’t have a create route, then store shouldn’t exist either.

Also, the fact that you are able to give use cases where people would omit a GET route means that they must have their reasons for this. It sounds like you want to enforce this rule more for consistency (I know, you created this issue because of security concerns and the middleware is optional, but therefore, it could be its own package). Wouldn't this rather mean that people use resources wrong and should use something other than resources for this task?

And if people don't have a form, would they then create an empty GET route that does nothing other than returning 200 OK just for the sake of it? I mean, the middleware isn't asking for more than this. This sounds a bit pointless to me.

Besides, I still don't exactly see the problem here: If the CSRF is valid, why would there be a security issue in the first place?

[marius-ciclistu]

That POST without a GET should be in API not in WEB. In anycase it should be protected by more than the CSRF. It should require auth.

[shaedrich]

In anycase it should be protected by more than the CSRF. It should require auth.

Yeah, that's why it's not adding up.

However, there's a case where a GET might have multiple POSTs, so essentially, the form view that is posted isn't returned on its own:

<!-- /resources/views/post.blade.php -->
<form action="/post" method="POST">
    @csrf
    <input type="text" name="title">
    <textarea name="content"></textarea>
    <input type="submit" value="Create Post">
</form>

<!-- /resources/views/page.blade.php -->
<form action="/page" method="POST">
    @csrf
    <input type="text" name="title">
    <textarea name="content"></textarea>
    <input type="submit" value="Create Page">
</form>

<!-- /resources/views/dashboard.blade.php -->
@include('post')
@include('page')

<!-- /routes/web.php -->
Route::view('/', 'dashboard');
Route::post('/post', [PostController::class, 'store']);
Route::post('/page', [PageController::class, 'store']);

[selimwdev]

The 403 is not meant to blame the user.
This proposal explicitly targets web resources, not APIs.

In APIs, a POST endpoint can be legitimately reached via documentation or clients.
In web routes, however, POST actions are expected to be part of a user flow, which is why CSRF exists in the first place.

CSRF is not only about preventing cross-user attacks; it also implicitly assumes that a real form exists somewhere in the application.

When a resource defines a store action without a corresponding create, that flow is structurally broken. In a resource context, create → store is an implicit contract developers rely on.

In practice, missing create routes usually happen due to developer mistakes (forgotten routes, removed views, scaffolding conflicts), especially in admin registration flows. This has been repeatedly observed in real-world applications.

The middleware is optional and scoped to resources only.
If a developer explicitly adds an empty create route, that is a conscious decision to make the action publicly reachable, and the framework should not interfere further.

The goal is not to enforce behavior, but to provide a guardrail against unintended, unreachable POST actions in web resources.

[shaedrich]

The 403 is not meant to blame the user. […] In practice, missing create routes usually happen due to developer mistakes (forgotten routes, removed views, scaffolding conflicts), especially in admin registration flows. This has been repeatedly observed in real-world applications.

This explains why 4xx is not the proper HTTP response status code, let alone this shouldn't even be handled by status codes but by tooling as explained earlier

The middleware is optional and scoped to resources only.
If a developer explicitly adds an empty create route, that is a conscious decision to make the action publicly reachable, and the framework should not interfere further.

Adding the middleware is conscious as is adding a create route—doesn't that cancel each other out? When I always know when I consciously add said route, why would I need the middleware?

[selimwdev]

The decision may be conscious in code, but that doesn’t mean it’s always a conscious security decision.

Laravel already works this way in other areas.
For example, CSRF is mandatory for forms, yet Laravel allows state-changing GET endpoints. When a developer does that, they are explicitly stepping outside the intended flow — and Laravel does not stop them. That’s a conscious bypass.

Resources follow the same philosophy:
create → store and edit → update are expected flows.

If a developer explicitly defines a create route (even an empty one), that’s a conscious choice to bypass the default flow, and the framework should not interfere.

But when store exists without create, that’s often not intentional — it’s usually a broken or incomplete resource flow caused by refactors or missing views.

The middleware doesn’t second-guess conscious decisions.
It simply enforces the resource contract unless the developer explicitly opts out.

That’s consistent with Laravel’s approach: safe defaults, clear flows, and explicit escape hatches.

[shaedrich]

That’s consistent with Laravel’s approach […] When a developer does that, they are explicitly stepping outside the intended flow — and Laravel does not stop them. That’s a conscious bypass. […] It simply enforces the resource contract unless the developer explicitly opts out.

There's one key difference: The middleware is optional, hence opt-in. That makes bypassing it redundant

[selimwdev]

I understand your point. We can make the middleware non-optional in new versions, so it becomes a built-in part of the resource contract, ensuring that flows like create → store are properly enforced.

This way, we improve security in new releases without breaking existing applications.

What do you think?

[shaedrich]

I still think this should be solved differently.

[selimwdev]

I think there could be another solution: have a guardrail in the Laravel core that ensures the resource flow is correct (create → store, edit → update). This would apply to new versions, so existing applications won’t break.

If a developer doesn’t want this behavior, they could override or opt out, keeping flexibility while improving security by default.

[selimwdev]

Optional middleware or a package would be redundant—developers aware of the resource flow already handle create → store correctly.

Having it in core acts as a guardrail for accidental misconfigurations, while still allowing conscious overrides. This improves security in new versions without affecting existing apps and aligns with Laravel’s philosophy of safe defaults and explicit escape hatches

[MOHRIDER619]

non-Laravel dev here just jumping in on this, i've been going through the discussion and follow-up comments and still not understanding what's the case here.

The core of your argument seems to rest on the idea that CSRF "implicitly assumes a real form exists," but isn't that a fundamental misunderstanding of what CSRF is actually doing? CSRF is a cryptographic proof of session origin, it doesn't care about the UI or the path a user took to get to an endpoint. By trying to force a check for a GET route, aren't you trying to turn a stateless security token into a stateful navigation tracker? and POST endpoints in general have tons of ways to reach them and it feels like you're treating a developer's messy route file as a framework vulnerability. laravel already gives us ->only() and ->except() according to @shaedrich to define exactly which routes should be open. If a developer leaves a POST route active, they’ve explicitly told the framework "this endpoint is open for business." Why should the framework then turn around and second-guess that at runtime by checking if a sibling GET route returns a 200? and ignoring the "HTTP status code" discussion which would turn into a debugging nightmare for devs, yet i still don't understand the issue at all (i might be dumb or missing something on this since i don't use laravel so let me know if i'm misunderstanding something).

If the goal is to stop developers from leaving orphaned routes open (Educational issue rather than technical), wouldn't this be much better handled by a static analysis tool or a simple php artisan route:list check during CI/CD? Why add the runtime overhead and the "magic" of internal sub-requests to the core framework to solve a discipline problem that already has explicit solutions?

and according to laravel's documentation

Laravel automatically generates a CSRF "token" for each active [user session](https://laravel.com/docs/12.x/session) managed by the application. This token is used to verify that the authenticated user is the person actually making the requests to the application. Since this token is stored in the user's session and changes each time the session is regenerated, a malicious application is unable to access it.

The steps mentioned to reproduce doesn't show any vulnerability, if an attacker got access to the user's CSRF token via XSS or chained with any other vulnerability it would still reach the same impact if the POST endpoint has a form, (Assuming that CSRF tokens are generated per form not per session)

- Open any unrelated form in the same application that has a valid CSRF token.
- Using a tool (Postman, curl, or browser automation), submit a POST request to the admin/register POST route reusing the CSRF token from the unrelated form.