Skip to Content
Technical Articles
Author's profile photo Vladimír Balko

Disable X-FRAME-OPTIONS in SCP Portal Cloud Foundry

Motivation and problem

During project for customer I developed the standalone Fiori application. Because that project is hosted on SAP SCP multi cloud – in other words on Cloud Foundry platform – I wrapped that Fiori application to multi target application (MTA) as a HTML5 module and added approuter so I can access that application from html repository.

Next step was to add that application to a portal service (also on that same subaccout). I managed to do this pretty easily, but when I launched that app from its tile – nothing happend. Or more accurately – application launched but there was only message that webpage refused connection.

If you would open developer tools on chrome (right click and then Inspect], you will see red message

that the link was refused to display because there is X-Frame-Options set to SAMEORIGIN.

You can find more on that option here but in short – it is security directive in http header, which prevents ClickJacking attack. This is done in a way, that page prevents to be included itself in iFrame of other page.
But in case of portal – this is exactly what we want to do. Portal page opens our application in iFrame. And because application dont want to be included – we see that error.

Options we have

In order to resolve this we have 2 options 4 options:
  1. In portal, you can set, that application will open in new tab instead of inside of portal page
  2. convince app router application to not include that security option into http header. This can be done in SCP cockpit. You need to go to your subaccount and space where you have your application deployed. On the left side in menu Applications find you app router. Click on its name  and this will get you to its configuration. There you have User-Provided Variables. There you have to add new variable named SEND_XFRAMEOPTIONS.
  3. Set iframDomains parameter of tenant.
  4. Set whitelist of secure domains in approuter config xs-app.json

In fact – only option 1 and 2 worked for me. I tried also options 3 and 4 but it doesn`t worked. I suppose that I done something wrong or forgot some setting, but both previous (1 and 2) options worked so I didn`t done any further research. Maybe in a future to sharpen my skill.


Option 1 – open page in new tab

In fact – this is the easiest and quickiest solution and works smoothly. This option works, because when you open that page in a new tab (outside of portal site) it is not in iFrame. It needs not to be, because it shows itself outside of portal. But it has also some drawbacks.

You actively navigate user out of your portal site, so this can be a little bit confusing for the user and also navigating is not that comfortable. It is also possible that user will forget to close that tab etc…

Setting for this option is really easy – just set Open in a new tab option in application attributes.

Option 2 – approuter env variable SEND_XFRAMEOPTIONS

This option is little bit complicated to set, but ensures, that page will be shown inside our portal site. When you set that env variable in an approuters config, the approuter won`t set that security directive (X-FRAME-OPTIONS) in an applications http header when served and therefore application will let itself be included in the iframe. I can imagine, that it can be a little bit higher security risk when the directive will be left off, but on the other hand – there are other security measures (e.g. you have to be authorized and authentified to access portal site and application itself). It is good to know that this directive will influence all the applications server by that particular app router. So if you want to serve two applications – one to be included in iframe and one not – it is best to serve them by two app routers.

So how to set that up?

In your space, in the Application page open configuration of your app router. On the tab for User-Provided Variables click Add Variable and fill the name and value

Note: There is value TRUE on a picture, but the right value is false. I grab that picture when I was trying different options how to work that out.

After that you have to restart the app router application so the new variable will take effect. You can do that on Overview page in the left menu.

Then go to the portal, reload page and you should see the application up and running. Sometimes it is necessary also reload whole portal site.

Options 3 and 4

As I wrote that before – I found that options, tried that, but that didn`t work. But I mention it here, because it is probably just me and if that options exists – it is probable, that they works. So if you will manage them to work, please let me know in comments.

Option 3 is in fact substitution for deprecated http header directive X-FRAME-ALLOW. It is describe on a help page for Conversational AI but the functionality is same for the whole cloud foundry. Also this note for C4C can help.

Option 4 is described in SAP Help page for SCP Portal . I set that whitelist service and also added env variable CJ_PROTECT_WHITELIST for domain *, but that did not help.

So finally…

Finally I resolved my problem and that fiori application is able to show inside portal site. In a process I also learned a lot about app router, xsuaa and their configuration.

It would be also great if somebody knows how to implement option 3 and 4 and so much more cool if he or she will share that with us :).


Disclaimer: all pictures used in that blog I took by myself and I apologize to have them in czech language.

