Consider an end point such as below. Let's imagine that this endpoint updates an address of the signed in user, changing the zip code. The address to update is identified by the address ID (
Importantly, the identifier is an alphanumeric string, not an incremental integer. If it was an incremental integer, then it feasibly could be predicted. The alphanumeric can't reasonably be predicted or guessed.
To clarify, in the example, the address ID was randomaly generated, but once it exists, it never changes. The ID is not based on any specific user or address data.
Also, an address update is just one example, it doesn't really matter what the request actually does. It could be updating a phone number, or removing an email address. The key is that this alphanumeric is used to identify the entity and that no CSRF token is present.
Argument for considering it a CSRF
A CRSF token only lives and remains valid for the current session (or possibly even shorter). The unique ID in question remains the same (probably forever). Therefore a CSRF token should be used. It's possible that the identifier could be used elsewhere in the app, and made available for another user to see.
Argument for not considering it a CSRF
The attacker is unlikely to ever obtain the unique ID. It could be close to being as difficult to obtaining an actual CSRF token itself.
OWASP defines a CSRF as:
Any application that accepts HTTP requests from an authenticated user without having some control to verify that the HTTP request is unique to the user's session.
I think the above example satisfies the OWASP definition, because the address ID is not unique to the user's session.