UI5 Fiori - Hide or Mask URL for security reasons

[Former Member]

Fellow community members, I have a scenario where the application URL is passed to external vendors in the following format with document number as a URL parameter. We have already created a proxy for the server/port part and it is secured and whitelisted etc. by the networking and security team.

https://PROXY.com#ZAPPLICATION-display?EmailLink=true&DocNo=1234&/HeaderSet/1234

The issue is with the document number (DocNo with value 1234) in URL. It is possible that the external party (Vendor) can manipulate the URL and replace the document number with a different value.

First Question: Is there a way we can avoid this? What are the best practices around this scenario?

I have validated the DocNo in the HEADERSET_GET_ENTITYSET method in the backend oData layer, and am giving an error if the external vendor is not authorized to access the document number. But looks like I am too late in the game because the app is already loaded and I don't know how to throw the user out of backend system. We have a frontend FIORI gateway hub and the backend ECC system is connected to the hub.

Second Question: Any thoughts as to where I should validate and how? I am just reading the URL parameter in HEADERSET_GET_ENTITYSET method. Should I do this in some other way?

Thank you for your guidance.

[Former Member]

Hi Ganesh,

First off, let me preface my response with the assumption that this is a custom application, not a standard SAP application.

There's nothing wrong with having the document number as part of the URL hash. From a developmental and usability perspective, this makes perfect sense. As long as you are validating the document number in the backend, which it sounds like you already are, then I think you should be fine. One thing that I would caution you on is the nature of the error messages returned from the backend. The error message resulting from a lack of authorizations should always be returned before any sort of error message related to a non-existent document number. You want to ensure that an attacker cannot abuse your error handling to enumerate valid document numbers. There's no need to "throw the user out of the backend system" as long as you are doing authorization checks appropriately.

Best Regards,

Hunter Young

[Former Member]

Thank you Hunter for your response, this is a custom application and I am doing authorization checks. It is a Master - Detail layout application. The only problem is that the external Vendor IS authorized to access the application and the authorization check passes. He is only supposed to look at all documents related to his own Vendor ID. But if he manipulates the document number which might be related to another Vendor, we need to stop him. I have a routine to check this but I am not able to go anywhere from the error message because we are in the method and the app shows a strange looking page as we are already in the middle of starting data binding etc. and the Masterlist is already loaded. Any thoughts about how to stop the app after this error and navigating out to the launchpad. Much appreciated!!

[Former Member]

There is nothing that you can (or should) do to the frontend JavaScript code to prevent the vendor from accessing documents related to another vendor - this should all be handled by the routine you mentioned in the backend. However, your routine should return a meaningful error related to authorization failures that can be parsed appropriately by your SAPUI5 app. I would have a callback for the failure condition of the OData binding update to 1) display a dialog or message toast with an error to the end user and then 2) fire a navBack event to return to the Fiori Launchpad homepage upon dismissing the dialog or message toast with the error.

[Former Member]

Thank you Hunter for the guidance. This is working now.