What are the downsides to disabling CSRF tokens?

You can manually create your own if you do not trust the built-in. But I would have them one way or the other for security reasons.

You could create a middleware that you apply on all post routes, that checks HTTP_REFERER but you should know that..

'HTTP_REFERER The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.

source

Suggested reading https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Another good read on this http://shiflett.org/articles/cross-site-request-forgeries

Whilst we are on the subject, Troy Hunt lectures on web security and his site is worth bookmarking. Here he has a 25 minute video on CSRF attacks. https://www.troyhunt.com/understanding-csrf-video-tutorial/

@Snapey good video I think part of the problem people who use a framework only like laravel with this stuff built in has never had to code it themselves therefore they don't get the full understanding of what they are protecting. I just wonder how many folks don't understand how to properly sanitize data input and I don't mean validate I mean sanitize. I use the technique from shiflet in one smaller framework that I use.

@jlrdw we are yet to see any significant Laravel compromise so are all perhaps a little complacent. Rails has had bad ones in the past (http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/) and I've been expecting similar to affect our favourite at some point, but nothing so far (touches wood). The fact that Taylor (and the Symfony community) draws on experiences with .NET and what happens in other frameworks helps a lot. If you develop common good practice (like csrf) then your framework does not fall into the same traps as befell your predecessors.

I see the original poster hasn't replied I just hope they have read over this and realize to implement this security. Weather laravel or their own.

I haven't replied since I have nothing to add to the conversation. Doesn't mean I wasn't reading/monitoring it. I have read and seen all the useful information provided. I've decided that to shelve the errors and come back to it before I push to production. I've kept all the code within my VerifyCsrfToken.tokensMatch the same but just did return true; //hash_equals($sessionToken, $token); to bypass the errors produced by sessions. I haven't removed the full functionality of Verifying the token nor did I plan to remove it fully. I just wanted some information on the subject. Only because I've wasted 3 days on this issue of getting a token missmatch error 25% of the time. I mean its only annoying because it happens sporadically and stopped me progressing.

@Alig96 I don't know what version you are using but I have seen a lot more problems in version 5.2, I would seriously consider using version 5.1 it seems to be more stable. And you do know there's a new kid on the Block http://novaframework.com/php-framework heavily similar to laravel 4.2 but yet PHP 5.5 through 7 compatible. Myself I don't use a lot of the build in things I'm just used of codeing my own way I even like coding my own authorization and roles I came from java and just used to writing my own stuff.

The references that were given in this post I would highly advise reading over those references modern applications definitely need security.