Do you have an issue with a specific file(s)? No
Can you reproduce using one of our samples or online demos? No
Are you using the WebViewer server? No
Does the issue only happen on certain browsers? No
Is your issue related to a front-end framework? Unsure (I am using Angular)
Is your issue related to annotations? No
I am having an issue where the WebViewer for an Office (DOCX) file never finishes loading.
looking at the network traffic in my browser, the call to "core/officeEditor/OfficeEditorModule.js?externalPath=../external/ never completes.
I am using Angular for my front-end framework.
When I build locally in development mode, there are no issues. However, when I package and deploy to my Azure environment, this behavior occurs.
I am checking to see if it’s something in our Azure environment or if it’s something we are doing wrong with packaging our Angular code in production configuration.
It looks like the resources for the Office workers may not be fetching correctly in your Azure environment. Could you please check the console or any error messages and the network panel and see if the files are failing to retrieve? (i.e. 404)
Also, from the screenshot it looks like you are loading the document in Office Editor mode. If you just need to view the office files, you don’t need the editor. Are you using the office editor?
Could you share your code snippets on how you are loading the document?
I was able to confirm that the issue is Azure related and not caused by Angular development or production configuration modes.
If I attempt to load that same request explicitly in a browser, I get a 403 error response from my Azure Application Gateway. If I remove the externalPath queryString variable, the request is successful.
Looking at my Azure Application Gateway security logs, the Web Application Firewall (WAF) is rejecting the request because it is a suspected “Path Traversal” security vulnerability.
Unfortunately, I do not control the WAF configuration in my deployments, so I won’t be able to make a change to allow this request.
Does this file work as expected without the externalPath queryString value?
Is there any way for me to explicitly tell the WebViewer during initialization where to get the file(s) it needs from, so that the WebViewer won’t include that externalPath queryString value?
Is there any way for me to explicitly tell the WebViewer during initialization where to get the file(s) it needs from
This is generally done via the path variable in WebViewer constructor.
For the externalPath OfficeEditor, it looks like there is a fix already on the way to remove this requirement for local resource. Could you please try out our experimental version of WebViewer (11.11.0) to see if this issue is resolved for you?
See here for instructions on how to try out the nightly build: https://docs.apryse.com/documentation/web/faq/webviewer-nightly-build/
Note that this is an experimental build and should only be used for testing.
I will pull your experimental nightly build.
Just to understand, what is the targeted release date for 11.11.0 ?
And for a change such as this, would this change also be backported into a hotfix for v11.9.X or v11.10.X?
If possible, would the development team consider this a “security” fix? Is there any way that I can request that?
Given that the use of the ?externalPath=../external/ queryString parameter is causing an Azure Application Gateway (AGW) Web Application Firewall (WAF) to reject the request on the basis of a security risk?
Working with my network security team, they gave me the network traffic result for the blocked request, and I can confirm that my Azure network security is rejecting the request on the basis of Rule 949110, which is part of the OWASP CRS 3.2 rule set.
Feb 18 is going to delay my delivery of the DOCX editor in my platform by 2 months, given our delivery cycle and planned release schedule. I will continue to work what I can on my end, but if the team would at least consider backporting this into v11.9 or v11.10 as a security fix, that would be greatly appreciated.
I’d be happy to take a call to discuss further if necessary.
Could you please confirm if the fix in experimental 11.11 version addresses your issue? If so, I can ask the product/development team if this is a feasible request.
My build just finished deploying and I can confirm that the nightly experimental build “WebViewer_2026-01-14_experimental.zip” does resolve the issue I am facing.
Confirming what I know about Azure Application Gateways (AGW) and Web Application Firewall (WAF) rules, it does appear that Rule 949110 more of an Anomaly “Catch All”, per the documentation I was provided here:
The issue I have is that I don’t control my production infrastructure WAF configuration. That is handled by another team, and there are lots of hoops to jump through to get exceptions, even for specific routes / paths / endpoints.
The response I received from my network security team is that the ?externalPath=../external/ is being evaluated as a potential Path Traversal attempt, which is considered a High security vulnerability, so while I can still work towards getting an exception for this request path, it’s going to require some significant discussion and scrutiny. I can offer that a resolution is being worked on, but I don’t know if that will be sufficient.
If v11.11.0 doesn’t release until Feb 18, per our release cycle, the earliest I can get that to my clients is mid-March, which will require more discussion on our side to account for the delays in feature development.
The development team looked into this and determined that we are not vulnerable to Path traversal . The externalPath is not loaded or passed to a server environment; it’s used to make a request to web resources over https and can only access resources that are publicly available normally through https.
Unfortunately that doesn’t get me past my Azure AGW / WAF issue rejecting that request and rendering the docx editor unusable.
As previously noted, I do not control my network security policies, so I am stuck until v11.11.0 is released, if this will not be hotfixed in v11.10 or v11.9.
Is there any way in the current v11.9 or v11.10 for me to affect that request and remove the externalPath query string parameter? Or is my only option to wait for a code change?
thank you again for the open dialog, and I hope you have a good weekend,
Personally, I have seen some users dig into the minified file and change the code directly, but this is not recommended as functionality can break or have unintended consequences.
I think your only option is to wait for the release, but if you just need a Proof of Concept, and not for production use, you could try with the experimental version until the official release and then update your package with a stable version afterwards.
I will look at the minified file and determine the risk of changing this file.
Agreed that it is not recommended, but I need to weigh my options carefully if I have to wait for FEB 18 for the v11.11.0 release.
A question for the development team : if I modify the code and remove the use of ?externalPath=../external, can they confirm whether or not the Office Editor Module still works correctly?
I think you could remove that part of the code to make it work, however since it is minified, there is still a risk of unintended consequence for this change.
my attempt at modifying the minified files appears to have worked.
since we aren’t placing the files anywhere else but the default, I removed the ?externalPath=../external/ queryString parameter, and in the OfficeEditorModule.js file, I hard-coded the use of ../external/ as the basePath
agreed that since the files are minified, there is a greater risk of unintended consequences, so we will thoroughly test this before taking anything to a production environment.
We will also look for the v11.11.0 release, and upgrade as soon as we can.
