SharePoint HTML pages are governed by a setting your custom script audit does not read

For eight years the answer to can somebody make their own HTML run on this SharePoint site? has lived in one setting. An HTML file in a library is downloaded rather than run, and the documented way round that, renaming it to .aspx, works only for somebody holding the AddAndCustomizePages permission. A site that blocks custom script grants that permission to nobody. Audits read DenyAddAndCustomizePages, report Custom script: blocked, and that line has been taken to mean that no code of a user's own runs on the site.

SharePoint HTML pages change that, and Microsoft's own documentation of the feature says so in a way most coverage has not drawn out. HTML pages run JavaScript. They are on by default. They are switched off site by site, by each site owner, from a toggle in the Site Pages library. And to the question Can I disallow or restrict HTML pages at the tenant level? Microsoft's support article answers, in full: No.

This analysis reads what Microsoft has published on 6 November 2026, separates it from what independent testers have observed, and names what neither has established. No tenant was accessed.

Where the feature stands, by source

Three Microsoft surfaces describe the same feature and they do not agree, which is itself the first thing worth knowing.

The roadmap row was read from the public roadmap's own JSON, which answers without sign-in:

curl -s https://www.microsoft.com/releasecommunications/api/v1/m365/569208

It returns the item's status, its target month and a modified timestamp. That timestamp is the useful part: it says when Microsoft last touched the entry, and here that was the day it was created. A roadmap status is a planning label, not the state of the feature in a tenant. The message centre carries the dated rollout. The only proof for a given tenant is the toggle appearing in its Site Pages libraries. We read MC1479517 through public copies of the message rather than in a tenant's admin centre, and the dates above are as those copies give them.

What Microsoft documents

The support article is short and specific. HTML pages are stored in the Site Pages library, created with Copilot or uploaded as an .html file or a folder of files. Images and other assets go to Site assets. A file can be up to 10 MB.

On how the HTML runs, it states four things directly:

• SharePoint renders HTML in a sandboxed iframe that isolates the page from the surrounding SharePoint header, footer, and navigation.
• Content Security Policy (CSP) rules provide extra isolation.
• The sandbox supports JavaScript when the code is contained in the same HTML file. Scripts from a CDN are not supported, apart from Microsoft-managed copies of Chart.js, Mermaid, React, Fluent UI and Babylon.
• SharePoint blocks arbitrary fetch requests and outbound API calls from HTML pages, and the sandbox cannot use the browser's localStorage.

Pages can show live data from lists and Excel. Links to domains outside SharePoint open only if the domain is on the site's HTML Field Security allow list, which a site admin maintains under site settings.

On who can do what, the article lists access per task, not per permission level. Opening the creation screen with Copilot needs permission to create or edit pages and a Microsoft 365 Copilot licence. Uploading or moving HTML into Site Pages needs permission to add or move files, and no Copilot licence. Publishing doesn't grant new permissions: the page is visible to whoever can already view it.

On control, three sentences carry the whole governance question:

• HTML pages are enabled by default.
• A site owner can turn Allow HTML files off from File types in the Site Pages library.
• At tenant level, there is no restriction.

The article does not mention custom script, DenyAddAndCustomizePages or NoScriptSite at all.

What independent testers have observed

Denis Molodtsov tested HTML pages on a Targeted release tenant in August 2026 and published the measurements. Two of them bear directly on governance.

First, the test site had custom scripting denied, NoScriptEnabled: true, and the HTML files run fine. Molodtsov's explanation is the sandbox: the file never runs as a SharePoint page, so the setting that governs SharePoint pages does not govern it.

Second, the policy SharePoint attached to the frame included default-src 'none', connect-src 'none', frame-src 'none', base-uri 'none' and form-action 'none'. That is consistent with what Microsoft documents and goes further: on the evidence of that policy, an HTML page could not submit a form anywhere or load anything from outside the file. The same test found that the frame does not know who the viewer is, and that SharePoint reads the list data on the viewer's behalf and hands it into the frame.

Both observations are one person's measurements, on one tenant, before general availability. An October update to the article says links, images and the page chrome changed at general availability and that the sandbox architecture still applies. They are evidence, and they are dated, and they are not Microsoft's word.

What follows, and what does not

HTML pages are not custom script coming back. The documented sandbox is narrower than custom script ever was. Custom script on a classic page ran in the page itself, with the viewer's signed-in session and every API the viewer could call. An HTML page's script runs in a frame that, on what is documented and observed, cannot call out, cannot load outside code, cannot submit a form and cannot see the page around it. That is a deliberate design, and it is the reason the feature can run on sites where custom script is blocked.

