30-second answer
Get-PnPTenantSite -Identity https://contoso.sharepoint.com/sites/team |
Select-Object Url, DenyAddAndCustomizePagesTrue establishes one thing precisely: nobody on this site can insert script
into a page, and nobody can mark a file as executable. It does not establish
that no interactive content can reach a reader on that site.
What this proves
That the AddAndCustomizePages permission is held by nobody on the site, which
is the permission the entire classic scripting model turns on. Microsoft is
explicit about why that matters: script in a SharePoint page, including an HTML
page in a document library, runs in the context of the user visiting the page,
has access to everything that user has access to, and can reach other Microsoft
365 services through Microsoft Graph. Once scripting is allowed, the
documentation states you can no longer identify what code was inserted, where,
or by whom.
Turning it off closes that door. It is a real control, and it is why Microsoft turns it off by default on modern sites.
What it does not prove
- That the HTML file in the library is inert because of this setting. It is inert for a second reason. Under strict browser file handling, which is now the only model available, files that could cause harm are not executed but downloaded or shown as raw content.
- That HTML is blocked. It is not. Writing about Content Security Policy, Microsoft states plainly: Added script will not execute, added HTML will still work. HTML and executable script stopped being one thing, and a control named for script does not speak for both.
- That no approved code runs in the page. SPFx is the governed alternative Microsoft recommends and it is not a sandbox: the documentation says the framework runs in the context of the current user in the browser and its controls render in the normal page DOM. What SPFx changes is who authorises the code, not where it executes.
PowerShell
# The setting, per site.
Get-PnPTenantSite -Identity https://contoso.sharepoint.com/sites/team |
Select-Object Url, DenyAddAndCustomizePages
# Every site where it is allowed, which is the list worth having.
Get-PnPTenantSite |
Where-Object { -not $_.DenyAddAndCustomizePages } |
Select-Object Url, Template, Owner
# The other four controls in the chain are read elsewhere:
# Trusted script sources, in the SharePoint admin centre
Get-SPOContentSecurityPolicy
# Whether CSP is being enforced yet in this tenant
(Get-SPOTenant).ContentSecurityPolicyEnforcementExample output
Url DenyAddAndCustomizePages
--- ------------------------
https://contoso.sharepoint.com/sites/team True
https://contoso.sharepoint.com/sites/legacy FalseRead the second line as this site still allows the classic model, and the first as this site does not, not as this site cannot render anything interactive.
Explanation
Five controls sit between an HTML file and a reader's browser, and each answers a different question.
| Control | Question it answers |
|---|---|
DenyAddAndCustomizePages | May anyone here insert script into a page? |
| The execution mark on a file | Was this file put here by somebody holding AddAndCustomizePages? |
| Strict browser file handling | What does the browser do when the file is opened? |
| App Catalog approval | Did an administrator approve this component? |
| Content Security Policy | Which origins may serve script to this page, and is inline script allowed? |
The second row is the mechanism the first one actually operates through, and it
is the one nobody quotes. A file becomes executable only when somebody holding
AddAndCustomizePages marks it so. Microsoft records both halves of the
consequence: a rename performed by a site member produces a file that is not
marked for execution and is therefore downloaded rather than executed, and any
later change to such a file marks it non-executable again.
So on a noscript site nobody can mark anything executable, and on any site editing a file removes the mark it had. The setting and the file state are one mechanism seen from two ends.
Production considerations
CSP is enforced on non-classic pages from 1 March 2026, with a tenant option to
delay it to 1 June 2026. It controls which origins may serve script, blocks
inline script outright, and is administered through Trusted script sources in
the SharePoint admin centre. Expressions that are too permissive, such as *,
*.domain, 'unsafe-inline' and 'strict-dynamic', are refused, and the list
is capped at 300 entries.
CSP is also the first control in this chain that leaves an audit trail:
violations are logged to Microsoft Purview as ViolatedContentSecurityPolicy
with DocumentUrl and BlockedUrl. Against a model whose own documentation
says you cannot identify what code was inserted or by whom, that is a real
change.
Its limits are documented too. CSP is not enforced for SPFx components on
classic pages, eval() remains available because 'unsafe-eval' is part of the
standard header, and it does not apply to SharePoint Add-Ins, which stop working
on 2 April 2026.
What this article does not cover. Copilot in SharePoint now creates interactive reports from SharePoint content. How those are executed, in which origin, under which policy, and whether the authorization of their source data survives into the generated artefact is not established by any Microsoft documentation read for this article. That is a separate investigation and it is not answered here by inference.
The honest summary. SharePoint did not make HTML safe and it did not quietly
let scripts back in. It split one question into several, and each control now
answers its own. An audit line reading Custom script: blocked states a fact.
The conclusion usually drawn from it, that no executable or interactive
experience can run on the site, is a wider claim and does not follow from that
fact alone.
Related governance rules
None. No published rule reads DenyAddAndCustomizePages, and that is deliberate
until the wording above is the wording it ships with.
References
- Security considerations of allowing custom script (Microsoft Learn)
- Allow or prevent custom script (Microsoft Learn)
- Migrating from the permissive browser file handling to the default strict browser file handling (Microsoft Learn)
- Support for Content Security Policy (CSP) in SharePoint Online (Microsoft Learn)
- Get started with Copilot in SharePoint (preview) (Microsoft Learn)
- Get-PnPTenantSite (PnP PowerShell)
Found something wrong? Suggest a correction. The article source is not public; the engine it cites is.
What this answer underwrites
The engine reads these Microsoft operations to collect evidence, so what is established here is what those collectors rest on.