SharePoint Online strips iframe allow="local-network-access" attribute,

[marlenkassym]

What type of issue is this?

Question

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

Chromium based v142+

Issue description

We’re encountering a behavior in SharePoint Online where iframe markup containing a Permissions Policy delegation attribute (allow="local-network-access") is being stripped from the rendered DOM on a modern page. Modern Chromium browsers require this directive for Local Network Access (LNA) permission delegation when the framed resource requires access to local/private network endpoints (e.g., Integrated Windows Authentication/IWA).

This behavior is impacting embedded authentication flows such as Okta Integrated Windows Authentication (DSSO) inside SharePoint Online iframes, even when the target origin is allow-listed via enterprise browser policy.

Reproduction Steps

1. Create a modern SharePoint Online page.
2. Embed HTML such as:

<iframe
  src="https://mycompany.okta.com/app/UserHome?iframe=true"
  allow="local-network-access"
  width="1000"
  height="600">
</iframe>

3. Publish and inspect the rendered DOM in Chrome DevTools.
4. Observe that allow="local-network-access" is absent from the final iframe element in the DOM.
5. Verify that the same iframe markup works as expected on a standalone external HTML page: the attribute is preserved in the DOM and Local Network Access works if enterprise browser policies are configured.

Observed Behavior
SharePoint Online sanitizes the iframe markup, removing the allow="local-network-access" attribute.
As a result, Chromium browsers (Chrome 142+) block local network access inside the iframe, even when:
The Okta origin is configured in LocalNetworkAccessAllowedForUrls via enterprise policy.
The user has an active Okta session in another tab.
This prevents Okta IWA/DSSO flows that require a local network hop from succeeding in the embedded context.

Expected Behavior

SharePoint Online should provide a supported mechanism to preserve/forward Permissions Policy delegation attributes such as allow="local-network-access" for iframes containing trusted content.

Additional Context

We have verified via chrome://policy that the enterprise allow-list is applied.
The issue occurs only within SPO-hosted pages; outside SPO, the behavior works as expected.
SharePoint Online does not expose an “HTML Field Security” setting or any equivalent control in the UI or via PowerShell to allow retention of such attributes.
Without the ability to preserve this permission delegation, modern browser requirements for Local Network Access cannot be satisfied in SPO iframes.Alternatively, documentation indicating this is by design and not supported would be helpful.

Questions / Requests

Is SharePoint Online intentionally stripping allow="local-network-access" from iframe markup?
Is there a supported way – within modern SharePoint Online pages – to preserve Permissions Policy iframe attributes?
Is there any upcoming roadmap support for explicit iframe permission delegation for trusted content?

[Ashlesha-MSFT]

Hello @marlenkassym,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
If you don’t receive a reply within two working days, please use this escalation form to escalate.

[Ashlesha-MSFT]

This behavior is by design, and there’s no supported way to preserve Permissions Policy delegation attributes in modern SPO pages.
As a result, scenarios requiring Local Network Access from an iframe, such as Okta IWA/DSSO, aren’t supported.
We recognize this can affect enterprise SSO flows in newer Chromium browsers.
While there’s no public roadmap for enabling this capability, we encourage submitting feedback through Microsoft 365 channels for future consideration.