SharePoint / SharePoint/sp-dev-docs

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

Open
#10,571 4 comments 0 reactions 1 assignee View on GitHub

@Ashlesha-MSFT is already working on this.

Since Jan 8, 2026.

Needs: Attention :wave: sharepoint-developer-support status:by-design
Dominant language
PowerShell
Stars
1.4k
Forks
1.1k
Avg merge
4d 12h
Merged PRs (30d)
12

Description

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>
  1. Publish and inspect the rendered DOM in Chrome DevTools.
  2. Observe that allow="local-network-access" is absent from the final iframe element in the DOM.
  3. 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?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.