Does this page really need CSRF protection?

We recently received a complaint from someone trying to subscribe to our Mastering Laravel community and it failed.

It was the classic example of a user opening a page, going to lunch, then coming back to submit a form and seeing the 419 Page Expired error.

I started thinking of some clever solutions to prevent CSRF/session timeouts, but then I thought: does this page actually need CSRF protection?

CSRF protection is in place to prevent a user from being tricked into having their browser do something on their behalf. But this implies the user is logged in and has an active authentication session. In our case, this is a public page, and there is no logged-in user.

So do we even need CSRF? I started to make the argument that we didn't need it. In fact, I argued we could go a step further and make it a GET request and bypass the issue altogether.

But Aaron and I talked it through, and decided to leave things as they were. Why? For a few reasons:

1. The 419 problem wasn't really that big of an issue. How many times will it come up in a month? One, maybe?
2. Because we are creating a Stripe session resource as part of checkout, it felt wrong to change this to a GET request. POST requests are the standard for resource creation, even if it's not a resource in our application.
3. Just because we couldn't think of an immediate downside to removing CSRF protection on the POST route, it just felt wrong. We follow standards and patterns for a reason, especially around security.

So putting all that together, we decided it made no sense to deviate from our normal standards to solve a problem that wasn't really a major issue in the first place.

I love conversations like this. Talking through a scenario is useful, even if the end result is to make no change.

Here to help,

Joel

P.S. Do you have a reliable solution for dealing with CSRF timeouts on long-lived pages? I'd love to hear it.