Most of the server callbacks that perform state-changing actions are protected by an explicit CSRF token or a dedicated header set via the XMLHttpRequest API. However, situations where this type of defense is not obviously present do not necessarily indicate a vulnerability. It is always important to make sure that the remaining parameters required to make a successful request could be realistically guessed by the attacker.

If you see a long, opaque blob of encoded data anywhere in the request, or if the request is accompanied by a seemingly random and non-sequential ID, it's always good to investigate if this value could be disclosed to the attacker in the course of using the service. If not, the secret value may function as a de facto CSRF token, even if it is not named accordingly.

Conclusion

The behavior described above is a common cause of false positive reports returned by some automated vulnerability scanners. When submitting a report about a CSRF vulnerability, be sure to always double-check for false positives of this type first!