CSP changes (March) blocking inline scripts - how are people handling this in SharePoint Online? #1827
Unanswered
Cjreynolds42
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi all,
Looking to sense check how others are handling recent CSP changes in SharePoint Online.
We have been using the sample solution for a number of years that injects JavaScript (via Script Editor / similar approach) to support analytics tracking. This has been stable for a long time.
However, following the CSP updates rolled out around March, we’re now seeing this blocked. The script is being flagged as inline and prevented from executing.
From what I can see, this is expected behaviour with the stricter Content Security Policy now being enforced, particularly around inline scripts and allowed domains.
Our current thinking is that this approach is no longer viable long-term, and the provided sample solution will need to be refactored:
• SPFx-based extension (Application Customizer)
• External JS hosted and referenced in a compliant way
• Potentially rethinking how tracking is implemented altogether
Before we go too far down that route, I wanted to ask:
• Are others seeing the same behaviour post-CSP changes?
• Have you successfully worked around this without moving the entire JavaScript into discrete files?
• If you’ve moved to the JavaScript to discrete files, any patterns or gotchas worth being aware of (particularly around analytics / tracking scenarios)?
• Any issues with CSP when loading external scripts (e.g. Google Analytics domains)?
Keen to understand what “good” looks like now in a CSP-compliant world, especially for scenarios that previously relied on lightweight script injection.
Appreciate any insight or examples.
Thanks in advance,
Chris
All reactions