What moved is the decision, not the risk of script. The two script controls Microsoft has tightened most are held by SharePoint administrators. Custom script on a site is reset to Not allowed within 24 hours of being allowed, and Microsoft has dated the end of that allowance: DenyAddAndCustomizePages is enforced as True and cannot be changed from 1 March 2027 in tenants created that day or later, and from 1 October 2028 in every other tenant (upcoming changes to classic pages and custom scripting, read 7 November 2026). Trusted script sources for the Content Security Policy are a tenant list in the SharePoint admin centre. HTML pages sit outside both. They are on unless a site owner switches them off, the switch is per library, and Microsoft states there is no tenant-level restriction.

The page is no longer limited to the components an organisation approved. A modern page is assembled from web parts, and each web part an organisation added went through somebody's review. An HTML page is any layout and any logic its author can fit in one file, published on the organisation's own domain to everyone who can read the site. The sandbox keeps that content from reaching out. It does not review what the content says.

The old HTML files are one action from becoming pages. Since strict browser file handling became mandatory at the end of 2018, an .html file in a document library has been downloaded, not rendered. Microsoft now documents Edit in SharePoint on such a file: SharePoint moves the file to the Site Pages library and opens it in edit mode, where it renders in the sandbox. Microsoft's own guide to the 2018 change noted that such files typically live in migrated classic team sites.

And Custom script: blocked now answers a smaller question than it is asked. It still states a true fact about one mechanism. It no longer says anything about whether a user's own HTML and JavaScript can run on the site, because the documented answer to that is now a different setting, held by a different person.

What has not been established

• Whether the switch can be read in bulk. The support article documents Allow HTML files in the library's interface. We have found no documented API that reads it, so a tenant-wide report of where HTML pages are allowed cannot be described yet. The next measurement is to read the Site Pages library's properties before and after the toggle on a test site.
• The frame's origin and its full policy today. The policy above was observed in August 2026, before general availability. Whether the frame runs on an origin separate from the tenant, and which policy it carries now, are measured in the browser's developer tools on a published HTML page.
• What the audit log records. Whether an HTML page upload or publication is distinguishable from an ordinary file upload in Microsoft Purview has not been documented or observed.
• Search, labels and data loss prevention. The message centre says existing storage and retention behaviour applies. Whether sensitivity labels and data loss prevention treat an HTML page as a page or as a file is not stated.

What to do before general availability reaches your tenant

1. Decide per site, because there is no tenant switch. List the sites where nobody should publish free-form pages: the intranet home, regulated sites, sites with external audiences. Plan to turn Allow HTML files off in their Site Pages libraries when the toggle appears.
2. Read who can add files to Site Pages on the sites with the widest reach. That permission is now enough to bring an HTML page, and a page published there reaches the site's whole audience.
3. Review the HTML Field Security allow lists. They now decide where links on HTML pages may go.
4. Inventory .html files in document libraries by enumeration. A search query returns what the index matched, not what the libraries hold, and these are the files one action away from rendering.
5. Rewrite the audit line. Report custom script as what it is, and report HTML pages as a separate line, stated as not established until the switch can be read.

What our rule says about this

Our engine's SPO-SCRIPT-001 reads DenyAddAndCustomizePages and reports a site that permits custom script. It says nothing about HTML pages, and a site it does not flag can host them. That is not a gap the rule can close by itself: there is no documented read of Allow HTML files for a collector to make, and a rule without a collector behind it would be an opinion. When the setting can be read, the order is the usual one: a collector first, and a rule only where one is defensible.

References

• Create, upload, edit, and publish HTML pages in SharePoint (Microsoft Support, read 6 November 2026)
• Microsoft 365 roadmap 569208, SharePoint: HTML pages, and its JSON at https://www.microsoft.com/releasecommunications/api/v1/m365/569208 (read 6 November 2026)
• MC1479517, SharePoint: HTML pages (Microsoft 365 message centre, September 2026, read through public copies)
• Support for Content Security Policy (CSP) in SharePoint Online (Microsoft Learn)
• Migrating from the permissive browser file handling to the default strict browser file handling (Microsoft Learn)
• Allow or prevent custom script (Microsoft Learn)
• SharePoint HTML pages, what they can and cannot do (Denis Molodtsov, August 2026, updated October 2026)

Tags#sharepoint#governance#security#copilot