Laravel passes the XSRF token to the client as a cookie. The client can then add the token to requests as the X-XSRF-TOKEN header. Whenever Laravel handles a request that is XSRF-protected, it looks for that header.
Cookies get automatically sent on every request. This is also why the token has to be sent in a header (or a request parameter). If Laravel just checked the cookie, there would be no protection against XSRF attacks.
Laravel can pass the token to the client in other ways too. The cookie method is just convenient for SPAs because some JS libraries automatically look for a cookie named XSRF-TOKEN and add it to the X-XSRF-TOKEN header.
@JussiMannisto thank you for reply. My confusion was caused by not fully understanding csrf attack. I think that I grasp the concept of it now.
Let's consider situation like that:
I'm authenticated to some page e.g. bank.com
I visited some page that have malicious request to bank.com to send money to another account
Because I'm authenticated, during executing malicious request cookie associated with bank.com are added to this request. Yeah?
So to protect against it we need to add X_XSRF-TOKEN from cookie to header. Scripts form page with malicious request doesn't have permission to read cookies connected with page bank.com, so there is not possible by them to add this token to header. This protects us against csrf attack. Are my way of thinking correct?
Note that the CSRF middleware is not used on GET requests. A malicious site may successfully send GET requests, but can't read the response. So it's important that your GET routes are all "safe": they should only return data, not modify the server state.