Security-reviewing a third-party SharePoint web part
Last updated:
A SharePoint Framework package runs JavaScript on your intranet pages, in your users' browsers, with your users' sessions. That deserves a review — but the review is shorter and more concrete than most people assume, because almost everything you need is inside the package itself and you can read it before you deploy anything.
The short version: unzip the .sppkg, read the manifests, judge the permission request, find out where the data goes, and confirm the uninstall path. Five steps, an afternoon at most. The rest of this page is each one in detail, plus the questions worth sending the vendor.
One framing that helps: you are not assessing whether the vendor is trustworthy in general. You are assessing how much damage is possible if they turn out not to be — which is a question about permissions and data flow, and has an answer.
1. Open the package
An .sppkg is a zip file. Rename it and extract it. You do not need the vendor's permission and you do not need to have bought anything — if they will not give you the package before you commit, that is itself a finding.
| What to look at | What you are checking |
|---|---|
| The solution manifest | The API permission requests, the version, and whether the solution is tenant-scoped. |
| <code>requiresCustomScript</code> | If true, the component can embed script authored by page authors. Treat that as a much higher-risk category. |
| <code>includeClientSideAssets</code> | If true, the JavaScript is served from your own tenant. If false, it is loaded from the vendor's CDN and can change without you redeploying anything. |
| The client-side assets | The actual bundle. It will be minified, but you can still search it for URLs — which tells you every host the component may contact. |
| Developer metadata | Publisher name, privacy URL, terms of use. Blank fields are a maturity signal. |
That fourth row is the highest-value ten minutes in the whole review: grep the bundle for http. Every endpoint the component can talk to is in there.
2. Judge the permission request
The manifest declares what the package will ask for. Approvals happen later, in the admin center, but you can read the request now and decide before anything is deployed.
- How many scopes? One narrow scope is a good sign. A list of them for a component that displays a table is not.
- Whose API? A request against
Microsoft Graphreaches your Microsoft 365 data. A request against the vendor's own API does not. - Read or write? Make them justify any
ReadWrite. - How broad?
.Allmeans tenant-wide, not what the current user can see.
Also worth knowing, because it removes a common fear: a package cannot acquire new permissions silently in an update. A new request appears as pending in your admin center and has no effect until an administrator approves it.
3. Find out where the data actually goes
This is where vendors are vaguest and where the real risk lives. There are two architectures and they are not comparable:
| Reads in the browser | Reads through the vendor's backend | |
|---|---|---|
| Who fetches the list rows | The user's browser, with the user's own session | The vendor's servers, with a stored credential |
| Do your rows leave the tenant? | No | Yes |
| Permissions applied | SharePoint's own, per user, unchanged | Whatever the stored grant allows |
| If the vendor is breached | They have no copy of your data and no standing access | They may have both |
Ask directly: “Do our list rows ever pass through your servers?” Then verify the answer against what you found in step 1 — if the bundle only ever calls SharePoint for data and the vendor's API for configuration, the architecture matches the claim.
4. Confirm how it comes out
Approve nothing whose exit you have not understood. Three questions:
- What happens to the data if we remove it? If the tool wrote to SharePoint lists, the data should simply stay there. If it lives in the vendor's database, you need an export path in writing.
- How do we revoke access? Removing the API permission and deleting the package from the App Catalog should be enough. If there is a separate Entra ID application to clean up, find out now.
- Can we disable one component without uninstalling everything? For anything deployed tenant-wide, this matters the first time one misbehaves.
5. The questions to send the vendor
- Which API permissions does the package request, and what feature needs each one?
- Do our SharePoint list contents ever reach your infrastructure?
- Do you store any credential or token belonging to our tenant?
- Who are your subprocessors, what does each one see, and in which region?
- Will you sign a DPA?
- What is your published SHA-256 for the package, so we can verify what we downloaded?
- What happens to our data and our components if we cancel?
How fast and how specifically those come back tells you as much as the answers. A vendor who has thought about this has the answers published; one who has not will send you a sales deck. Sharelio publishes all seven at sharelio.com/security, and the package and its hash can be downloaded without an account.
Frequently asked questions
Do we need to read the minified JavaScript?
Reading it line by line is rarely worth the effort and rarely conclusive. Searching it is: extract the bundle and search for URLs to enumerate every host the component can contact, and for terms like eval or innerHTML if you want a quick sense of how it renders. The manifests and the data-flow question tell you far more per minute spent.
Is a web part from AppSource automatically safe?
Safer, not safe. Microsoft's certification checks that the solution behaves, does not let end users inject arbitrary script, declares valid developer metadata and works as described. It does not audit the vendor's backend, their subprocessors or their data handling. AppSource presence is a useful signal that raises the floor; it does not replace steps 2 to 4 above.
What is the single biggest red flag?
A request for broad Microsoft Graph scopes that nobody can tie to a specific feature — especially application (app-only) permissions, which are not limited by who is viewing the page. Close second: a vendor who cannot say plainly whether your data passes through their servers.
How long should this review take?
For a well-documented package, an afternoon: an hour with the package, an hour on the vendor's documentation, and a short exchange of questions. If it is taking weeks, the delay is usually organisational rather than technical — which is worth naming, because it is the thing that actually blocks the business from getting the tool.