In Chrome 147 and later, Local Network Access (LNA) restrictions now apply to WebSockets. Normally, this just requires a permission prompt. But, for content in iframes – like the Webflow Designer Extensions – the iframe must also have allow="loopback-network" in order to attempt this at all.
If you self-host the Webflow MCP Bridge App in development mode, there is no issue because the iframe itself is served from localhost. You'll get a permission request from Chrome (to access the iframe HTML served from localhost), but the iframe is allowed to connect to the localhost WebSocket without allow="loopback-network". (Localhost iframe documents are exempt from iframe permission policy restrictions on local/loopback subresource fetches.)
Steps
If you self-host the Webflow MCP Bridge app by uploading a bundle.zip (following the repo instructions here) and attempt to launch the Designer Extension in production mode, Chrome will refuse to connect to the localhost socket.io WebSocket due to the lack of allow="loopback-network" on the iframe.
The error logged in the Chrome console is generally unhelpful. When socket.io is in WebSocket mode, Chrome will report:
WebSocket connection to 'ws://<localhost WebSocket>' failed
If you set socket.io to long-polling mode, it'll show:
Access to XMLHttpRequest at 'ws://<localhost WebSocket>' from origin 'https://ID.webflow-ext.com' has been blocked by CORS policy: Permission was denied for this request to access the loopback address space.
Security
The LNA restriction is new. Requiring opt-in for iframes makes sense as a default for Chrome; it can help prevent malicious ads/embeds from requesting LNA permission. In that case, the permission prompt appears to come from the parent page and is not obviously connected to a particular frame or action. With Webflow Designer Extensions, the LNA prompt would only appear after loading a particular app (which the user has already explicitly approved and installed), making the association much clearer. All standard web security like CORS and origin cookie partitioning continues to apply.
Other considerations
I'm particularly interested in this bug because it also affects an internally developed extension that follows the same communication model as the Webflow MCP Bridge App (OSS/self-host edition). Generally, allowing a Webflow Designer Extension to communicate with localhost is the only viable to provide performant integrations between Webflow Designer and local desktop apps.
In Chrome 147 and later, Local Network Access (LNA) restrictions now apply to WebSockets. Normally, this just requires a permission prompt. But, for content in iframes – like the Webflow Designer Extensions – the iframe must also have
allow="loopback-network"in order to attempt this at all.If you self-host the Webflow MCP Bridge App in development mode, there is no issue because the iframe itself is served from localhost. You'll get a permission request from Chrome (to access the iframe HTML served from localhost), but the iframe is allowed to connect to the localhost WebSocket without
allow="loopback-network". (Localhost iframe documents are exempt from iframe permission policy restrictions on local/loopback subresource fetches.)Steps
If you self-host the Webflow MCP Bridge app by uploading a bundle.zip (following the repo instructions here) and attempt to launch the Designer Extension in production mode, Chrome will refuse to connect to the localhost socket.io WebSocket due to the lack of
allow="loopback-network"on the iframe.The error logged in the Chrome console is generally unhelpful. When socket.io is in WebSocket mode, Chrome will report:
WebSocket connection to 'ws://<localhost WebSocket>' failedIf you set socket.io to long-polling mode, it'll show:
Access to XMLHttpRequest at 'ws://<localhost WebSocket>' from origin 'https://ID.webflow-ext.com' has been blocked by CORS policy: Permission was denied for this request to access theloopbackaddress space.Security
The LNA restriction is new. Requiring opt-in for iframes makes sense as a default for Chrome; it can help prevent malicious ads/embeds from requesting LNA permission. In that case, the permission prompt appears to come from the parent page and is not obviously connected to a particular frame or action. With Webflow Designer Extensions, the LNA prompt would only appear after loading a particular app (which the user has already explicitly approved and installed), making the association much clearer. All standard web security like CORS and origin cookie partitioning continues to apply.
Other considerations
I'm particularly interested in this bug because it also affects an internally developed extension that follows the same communication model as the Webflow MCP Bridge App (OSS/self-host edition). Generally, allowing a Webflow Designer Extension to communicate with localhost is the only viable to provide performant integrations between Webflow Designer and local desktop apps.