@eagle_arg that's kinda the point.

Let's say in Chrome, you logged into a Todo App which has a button that allows you to create a todo item. This button would make a POST request with the todo description to the /todos endpoint and create a todo in your account.

Now, assuming there is no CSRF protection on the Todo App:

If you then, in Chrome, visited my malicious website, I could have a form with a button that says Click Here If You Like Cake which makes a POST request to the Todo App's /todos endpoint and it would use your credentials to create a new todo item in your account. Now imagine what other damage pressing a button on my site could do to your to-dos. Renew your subscription perhaps? Basically, we are trying to prevent a third party site from hijacking the fact that you are logged into the same browser and sending requests on your behalf.

So with CSRF, the Todo App verifies that the request came from a page within the app, or rather, from a form that somehow knows the value of the csrf token which is in the session, which my malicious site does not have access to. My malicious website can't read your session nor the contents of your current page so can't spoof the token and hence can't beat the protection.

CSRF Attacks, With Examples

Updated Series Available