Application Development and Automation Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

Understand CSRF handling in SAP Build Apps

Aparna_N
Product and Topic Expert
Product and Topic Expert
‎2024 Jul 29 9:38 AM
3,021

What is CSRF?

CSRF stands for Cross-Site Request Forgery. It is a type of malicious attack that tricks the victim into submitting a malicious request. It uses the identity and privileges of the victim to perform an undesired function on their behalf. For instance, this could involve changing an email address or password, or making a purchase. The attack can cause damage even if the exploited action is normally harmless because it's performed without the user's consent or knowledge.

What is the defense mechanism?

CSRF token is a security measure used in web applications to protect against CSRF attacks.

It is a unique, random value associated with a user's session and is typically embedded within a form or URL to ensure that the user is intentionally submitting the request. This token is checked by the server to verify the source of the request, preventing malicious parties from tricking a user's browser into making a request on their behalf.

This is usually taken care of by the browser from where the app is launched and accesses APIs.

CSRF tokens are mainly used for communication with the server. Before an app is allowed to execute a modify operation through an HTTP request such as POST, PUT, DELETE etc., a CSRF token is generated by the server to ensure the security of the operation.

Here is a brief process of how it is used:

  1. First, the app sends a GET request to fetch a CSRF token from the server.
  2. During the GET request, the server generates a new CSRF token and sends it back in the response headers (usually under "x-csrf-token").
  3. The app then uses this token in the header of every modification request.
  4. The server validates the CSRF token in every modifying request. If it's valid, the operation proceeds.
  5. If it's not valid or missing, the server returns a 403 (Forbidden) status, and the operation does not proceed.

In this way, the CSRF token ensures that every operation modifying data is secure, authenticated, and originated from a trusted source. It protects against CSRF attacks where an attacker might trick a victim into executing actions of the attacker's choosing.

Why do we need additional CSRF handling for SAP Build Apps?

To ensure application security, it is essential to understand and manage CSRF token use effectively, as it is crucial in preventing unwanted actions from being performed.

In SAP Build Apps because of the current architecture, extra CSRF token handling is required sometimes for end-user deployed apps with a back-end connection accessing an API indirectly (via a destination such as S/4 HANA) wherein the request to the API goes through via managed app-router.

To be more precise, all installed destinations are CSRF protected by managed app-router, by default. However, if a backend behind a destination has its own CSRF protection, you need to tell SAP Build Apps to switch off managed app-router’s CSRF protection for that specific destination.

This is because when your app is fetching the CSRF token, it will end up getting the CSRF token from managed app-router and then it will send it to backend and fail because the backend doesn’t recognize that token.

Aparna_N_0-1721830665044.png

What is the consequence of not handling the CSRF in SAP Build Apps?

In this case the symptom would be that the deployed build apps fail with a 403 (forbidden) error as illustrated in one example below.

Aparna_N_1-1721830665047.png

Disclaimer: As of today it is not possible to show this failure early in the Preview mode as the request handling here (and in the design time) is done via destination-proxy. So in general, no additional CSRF handling is required for design-time and preview mode.

How to overcome this issue?

To overcome this issue, we need to extend your destination (only for some backends which has it's own CSRF protection (such as S/4 Hana backends)) with the tag below to tell the Build Apps to switch off the managed app-router’s CSRF protection for that specific destination.

 

BuildApps.RequiresCsrf = true

 

This way, when your app is fetching the CSRF token, managed app-router won’t interfere and you will get the CSRF token from backend and then when you send it to backend it will work (because the backend will recognize that token).

NOTE: If the SAP Build apps is already built and deployed then we need to also rebuild and redeploy the application for this change in the destination to take effect.

Additional Reading

Refer to the SAP Systems | SAP Help Portal under the 'Adding Data Endpoints' section.

2 Comments