Skip to main content
Question

Embedding Flow apps

  • August 28, 2025
  • 18 replies
  • 509 views

jeresv
Contributor
Forum|alt.badge.img+10

Apparently since fixing this problem 

https://support.safe.com/hc/en-us/articles/25407612007949-Known-Issue-FME-Flow-Apache-Tomcat-Vulnerability-with-X-Frame-Options-header

In FME Flow 2025.1, embedding FME Flow content to other pages is disabled entirely by default. 
 

Is there any chance to allow embedding from known sources or is embedding considered so risky that this would not be even considered? 

18 replies

mgg_beca
Enthusiast
Forum|alt.badge.img+20
  • Enthusiast
  • September 18, 2025

Hi, we also need an answer to this as we have just upgraded and found that our embedded apps are no longer working.

Thanks,

Marc


todd_davis
Influencer
Forum|alt.badge.img+23
  • Influencer
  • September 22, 2025

Originally, I thought you could use ALLOW-FROM (and antiClickJackingUri), rather than DENY in the web.xml for fmeserver, however I soon noted that ALLOW-FROM is no longer supported by browsers and therefore you would be allow for any source.

<init-param>
      <param-name>antiClickJackingOption</param-name>
      <param-value>DENY</param-value> <!-- Prevents the page from being embedded in an iframe on any domain -->
    </init-param>

 

It appears that frame-ancestors as part of the Content-Security-Policy is the way to go. But I have tried to add a custom response header to tomcat, but have not been able to get it to work. Would be interested if anybody knows how to do that from an FME Flow tomcat perspective?

Content-Security-Policy: frame-ancestors 'self' https://www.example.org;

hkingsbury
Celebrity
Forum|alt.badge.img+73
  • Celebrity
  • September 30, 2025

I’ve mostly figured it out.

 

As ​@todd_davis alluded to, you’re working in this file:

Utilities\tomcat\webapps\fmeserver\WEB-INF\web.xml


You can fully disabled the block by setting ‘antiClickJackingEnabled’ to ‘false’

You can disable the block for the same domain by leavting ‘antiClickJackingEnabled’ as ‘true’ and setting ‘antiClickJackingOption’ to ‘SAMEORIGIN’ 

 

Where it gets tricky…...

If you want to allow *.example.com, you need to build a custom filter and compile that through to a .jar file and place it in:

Utilities\tomcat\webapps\fmeserver\WEB-INF\lib

 

Depending exactly how that’s built, you then need to add a new filter to web.xml that calls the new module you added.


jeresv
Contributor
Forum|alt.badge.img+10
  • Author
  • Contributor
  • September 30, 2025

I’ve mostly figured it out.

 

As ​@todd_davis alluded to, you’re working in this file:

Utilities\tomcat\webapps\fmeserver\WEB-INF\web.xml


You can fully disabled the block by setting ‘antiClickJackingEnabled’ to ‘false’

You can disable the block for the same domain by leavting ‘antiClickJackingEnabled’ as ‘true’ and setting ‘antiClickJackingOption’ to ‘SAMEORIGIN’ 

 

Where it gets tricky…...

If you want to allow *.example.com, you need to build a custom filter and compile that through to a .jar file and place it in:

Utilities\tomcat\webapps\fmeserver\WEB-INF\lib

 

Depending exactly how that’s built, you then need to add a new filter to web.xml that calls the new module you added.

Yeah this seems to be the only way now. But seems rather hard and overhead and requires custom actions and extra coding to achieve it. And, I don’t know if this is counted as modifying the software, thus violating the license terms. 

Edit: I mean adding the custom filter as .jar, would it be counted as modifying the software?


mgg_beca
Enthusiast
Forum|alt.badge.img+20
  • Enthusiast
  • September 30, 2025

This seems risky. It would be good if someone from Safe could chime in if this is a supported approach, and if there are any alternative way to do this.  Surely embedding apps is a common approach to integrating FME Flow into other systems, this is quite a breaking change.


hkingsbury
Celebrity
Forum|alt.badge.img+73
  • Celebrity
  • September 30, 2025

This seems risky. It would be good if someone from Safe could chime in if this is a supported approach, and if there are any alternative way to do this.  Surely embedding apps is a common approach to integrating FME Flow into other systems, this is quite a breaking change.

 

I’ve mostly figured it out.

 

As ​@todd_davis alluded to, you’re working in this file:

Utilities\tomcat\webapps\fmeserver\WEB-INF\web.xml


You can fully disabled the block by setting ‘antiClickJackingEnabled’ to ‘false’

