Local Network Access iFrame Restrictions Causing Development Problems

Justin Griep 25 Reputation points
2025-12-04T18:17:40.4366667+00:00

With the release of Chrome v143 and Edge v143, Local Network Access restrictions have been implemented.

Due to this, our Teams app development has been halted as it now throws CORS errors in the dev environment.

We have narrowed the problem down to part of this specification where an iframe requires an attribute allow="local-network-access". We can't change this in the Teams app, as it creates the container iframe we are hosted in.

There are a good number of scenarios where we need local access, such as Vite JS.

I have tried to work around this with --ip-address-space-overrides command line argument to get it to treat our local dev calls as public. However, it seems the iframe protection ignores this and still causes a CORS violation.

The only workaround seems to be proxies / dev tunnels for these resources, but this can be difficult or time-consuming.

Here is a guide for reference on LNA adoptions:

https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?tab=t.0

Is anyone else experiencing this issue?

Has anyone come up with a workaround outside of proxies or dev tunnels?

Microsoft Teams | Development
Microsoft Teams | Development
Building, integrating, or customizing apps and workflows within Microsoft Teams using developer tools and APIs
0 comments No comments
{count} votes

Answer accepted by question author
  1. Teddie-D 9,580 Reputation points Microsoft External Staff Moderator
    2025-12-05T02:25:18.8566667+00:00

    Hi @Justin Griep 

    Thank you for posting your question in the Microsoft Q&A forum. 

    The enterprise policy applies only to top-level frames. When an app runs inside an iframe, as Teams tabs do, the browser still enforces the allow="local-network-access" requirement because the embedding frame must delegate that permission. 

    Unfortunately, since Teams controls the container iframe, you cannot add this attribute yourself. Even if LocalNetworkAccessAllowedForUrls grants local network access to the origin, the iframe sandbox continues to block local requests unless the parent frame explicitly includes allow="local-network-access". 

    Currently, Teams does not include this attribute, so the restriction remains. The most reliable workaround is to use proxies or developer tunnels such as ngrok or the dev tunnels in Visual Studio Code, which move the endpoint out of the local address space. 

    The Teams engineering team is evaluating the addition of allow="local-network-access" support in integration iframes, but there is no confirmed timeline. Please keep an eye on the Chrome 142 LNA Restrictions: Integration iframes require allow="local-network-access" · I…for updates.


    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 


4 additional answers

Sort by: Most helpful
  1. Q&A Assist
    2025-12-04T18:17:58.7033333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The implementation of Local Network Access restrictions in Chrome and Edge can indeed cause issues for applications like Teams that rely on iframes for functionality. As you mentioned, the requirement for the allow="local-network-access" attribute in iframes can lead to CORS errors if the Teams app does not permit changes to the iframe configuration.

    Currently, the recommended approach for handling local network access is to configure the LocalNetworkAccessAllowedForUrls policy in the registry for Chrome-based Microsoft Edge and Google Chrome browsers. This policy allows specific websites to access resources on local network endpoints, which is essential for enabling peer-to-peer communication in Microsoft eCDN. However, if you are unable to modify the iframe settings in the Teams app, this may not resolve your issue directly.

    While proxies or development tunnels are common workarounds, they can be cumbersome. Another potential solution could be to explore whether your development environment can simulate the necessary permissions or to check if there are updates or changes in the Teams app that might allow for better handling of local network access in iframes. Additionally, keeping an eye on updates from Microsoft regarding Local Network Access policies may provide new options in the future.

    If you are facing specific CORS errors, providing detailed error messages in developer forums or communities may also yield insights from others who have encountered similar issues.


    References:


  2. Leif Frederiksen - LEFR 0 Reputation points
    2025-12-10T11:42:51.1+00:00

    We are experiencing the exact same problem in Model Driven Power Apps (Dataverse) when we have the API call in a side-panel. The side-panel uses an iframe, and we cannot control this and put allow="local-network-access" on it.

    Is Microsoft working on a solution to this?

    0 comments No comments

  3. Ivan Yankulov 0 Reputation points
    2025-12-14T20:34:34.9766667+00:00

    We experience this when we have Spfx full page SP web part page with Azure Web services backend, published as personal Teams App, the requests to the backend are blocked and it is production. It is a major issue. If we turn off the Lna in Edge the Teams Web starts working imedia. Is this expected, how can this be solved for the Desktop Teams client?

    0 comments No comments

  4. Teddie-D 9,580 Reputation points Microsoft External Staff Moderator
    2025-12-15T06:53:10.93+00:00

    Hi @Leif Frederiksen - LEFR, @Ivan Yankulov
    This behavior is expected and is caused by how Chromium-based browsers enforce Local Network Access.

    In all of the scenarios mentioned, including Teams tabs, Power Apps side panels, and SPFx pages running inside Teams, the content is displayed inside Microsoft controlled iframes. These iframes do not grant the local network access permission. Because of that, any request to a local or private network endpoint is blocked by the browser before your application code can run. Browser settings and enterprise policies cannot override this restriction when the request comes from a nested iframe.

    For development and testing, you can work around this by exposing your local service through a publicly reachable URL. Tools such as ngrok or Visual Studio Code Dev Tunnels work because the browser no longer treats the request as local or private network traffic.

    This workaround is not a long-term solution. It does not change the underlying platform limitation. For production use, services need to be hosted on publicly accessible endpoints with proper authentication and network protections.

    A permanent fix would require changes in how Microsoft platforms configure iframe permissions. At this time, there is no supported method for app developers to bypass or override this behavior.
    Please also keep an eye on the GitHub issue Chrome 142 LNA Restrictions: Integration iframes require allow="local-network-access" · I…for ongoing updates from the Teams engineering team.

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.