Note: This blog post was first posted on my personal blog. Here you can find original version: Disable X-FRAME-OPTIONS in SCP Portal Cloud Foundry.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mio Yasutake
      Mio Yasutake

      Thank you for sharing this.

      I had the same issue and I followed below tutorial.

      Here I created a destination for approuter.

      Your option 2 seems good because you don't have to create a destination.

      Author's profile photo Lutz Rottmann
      Lutz Rottmann

      Vladimír Balko , Mio Yasutake

      please be aware that you are switching off a security feature when implementing solution 2. With switching it off, you increase the risk of clickjacking and comparable web attacks.

      Best regards, Lutz

      Author's profile photo Vladimír Balko
      Vladimír Balko
      Blog Post Author

      Yes, I understand that and I`m also writing it there. I bet that 3 and 4 are much better, because you will choose your safe domains and the rest will be protected, but unfortunately it did not worked for me.

      In fact you are losing just one layer of protection, but still have to consider if it is worth it for your use case.

      Author's profile photo Zhigao Chen
      Zhigao Chen

      I agree option 2 is not a proper way since it disables Clickjacking protection.

      I managed to get CF Portal load an HTML5 application in-line by whitelisting my Portal  {subaccount} Both Portal and the HTML5 application are in the same account.

      What I did was to go to CF SCP cockpit and add the following two User-provided Variables to the app router application of the Html5 application, i.e. make option 4 work.

      CJ_PROTECT_WHITELIST [ { “host”: “{subaccount}” } ]
      httpHeaders [{ “X-Frame-Options”: “ALLOW-FROM https://{subaccount}” }]


      Hope it helps.


      Author's profile photo Vladimír Balko
      Vladimír Balko
      Blog Post Author

      Thank you Zhigao Chen,

      for the comment about how to make whitelist work. I will try that ASAP and respectively update the article if I make it work.

      I agree, that this is much better solution, that ones I found.


      Author's profile photo Nick Yang
      Nick Yang

      Hi Zhigao,


      Your solution works for me.



      Kind regards,


      Author's profile photo Kaustubh Dewoolkar
      Kaustubh Dewoolkar

      Hi Zhigao,

      I have tried adding those variables in the app-router configuration but this does not seem to work for me. The app shows 'Not Found' on the SAP Cloud Portal when accessed.

      For testing I have even tried the SEND_XFRAMEOPTIONS = false option but even this is not working.

      I am using the Trial account for testing purposes. Can you suggest a workaround how this can be resolved?


      Author's profile photo Zhigao Chen
      Zhigao Chen

      Hi Kaustubh, your error seems not related to framing in Portal. I suspect you gave an invalid app URL when configuring your Portal tile.

      Author's profile photo Kaustubh Dewoolkar
      Kaustubh Dewoolkar

      Hi Zhigao,

      I have done the configuration as mentioned in the following blog :

      The only way I got the app to work was to change the "data-sap-ui-frameOptions" setting in the index.html file of the Ui5 app from trusted to allow and add SEND_XFRAMEOPTIONS = false in the approuter config.

      After that adding the app as a Dynamic URL app on the Portal with the url being the approuter url.


      But since this is essentially removing a safety feature from the app I would not like to use this option.


      Author's profile photo Former Member
      Former Member


      Setting httpheader env variable might solve the issue

      cf set-env <approutername> httpHeaders '[{ "Content-Security-Policy": "frame-ancestors '*';"}]'




      Author's profile photo Dinu PAVITHRAN
      Dinu PAVITHRAN

      Making a note here for the benefit of those who reach here looking for a solution:


      A. Option 2


      • ALLOW-FROM (in X-Frame-Options) is only supported in IE [1]
      • Other current browsers (or modern browsers) support [2]  frame-ancestors (in Content-Security-Policy)

      So the following environment variables are needed for approuter for support everywhere. Are your users using IE? 

      { "X-Frame-Options": "ALLOW-FROM https://<host>.<domain>" },
      { "Content-Security-Policy": "frame-ancestors https://<host>.<domain>” }

      Note: This elaborates the suggestion in [3]

      Http headers can be set in xs-app.json [4] with responseHeaders. So you may choose to set the headers in xs-app.json instead of environment variable. But environment variable allows for this to be set from outside the MTA, directly or using an MTA extension. 





      Author's profile photo Dinu PAVITHRAN
      Dinu PAVITHRAN

      B. Option 3 - Setting iframeDomains for XSUAA

      Setting of iframeOptions is described in [5]. This is required when the embedding application needs authentication ("authenticationType":"xsuaa") in route. This allows the authentication page to be embedded in iframe. Without that the page from https://<subdomain>.authentication.<domain>/login will recommend (with X-Frame-Options: DENY; header) to the browser not to allow it to be embedded in iframes.

      Note that this setting has to be enabled for the tenant in case of multitenant applications. You may need to enable cloud foundry to create the xsuaa service instance with apiaccess plan as required to perform this activity today.

      So this is not an option, it is necessary when authentication page need to be embedded as part of the authentication flow. If some other pages are involved in the authentication flow, they need to allow embedding as well.

      [5] SAP Note: 2912358

      C: Option 4 - Enabling whitelistService

      This option in approuter[6] enables allowlist service [7] for use from SAP UI5 . SAP UI5 [8] outlines in a example how this service can be used. Unless enabled by configuration of SAP UI5 in the page, configuring the service is useless.  So if you are preparing your own html page, prepare it with these guidelines.

      In [9] SAP UI5 makes further recommendations for Content-Security-Policy header. Some of these can be set in meta tag in the html page itself.