Cross-Site Request Forgery (CSRF) is when commands, usually in the form of HTTP GET or POST requests, are transmitted from a user without their intent, by malicious code. A primitive example would be if a banking website at bank.example.com had an API endpoint that allowed logged-in users to transfer a given amount to a specified account number. The endpoint might be as follows:
POST bank.example.com/transfer?amount=5000&account=12345678
Even if users were authenticated via a session cookie on the bank.example.com domain, a malicious website could easily embed and submit <form> directing the transfer to their own account, like so:
<form
method="post"
action="//bank.example.com/transfer?amount=5000&account=12345678">
</form>
<script>
document.forms[0].submit();
</script>
Regardless of what HTTP method is used by the endpoint or what kind of request body or parameters it accepts, it is liable to a CSRF attack unless it ensures that the request comes from its own website. This problem is partially solved by the same-origin policy inherent to browsers, which prevents some types of requests from taking place (such as a JSON POST request via XHR or PUT/DELETE requests), but there is nothing inherent in the browser to prevent a user innocently clicking a link to a website or submitting a form that forges a malicious POST request. These actions are, after all, the entire purpose of the browser.
Since there is no inherent mechanism of the web that prevents CSRF, developers have come up with their own defenses. One common mechanism to prevent CSRF is with a CSRF token (which should really be called an Anti-CSRF Token). This is a generated key (random, long, and impossible to guess) that is sent down to the client with each regular request while also being stored on the server as part of the user's session data. The server will then require the browser to send that key along with any subsequent HTTP requests to verify the source of each request. So, instead of just two parameters, our /transfer endpoint will now have a third, the token:
POST bank.example.com/transfer?
amount=5000&
account=12345678&
token=d55lv90s88x9mk...
The server can then verify that the provided token exists on that user's session data. There are many libraries and frameworks that simplify this. There are also a variety of adaptations and configurations of this basic token mechanism. Some of them will only generate a token for a given amount of time, or a given request cycle, whereas others will provide a singular token for that user's entire session. There are also a variety of ways for the token to be sent downstream to the client. The most common is within the response payload as part of the document markup, usually in the form of a <meta> element in <head>:
<head>
<!-- ... -->
<meta name="anti-csrf-token" content="JWhpLxPSQSoTLDXm..." />
</head>
This can then be grabbed by JavaScript and sent with any subsequent GET or POST requests made dynamically by the JavaScript. Or in the case of a conventional website without client-side rendering, the CSRF token can be sent downstream directly embedded in the <form> markup as a hidden <input>, which naturally forms part of the form's eventual submission to the server:
<form>
<input
type="hidden"
name="anti-csrf-token"
value="JWhpLxPSQSoTLDXm..." />
<!-- Regular input fields here -->
<input type="submit" value="Submit" />
</form>
Whatever anti-CSRF measure you use, the crucial need is for every request that mutates a user's data or carries out a command to be verified as coming from a legitimate page within the web application itself and not some maliciously crafted external source. To get a more thorough understanding of CSRF and the available countermeasures, I recommend reading and fully digesting OWASP's CSRF Prevention Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html.