The Spring docs state:
Our recommendation is to use CSRF protection for any request that could be processed by a browser by normal users. If you are only creating a service that is used by non-browser clients, you will likely want to disable CSRF protection.
I'm interested in why? Why is it OK to disable CSRF protection when building a service whose only clients are non-browsers, but it should be enabled when the service talks to browser clients?
It comes down to the fact that CSRF is an attack against browsers, so if your service is exclusively used by non-browsers there's no point in using anti-CSRF defences, which can be expensive so may be worth disabling.
When a browser interacts with a server, each request comes in separately, so if the service wants to have authentication it needs to add in some scheme to connect requests (to avoid having to have the user authenticate every request). One common way is to set a cookie to the user's browser, which is automatically send when every subsequent request by the browser).
vs. with protection
However malicious scripts can make requests to the server, and the browser will helpfully included the cookie. However the script won't have access to the cookie directly (assuming the right cookie option is specified). Therefore a protection against CSRF is to have something in the request separate from the cookie (i.e. a hidden field on a form) that can be verify the request came from a proper form, rather than a script.
CSRF relies on the browser sending the cookie with a cross-site request automatically, since Javascript/attacker's site don't have access to the cookie.
CSRF protection relies on the server correlating something the browser sends automatically (the cookie) with something in the form (the token).
A non-browser client will be in control of both the token and the cookie so can make them match (if it can get the cookie at all). So there's no point having complicated CSRF protection if the service is never going to be accessed by a browser.
TL/DR - CSRF is inherently a browser attack, so protections against it are only required for services that might be accessed by a browser.
Because the threat model is different.
In a browser context, we have an expectation that the browser user should be able to navigate to arbitrary web pages without worrying about it making unauthorised actions on the user’s behalf. This is despite the fact that webpages may initiate fetch requests to arbitrary external resources, using the user’s pre-existing authorisation token (i.e. cookies), and have certain limited control over the parameters of such requests, though they generally are not able to see the contents of the response. CSRF protection is meant to guard against this kind of threat, where the attacker may initiate more-or-less arbitrary requests on someone’s behalf, but cannot generally see the responses.
In an analogous situation outside the browser, the threat model is different. Native applications can open arbitrary socket connections to arbitrary hosts, have total control over initiated requests, and can always see the full response from the server. The answer to the analogous problem of ‘what if I run an application that may initiate unauthorised requests on my behalf?’ becomes the punchline of the well-known doctor joke (‘well, don’t do that’). As Raymond Chen likes to put it, you are already on the other side of the airtight hatchway. Any CSRF protection scheme can be trivially bypassed by a native application; it would only amount to security theatre.
That said, pay attention to how the advice about CSRF protection you quoted is worded: it only suggests you may want to disable it if your endpoint can never be used in a browser context. As long as a web browser can initiate authorised requests to it at all (whether you intended it for such use or not), CSRF protection may offer some value, even if native applications can bypass it easily.