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

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;

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.

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

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

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?

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.

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

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

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

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

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

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.

​@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>

    

brilliant thanks ​@rylanatsafe