Occasional TokenMismatch error - Is that normal?

@ralphmorris I get them every once in a while from my apps that contain auth. I use BugSnag and from there I can see who the user is, what device, browser. I figured out real quick that the same folks would have it happen. It turns out that they have some type of cookie/session cleaning app running for privacy. That is about all I know for this occasional issue. Another is with Guzzle, sometimes it fails and throws an error but the person completes the request directly afterward.

Just double check that you have your forms set up correctly with the token and that if using AJAX, you send it as a header or put a meta tag in the document head. Oh, yea, Opera mobile causes more than a few of those two errors.

It can happen quite easily if the user goes away for a couple of hours whilst leaving your site 'open' on a form

They come back and fill in the form and you get a token mismatch because their session has expired

You can look at the logs and decide if that is a page that they might leave open. One thing I do is disable csrf on login forms because it is not doing any good there.

Thanks guys for your responses. Congrats @Snapey on the 1000 best answers!

@ejdelmonico - Just to double check. My forms all contain the _token hidden input and all I'm doing is serialising the form with something like:

        $.ajax({
            type: "POST",
            url: $('form').attr('action'),
            data: $('form').serialize(),

So the token is inside with the form data.

In parts where I am sending an ajax request without the use of a form I use

        $.ajaxSetup({
            headers: {
                'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
            }
        });

@Snapey - would you mind expanding on why the CSRF isn't needed on the login form? One of the forms is located on the homepage so it's very possible that the user has left and come back later. The other is the login page so this would be possible also. The third is a logged in profile page where they can add/update bits of info.

Thanks!

The point about a cross site request forgery is getting a user to action something when then gets posted back to a site they are currently authenticated with.

With a login form there is nothing that a bad actor could do indirectly that they could not do directly themselves through the login form.

So to me, if the user is not logged in then the forms they submit or are submitted in their name are not dangerous.

Not sure if I'm explaining it well...

Looking into it a little further, there is something called Login CSRF attack (or session donation), however this does not overly concern me for the types of sites I build.

It might be relevant to you if you have to have your site pen-tested

https://security.stackexchange.com/questions/91264/is-it-secure-not-to-have-csrf-protection-in-login-forms