You can disable the block for the same domain by leavting ‘antiClickJackingEnabled’ as ‘true’ and setting ‘antiClickJackingOption’ to ‘SAMEORIGIN’ 

 

Where it gets tricky…...

If you want to allow *.example.com, you need to build a custom filter and compile that through to a .jar file and place it in:

Utilities\tomcat\webapps\fmeserver\WEB-INF\lib

 

Depending exactly how that’s built, you then need to add a new filter to web.xml that calls the new module you added.

Yeah this seems to be the only way now. But seems rather hard and overhead and requires custom actions and extra coding to achieve it. And, I don’t know if this is counted as modifying the software, thus violating the license terms. 

Edit: I mean adding the custom filter as .jar, would it be counted as modifying the software?

 

Yea, I’ve deliberately left my response vague as I don’t want to lead anyone down the path of thinking that approach is the offical way


rylanatsafe
Safer
Forum|alt.badge.img+14
  • Safer
  • October 1, 2025

Hi all, thank you for your input and the troubleshooting shared in this thread.

To start, I want to acknowledge that in addressing the X-Frame-Options header vulnerability, we made the decision to disable iframe embedding entirely by default. In hindsight, we recognize this approach was too heavy-handed and underestimated how many of you rely on embedding Flow Apps as part of broader integrations. We’re sorry for the disruption and confusion this caused.

We have reverted this change in FME Flow 2025.1.2 for the time being.

The good news is that we are now investigating a more flexible solution—one that will allow embedding from approved origins while continuing to protect against clickjacking attacks. This will help eliminate the need for workarounds (and ensure Flow Hosted customers can also benefit).

In the meantime, while we understand the community’s creativity in exploring workarounds, such as editing web.xml or injecting custom .jar filters to modify the Content-Security-Policy, we can’t formally support or recommend code-level changes to the application. These modifications carry potential security risks and may affect your ability to receive support, even if they don’t explicitly violate license terms.


hkingsbury
Celebrity
Forum|alt.badge.img+73
  • Celebrity
  • October 2, 2025

Hi all, thank you for your input and the troubleshooting shared in this thread.

To start, I want to acknowledge that in addressing the X-Frame-Options header vulnerability, we made the decision to disable iframe embedding entirely by default. In hindsight, we recognize this approach was too heavy-handed and underestimated how many of you rely on embedding Flow Apps as part of broader integrations. We’re sorry for the disruption and confusion this caused.

We have reverted this change in FME Flow 2025.1.2 for the time being.

The good news is that we are now investigating a more flexible solution—one that will allow embedding from approved origins while continuing to protect against clickjacking attacks. This will help eliminate the need for workarounds (and ensure Flow Hosted customers can also benefit).

In the meantime, while we understand the community’s creativity in exploring workarounds, such as editing web.xml or injecting custom .jar filters to modify the Content-Security-Policy, we can’t formally support or recommend code-level changes to the application. These modifications carry potential security risks and may affect your ability to receive support, even if they don’t explicitly violate license terms.



Thanks for the prompt response on this ​@rylanatsafe! I also appreciate the willingness to revert the change in subsequent versions.

 

Just confirming, that through the reversion of this change, the known issue (FMESERVER-10761) has been reintroduced to 2025.1.2?

I assume the associated article is still to be updated:
https://support.safe.com/hc/en-us/articles/25407612007949-Known-Issue-FME-Flow-Apache-Tomcat-Vulnerability-with-X-Frame-Options-header


rylanatsafe
Safer
Forum|alt.badge.img+14
  • Safer
  • October 2, 2025

Just confirming, that through the reversion of this change, the known issue (FMESERVER-10761) has been reintroduced to 2025.1.2?

I assume the associated article is still to be updated:
https://support.safe.com/hc/en-us/articles/25407612007949-Known-Issue-FME-Flow-Apache-Tomcat-Vulnerability-with-X-Frame-Options-header

Yes, that is correct—the issue is effectively reintroduced. The article should be updated soon to clarify.


mgg_beca
Enthusiast
Forum|alt.badge.img+20
  • Enthusiast
  • October 6, 2025

Hi ​@rylanatsafe 

Thanks for the update.  Can you give us a rough timeframe for the improved interface?  If it will be soon I will wait to upgrade, if it is going to be 6 months - a year away then we will need to upgrade to 2025.1.2 sooner.


rylanatsafe
Safer
Forum|alt.badge.img+14
  • Safer
  • October 8, 2025

@mgg_beca the timeline is likely within the 6–12 month timeframe, as we’re currently wrapping up feature work for the 2025.2 release.

