Skip to Content
Technical Articles
Author's profile photo Akos Grabecz

How does CSRF token work? SAP Gateway

Update 2021-06-25: making the diagrams more precise & explicitly writing that the CSRF token is for one user session.

Update 2021-09-28: explaining cookies in more detail.


“Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.” OWASP Cross Site Request Forgery (CSRF)

Issues come really often about CSRF token validations where developers receive errors like:

403 Forbidden CSRF Token required

403 Forbidden CSRF Token expired

The aim of this Blog is to explain how CSRF token protection works in SAP Gateway and how should developers implement it.

The ideal flow is like the following:

  1. The client application sends a GET request with header X-CSRF-TOKEN: Fetch (this is usually sent in the $metadata or in a simple service document request).GET%20Service%20DocumentX-CSRF-TOKEN%3A%20FETCH
  2. The server then responds with 200 OK and response header: X-CSRF-TOKEN: <tokenValue> and one or more Set-Cookie headers (not highlighted below)Response%20-%20X-CSRF-TOKEN%3A%20tokenValue
  3. The client has to store this token and all the cookies in the Set-Cookie response header (the cookie here identifies the HTTP session) and send in every modification request* throughout its session. When the session renews the CSRF token has to be renewed as well, by requesting a token again.
    *A modification request, is a non-GET request like POST, PUT, PATCH, MERGE, DELETE (CUD). Note, that $batch requests are always sent with POST method.Request%20headersX-CSRF-TOKEN%3A%20tokenValue
  4. The server will check this token and the session ID cookie(s) and if they’re valid and matching, it’ll process the request. If at least one of them is invalid or expired then the server will respond with 403 Forbidden, with response header: X-CSRF-TOKEN: Required, with response body: “CSRF Token required”
  5. The client has to automatically send a new GET request with X-CSRF-TOKEN: Fetch and retrieve the new token from the response header.

So the successful scenario would look like this (Set-Cookie + Cookie isn’t present in the diagram):

CSRF Token – Successful

And the scenario where it fails once and the client has to re-request the CSRF token would look like this (Set-Cookie + Cookie isn’t present in the diagram):

CSRF Token – Failure

Assigned tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Christian Tapia
      Christian Tapia

      Thanks for the blog Akos.

      I understand that the "session" between the fetch request and the modification request has to be the same. In other words, cookies has to be shared. Is this right?

      Best regards.

      Author's profile photo Akos Grabecz
      Akos Grabecz
      Blog Post Author

      Hi Christian,

      With regards to the CSRF token itself only, it doesn't matter how you work with the cookies. When the Gateway checks the CSRF token, it checks only that and nothing else. So it won't check for a session ID or anything like that. But if your question is about the "share-ability" of a CSRF token between different users, then the answer is that a user must send the token that it received. If the user is sending the token of another user then it'll fail.

      Hope this answers your question.

      Best regards,
      Ákos

      Author's profile photo Akos Grabecz
      Akos Grabecz
      Blog Post Author

      Christian Tapia I've just updated my reply to be more precise. Let me know if you have any further questions.

      Author's profile photo Wayne Smith
      Wayne Smith

      The CSRF Token has to be requested and fetch on the fist call to the Gateway Server
      then on every call there after the CSRF Token has to be sent back on every Call when doing
      any PUT calls as an example. The CSRF Token in general is in and is part of the Cookie
      and part of the HEADER. thou there are other ways to present the Cookie see the Link below

      If there is any changes to the Connection it will fail
      If the CSRF Token is not in the Cookie it will fail
      If the Connection is closed and reopened it will fail

      One Area you have to be careful with is redirecting the URL this can also cause
      the CSRF Token to be invalidated

      You can trace this calls in SAP Gateway Server via t-code SMICM and see the error messages

      CSRF Tokens are session based once the connection is closed or the user disconnect

                a new request for the CSRF Token has to be done again

       

      There are different methods of handling the CSRF Token

      For this I would recommend taking a look at the following

      SAP Help Web Page on how to

      Using the CSRF Token - SAP Help Portal

      Great Write up Akos thank you for creating this very helpful

       

       

       

      Author's profile photo Pavan Golesar
      Pavan Golesar

      Wow, Thanks for good post, I came across recently to this good post on same lines:

      https://www.youtube.com/watch?v=a4xM5PbVNv0

       

       

      Author's profile photo Wayne Smith
      Wayne Smith

      One other note, if you do a GET request you will not see the CSRF Token.

      Get request do not trigger the generation request for a CSRF Token as it is a Read only request.

      If you do any other request PUT, DELETE and so on then you will get the CSRF Token.