Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

travisobregon's avatar

Is there a case to keep "_token" as part of the request?

Once the VerifyCsrfToken middleware has executed, should the "_token" be removed? I'm just wondering if people still use it in their controllers or something else?

Should this line be added to the middleware?

$request->offsetUnset('_token');

So that the handle method becomes:

        if (
            $this->isReading($request) ||
            $this->runningUnitTests() ||
            $this->inExceptArray($request) ||
            $this->tokensMatch($request)
        ) {
            $request->offsetUnset('_token');

            return tap($next($request), function ($response) use ($request) {
                if ($this->shouldAddXsrfTokenCookie()) {
                    $this->addCookieToResponse($request, $response);
                }
            });
        }

        throw new TokenMismatchException;
0 likes
11 replies
jlrdw's avatar

The token is compared with a token that is in session so yes it's part of the request and properly disposed of as all of the request is.

Basically it has to match another token that is stored in session.

You need to go to Owasp site and study up on security.

travisobregon's avatar

@JLRDW - At the point where I added $request->offsetUnset('_token');, the token has already matched. So I was looking for feedback to see if the "_token" parameter is still useful afterwards.

jlrdw's avatar

No after the match. You really need to go to owasp and learn this stuff it explains everything.

You really have no control over that request until it is disposed of.

Go to the Docs read about request cycle.

Basically it's something that happens in the background that you do not even need to worry about.

travisobregon's avatar

@JLRDW - I understand the reason for the token.

Let's say in your controller, you execute request()->all(). Currently, this will return something like:

[
  "_token" => "UMNcQX8nhi4rO70VJPLukTtyL5bP0aJCrtLIAqp5",
  "foo" => "bar"
]

It would be nice if it only was:

[
  "foo" => "bar"
]

This was just a thought I had, and I was wondering if there was a use case where people still needed "_token" as a parameter on the request.

BillRiess's avatar

@travisobregon you're safe to remove it but really you don't need to - you don't gain anything by removing it after it has been validated. If you want to get a request object without the token you can just use request()->except('_token') or better yet, use request()->only('fields', 'you', 'want').

shez1983's avatar

@travisobregon @jlrdw sometimes thinks what he is saying makes sense.. but @billriess is right - u can ignore it or remove it if you so desire.. if you have fillables in your model then you can simply do Mode::create($request->all()) and everything should be taken care of..

1 like
Snapey's avatar

I prefer to be explicit about what I'm writing to the model rather than just chucking the whole request and hoping its ok.

Yes, you could remove the _token in middleware. It would not make a difference to me as its never an issue. Try with a PR to the framework?

jlrdw's avatar

Why would you even think about moving the token I never even conceived someone would ask such a question.

It's there for a reason. And really no extra overhead.

Again study owasp for a week.

rather than just chucking the whole request

I'm glad I'm not the only one who likes to get the individual requests parameters one at a time.

Sometimes there can be too many shortcuts.

jlrdw's avatar

@shez1983 I had already said

No after the match.

Meaning no it's not necessary to keep after the match, read it.

So now what are you saying is that right, wrong?

Ditto @travisobregon I already gave the same answer no it's not necessary.

But you even asking such a question is telling me you do not understand it otherwise you would have known the answer one more time study owasp.

BillRiess's avatar

I don't see what owasp has to do with this question though. Clearly, he is asking about removing the field after it has been validated, which means it is no longer going to be used for the rest of the request lifecycle. This also implies he understands its purpose. I do agree, however, that removing it does not gain any benefit whatsoever.

1 like

Please or to participate in this conversation.