If you are already running a Flow deployment of 2025.1.0 or 2025.1.1, and have access to the install directories or filesystem, then you can follow this instruction to avoid needing to perform a full upgrade:

  1. Open the web.xml file located at:
     <install>/Resources/Utilities/tomcat/webapps/fmeserver/WEB-INF/
  2. Find and update the following parameter:
    <init-param>
    <param-name>antiClickJackingEnabled</param-name>
    <param-value>true</param-value>
    </init-param>
    to
    <init-param>
    <param-name>antiClickJackingEnabled</param-name>
    <param-value>false</param-value>
    </init-param>

     


mgg_beca
Enthusiast
Forum|alt.badge.img+20
  • Enthusiast
  • October 8, 2025

brilliant thanks ​@rylanatsafe 


braggken
Supporter
Forum|alt.badge.img+9
  • Supporter
  • January 15, 2026

Using ​@rylanatsafe ‘s web.xml change we can now embed apps again but if users run Workspace Apps using the datastreaming service the result is not returned to the user.

Anyone or ​@rylanatsafe  have a work-around for this?

Thanks


rylanatsafe
Safer
Forum|alt.badge.img+14
  • Safer
  • January 15, 2026

Using ​@rylanatsafe ‘s web.xml change we can now embed apps again but if users run Workspace Apps using the datastreaming service the result is not returned to the user.

Anyone or ​@rylanatsafe  have a work-around for this?

Thanks

Hi ​@braggken , would you be able to open a support ticket for this so we can look into it further? That’s definitely unexpected behaviour, and I’m sorry you’ve run into this.


yesmankzzzzz
Contributor
Forum|alt.badge.img
  • Contributor
  • September 9, 2026

Hi all, thank you for your input and the troubleshooting shared in this thread.

To start, I want to acknowledge that in addressing the X-Frame-Options header vulnerability, we made the decision to disable iframe embedding entirely by default. In hindsight, we recognize this approach was too heavy-handed and underestimated how many of you rely on embedding Flow Apps as part of broader integrations. We’re sorry for the disruption and confusion this caused.

We have reverted this change in FME Flow 2025.1.2 for the time being.

The good news is that we are now investigating a more flexible solution—one that will allow embedding from approved origins while continuing to protect against clickjacking attacks. This will help eliminate the need for workarounds (and ensure Flow Hosted customers can also benefit).

In the meantime, while we understand the community’s creativity in exploring workarounds, such as editing web.xml or injecting custom .jar filters to modify the Content-Security-Policy, we can’t formally support or recommend code-level changes to the application. These modifications carry potential security risks and may affect your ability to receive support, even if they don’t explicitly violate license terms.

Hi. I’m trying to integrate FME App in Model-driven app (Power Apps) using iframe and I’m facing the same restrictions:
- I can’t load and work with FME app within iframe on the Model-driven app form, only login form is visible. Authorization by login and pass in the iframe occurs infinite logging dialog.
- FME app works only in the separate browser tab.
- SSO logging within the iframe is not working: “login.microsoftonline.com refused to connect.”.


todd_davis
Influencer
Forum|alt.badge.img+23
  • Influencer
  • September 9, 2026

@yesmankzzzzz SSO login via Microsoft won’t work. Microsoft block logins in iframes because of the security risk presented. So that is not tied to FME Apps in itself.

If you need SSO you need to move away from iframe.

 


yesmankzzzzz
Contributor
Forum|alt.badge.img
  • Contributor
  • September 10, 2026

@yesmankzzzzz SSO login via Microsoft won’t work. Microsoft block logins in iframes because of the security risk presented. So that is not tied to FME Apps in itself.

If you need SSO you need to move away from iframe.

 

Yeah, embedded SSO login is restricted, but for a Power BI report embedded within an iframe, we have a popup login dialog and it is working (after logging in via the popup dialog, the Power BI report is shown in the iframe container). Maybe the Safe vendor has the same or is looking for a similar solution?


rylanatsafe
Safer
Forum|alt.badge.img+14
  • Safer
  • September 15, 2026

I see that eleven months ago I estimated this was 6–12 months out; the reality is it hasn't been built and has since been deprioritized relative to other work. It's still in our backlog, but not scheduled and I don't have a date.

So if this matters to you, tell me—preference for direct message, but you could also share here. Your input helps make the strongest case.

  • What you're embedding Flow Apps into (Power Apps, SharePoint, an internal portal, a GIS viewer, a customer-facing site)
  • Whether you need SSO inside the embed, or username/password is enough
  • Whether you're on Flow Hosted, where the web.xml workaround isn't available at all
  • What you're doing today—using the workaround, holding on an older version, or gave up on the embed