Create a TC Note in order "Securing Open Data" to address security issues and add this to that note. The client adds the header X-CSRF-Token: Fetch to a GET request. The header value "Fetch" is case-insensitive. The server adds the same header to the response. The header value is generated by the server. It is opaque, i.e. the client has to copy it verbatim without alteration. As a consequence it is case-sensitive. The client adds this header with the copied, unaltered value to subsequent POST, PUT, PATCH, or DELETE requests. The server accepts the modifying request if and only if the provided CSRF token is still valid. If the token is invalid, the server responds with 403 Forbidden and includes the response header X-CSRF-Token: Required If a server requires a CSRF token for modifying requests, it MUST issue a CSRF token in responses to GET requests to the service document as this is the only well-known and small resource of a service. To guarantee freshness of the CSRF token the server MUST include cache control headers that advise intermediaries and clients to refresh their caches. The refresh period or point in time MUST be chosen to guarantee that the caches are refreshed before the CSRF token expires. The service SHOULD issue a CSRF token in responses to GET requests to other resources whose cache residence period is sufficiently shorter than the CSRF token validity period. The client MUST NOT assume to get a CSRF token in responses to GET requests to the metadata document, as this is typically not small and SHOULD be cached anyway, so there's no guarantee to get a fresh CSRF token. For $Batch the X-CSRF-Token MUST be provided as a header. It's not allowed to specifiy any X-CSRF-Token in the "inner" requests. Accepted: https://www.oasis-open.org/committees/download.php/49447/odata-meeting-40_on-20130606-minutes.html#odata-262