XSRF that requires the knowledge of a secret

Most of the server callbacks that perform state-changing actions are protected with an explicit XSRF token or a dedicated header set via the XMLHttpRequest API. But in situations where such a defense is not obviously present, it is always important to make sure that the remaining parameters required to make a successful request could be realistically guessed by the attacker.

When you see a long, opaque blob of encoded data anywhere in the request, or if it's 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 XSRF token, even if it is not named this way.

The behavior is a common cause of false-positive reports by some automated vulnerability scanners. When submitting a report about an XSRF vulnerability, be sure to double-check for that!