Microsoft has had the custom scripting restriction in SharePoint Online for years. For most of that time, administrators could leave it half-managed: some sites with scripting enabled because classic web parts needed it, others locked down, the whole situation deferred indefinitely. That era is ending. From September 2025, Microsoft began enforcing tighter defaults across new and recently created site collections, and the pressure on existing sites is building. Administrators who are still running Script Editor web parts, custom master pages, or injected JavaScript in production SharePoint sites are one policy update away from a silent failure.
This post explains what the custom scripting setting actually controls, what breaks when it is enforced, what does not, and the practical steps to get ahead of the problem before it becomes an incident.
What "custom scripting disabled" actually means
The technical name for this control is DenyAddAndCustomizePages, a property set on each SharePoint Online site collection. When DenyAddAndCustomizePages is set to Enabled, the site is running in what Microsoft calls "NoScript mode." When it is set to Disabled, custom scripting is permitted.
The naming is counterintuitive: Enabled means scripting is denied; Disabled means scripting is allowed. Remember it - the PowerShell output reads backwards from what you expect.
In NoScript mode, the following are blocked regardless of the user's permission level:
- The Script Editor web part: existing instances display a placeholder message instead of executing. No JavaScript runs.
- The Content Editor web part when used to link to a JavaScript file: the link is ignored.
- Custom master pages: the site reverts to the default master page. Any custom branding applied through the master page gallery is suppressed.
- Custom actions that inject script: UserCustomAction entries that reference JavaScript files or inline script are silently blocked.
- Uploads to restricted galleries: the master page gallery, style library, and solutions gallery become read-only for non-SharePoint-admin accounts even if the user has Site Collection Administrator rights.
- SharePoint Designer customisations that rely on the above mechanisms: Designer can still open and read list structures, but script-based customisations will not execute.
The restriction applies across the board. It is not a per-user setting. A site collection administrator cannot bypass it; only a SharePoint tenant admin can change the property value on a site.
The restriction is not new. What is new is Microsoft removing the easy escape hatch that let administrators defer the decision indefinitely.
To find out which sites in your tenant currently have custom scripting allowed, the quickest method is PowerShell. The command Get-SPOSite -Limit All | Where-Object {$_.DenyAddAndCustomizePages -eq "Disabled"} returns every site collection where scripting is currently permitted. The list is usually shorter than expected in modern tenants; longer than expected in tenants that have been running since the SharePoint 2013 era.
What breaks and what does not
Understanding the exact blast radius is the first step toward a remediation plan. Not everything classic is affected; the restriction targets script execution, not content management.
What breaks: any customisation that works by executing JavaScript outside the SPFx app catalogue model. Script Editor web parts are the most common culprit. They were the go-to solution for adding custom buttons, navigation overrides, form validation, analytics tracking, and banner messages from roughly 2013 to 2019, and they remain in production on sites that have never been modernised. Custom master pages that load JavaScript files from the style library also fall into this category. So do jQuery-based custom actions that admins deployed in bulk years ago and have since forgotten about.
What does not break: modern SharePoint is largely unaffected. SharePoint Framework web parts and extensions use a different deployment model: they are installed through the app catalogue and run in a sandboxed iframe. The DenyAddAndCustomizePages setting has no impact on SPFx solutions. Likewise, Power Automate flows, Power Apps embedded in SharePoint pages, Microsoft Teams integrations, standard document library functionality, column formatting using JSON, and all built-in modern web parts continue to work without change.
This distinction matters for scoping the migration effort. If your sites were modernised in 2020 or later and you removed the Script Editor web parts at that point, you likely have very little exposure. If your sites were migrated from on-premises with "lift and shift" and classic customisations were brought across intact, the risk surface is larger.
Classic publishing sites carry the highest risk. Sites created with the Publishing Infrastructure site feature enabled often depend heavily on custom master pages for navigation, branding, and layout. When custom scripting is enforced on a publishing site, the visual result can be severe: navigation disappears, custom header and footer elements vanish, and the site may render without any theming at all. Publishing sites were already on a retirement path; the custom scripting enforcement is another signal that the migration to modern communication sites should not wait.
What SharePoint admins should do now
The remediation path has four steps. None of them is novel, but completing them in order matters.
Step 1: Build the inventory. Run the PowerShell command above to identify every site collection where custom scripting is currently enabled. This is the definitive list of sites at risk. Add to it any sites where your SharePoint permissions audit (see the guide on SharePoint permissions audits) has revealed that non-admin users have been granted elevated rights specifically to manage classic customisations. Those sites are almost certainly using custom scripting.
Step 2: Audit what each site actually uses. For each site on the list, you need to know concretely what would break if scripting were disabled today. Check for:
- Script Editor or Content Editor web parts on any page (not just the home page; classic web parts appear on list view pages, form pages, and wiki pages as well)
- Custom master pages in the master page gallery that are actively applied
- UserCustomAction entries: these can be listed via PnP PowerShell with
Get-PnPCustomAction - Files in the style library that are referenced by the master page or web parts
The output of this step is a site-by-site inventory of custom scripting dependencies with a rough assessment of what each one does and how critical it is to daily operations.
Step 3: Migrate to modern alternatives. For each dependency identified, the modern alternative is almost always available:
- Script Editor web parts displaying announcements or messages: use the modern Text web part or the Markdown web part.
- Script Editor web parts for analytics tracking: embed the tracking script through the SPFx Application Customizer, which executes correctly in NoScript mode because it uses the app catalogue.
- Custom master pages for branding: use the SharePoint theme generator and modern site theming. Communication sites support header backgrounds, custom colour palettes, and font selections without any master page involvement.
- Custom navigation injected by script: SPFx header extensions can replicate global navigation that was previously delivered by custom master pages.
The migration does not need to happen all at once. Start with the sites that have the simplest dependencies: a single Script Editor web part displaying a static message is a one-hour fix. Leave the complex publishing sites for last, and plan them as mini-projects with proper staging and user acceptance testing.
Step 4: Disable custom scripting as soon as each site is ready. Do not wait until all sites are migrated before disabling custom scripting on any of them. Each site you lock down is one less site in your risk inventory. Use the SharePoint admin centre (Active sites, select the site, edit the Custom scripts property) or PowerShell (Set-SPOSite -Identity <url> -DenyAddAndCustomizePages 1) to enforce the setting site by site as migration completes.
The goal is not to disable custom scripting across the entire tenant in one operation and deal with the fallout. It is to work methodically through the inventory, migrate each dependency, verify the site still works, and then permanently lock it down. Done consistently over a quarter, most tenants can clear the majority of their custom scripting exposure without a visible incident.
Governance tooling helps here. Keeping track of which sites have been audited, which have open dependencies, and who owns the remediation for each is a coordination task as much as a technical one. Teams that already have a regular SharePoint permissions review cadence find it natural to layer the custom scripting audit into the same cycle. If you are not already running regular permissions reviews, the Explore Master feature in ShareMaster gives you visibility into hidden site properties alongside the content-level metadata that is often needed to understand what a classic customisation is actually doing.
The administrators who are going to have a bad day are the ones who discover their exposure during a tenant-level policy change rather than before it. The inventory and migration steps above are not complicated. The only reason to defer them is the same reason the problem exists in the first place: classic SharePoint customisations are easy to forget until they break.
Frequently Asked Questions
What is the SharePoint custom scripting setting?
Custom scripting is controlled by the DenyAddAndCustomizePages property on each site collection. When set to Enabled, the site is in NoScript mode: the Script Editor web part, custom master pages, and JavaScript-based custom actions are blocked. When set to Disabled, those features are permitted. The naming is counterintuitive: Enabled blocks scripting, Disabled allows it.
Does disabling custom scripting affect SharePoint Framework solutions?
No. SPFx web parts and extensions operate through the modern app catalogue, which is separate from the DenyAddAndCustomizePages setting. SPFx solutions work regardless of whether custom scripting is enabled or disabled on a site. This is the principal reason Microsoft positions SPFx as the approved successor to classic JavaScript customisations.
Can I re-enable custom scripting on a SharePoint site if I need it?
A SharePoint administrator can currently set DenyAddAndCustomizePages to Disabled on a specific site via the SharePoint admin centre or PowerShell using Set-SPOSite. Treat this as a temporary bridge, not a permanent solution. Microsoft is progressively narrowing the conditions under which this override works, and future policy changes may remove it entirely for certain site types.