SharePoint and OneDrive Security Guide: Sharing, Permissions and Oversharing Controls

SharePoint Online and OneDrive hold most of an organisation's documents, and their default behaviour favours sharing: any user can create links, invite guests and grant broad groups access, so exposure accumulates quietly over years. This guide explains how access actually works across tenant, site, library and item, which admin roles and app permissions carry the most risk, and which settings, labels and policies bring sharing back under control. It covers SharePoint Online and OneDrive for Business, with a short section on on-premises SharePoint Server after the 2025 ToolShell exploitation. It is written for Microsoft 365 administrators, security engineers and data protection leads. Tenant-wide Microsoft 365 hardening is in the Microsoft 365 Security Guide, and oversharing as it affects Copilot is covered in the Microsoft 365 Copilot Security Deep Dive.

Key takeaways

• Sharing settings cascade downwards only. A site or OneDrive can be as restrictive as the organisation setting or more so, never more permissive, so the tenant level sets the ceiling.
• Links are the main exposure path. Anyone links work without sign-in and cannot be scoped by device policy; limit them, make them expire and default users to Specific people links.
• Admins can reach any content. SharePoint and Global Administrators do not have automatic access to every site and OneDrive, but they can grant it to themselves, so treat these roles as privileged.
• Apps should get Sites.Selected, not tenant-wide scopes. An integration with Sites.ReadWrite.All can read or change every site; selected scopes limit it to sites an administrator assigns.
• Oversharing is a reporting problem first. Data access governance reports, sharing audit events and site access reviews show where to apply restricted access control, labels and DLP.

How identity and access work in SharePoint and OneDrive

Every request is authenticated by Microsoft Entra ID, then authorised against SharePoint permissions. Access can be granted at several layers, and the effective result is the union of all of them, minus whatever tenant-level policies block.

External sharing levels

The tenant and each site choose one of four levels: Anyone (unauthenticated links plus guests), New and existing guests (guests sign in with a work, school or Microsoft account, or a verification code), Existing guests (only guests already in the directory) and Only people in your organisation. The OneDrive setting may be more restrictive than SharePoint but not more permissive, and each site must be the same as or more restrictive than the organisation. Restricting or turning off sharing typically removes guest access within an hour; turning it back on restores it.

Decision guidance: most organisations should run the tenant at New and existing guests, set the default link to Specific people, and allow Anyone only on named sites that genuinely publish to the public, with expiry and view-only enforced. Small organisations that collaborate heavily with clients may keep Anyone at tenant level but should still set a short expiry. Regulated organisations often set confidential sites to Only people in your organisation through a sensitivity label so owners cannot loosen them.

Tenant sharing controls worth setting

• Anyone link expiry and permissions: set a maximum number of days and restrict Anyone links to view only. Shortening the limit updates existing links.
• Domain restrictions: allow or block up to 5,000 domains (Set-SPOTenant -SharingDomainRestrictionMode with -SharingAllowedDomainList or -SharingBlockedDomainList). Entra B2B allow and block lists also apply when B2B integration is on.
• Who may share externally: limit external sharing to members of named security groups.
• Guests resharing: keep "Allow guests to share items they don't own" off.
• Guest expiry and reauthentication: set guest access to a site or OneDrive to expire after a set number of days, and require verification-code users to reauthenticate periodically.

The tool-neutral principles behind these settings are in the Secure File Sharing Guide; guest lifecycle is covered in the Third-Party Access Guide.

Admin roles and privileged access

The SharePoint Administrator role can create and delete sites, add and remove site admins, change organisation sharing settings, manage Microsoft 365 groups and set storage limits. Global Administrator includes all of these. Microsoft notes that these administrators do not automatically see every site and OneDrive but can give themselves access to any of them, which makes the roles a direct path to all document content.

• Just-in-time elevation: make SharePoint Administrator an eligible role in Privileged Identity Management and require approval for activation. See the Active Directory and Entra ID Hardening Guide.
• Watch self-granted access: alert when an administrator adds themselves as a site admin of a site or OneDrive they do not own, outside an approved request.
• PowerShell and admin centre access: SharePoint Online Management Shell and PnP PowerShell sessions run with the signed-in admin's rights, so the same Conditional Access and device requirements must apply to them as to the browser.

Integrations, API tokens and service accounts

Backup tools, migration tools, workflow platforms and line-of-business apps reach SharePoint through app registrations. These are non-human identities with tenant-level reach, and they are often the least reviewed access in the tenant.

• Prefer selected scopes: Sites.Selected grants an app access only to site collections that an administrator explicitly assigns through POST /sites/{siteId}/permissions with a role of read, write, owner or fullcontrol. Newer scopes (Lists.SelectedOperations.Selected, ListItems.SelectedOperations.Selected, Files.SelectedOperations.Selected) narrow this to lists, items or files. Consent alone grants nothing; the assignment is required too.
• Challenge tenant-wide scopes: Sites.ReadWrite.All, Sites.FullControl.All and Files.ReadWrite.All as application permissions reach every site and OneDrive. Require a documented reason and owner for each.
• Retire legacy app-only tokens: new tenants have Azure ACS app-only authentication disabled by default (DisableCustomAppAuthentication), and Microsoft recommends the Entra app-only model. Keep it disabled.
• Credentials: use certificates or managed identities rather than client secrets for app-only access, store them in a vault and rotate them. See the Entra ID Applications and Consent Guide.
• User consent: block users from consenting to apps requesting file access; a consent-phishing app with delegated Files.Read.All reads everything the user can. See the SaaS and OAuth App Governance Guide.

Third-party integrations holding Microsoft 365 app secrets have been targeted directly: the Commvault Metallic breach followed a zero-day in the backup provider's Azure environment, where client secrets for the app registrations used to reach customers' Microsoft 365 tenants may have been accessed. Ask any vendor with SharePoint access how it stores and scopes those credentials.

Oversharing controls

• Restricted access control setup: enable it with Set-SPOTenant -EnableRestrictedAccessControl $true (up to an hour to take effect), then per site with Set-SPOSite -Identity <url> -RestrictedAccessControl $true and -AddRestrictedAccessControlGroups. Blocking sharing outside the control groups is opt-in with Set-SPOTenant -AllowSharingOutsideRestrictedAccessControlGroups $false.
• Unmanaged devices: Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess gives browser-only access with no download, print or sync; Set-SPOSite ... -ConditionalAccessPolicy BlockAccess blocks a site. Also block apps that do not use modern authentication, which otherwise bypass the policy. Changes can take up to 24 hours.
• OneDrive sync: "Allow syncing only on computers joined to specific domains" restricts the sync app to Active Directory domain GUIDs; for Entra-joined devices use Conditional Access instead. Synced OneDrive folders put copies on endpoints, so endpoint encryption and wipe matter as much as tenant settings.
• DLP: scope policies to SharePoint sites and OneDrive accounts, run them in simulation mode first, then enable policy tips before blocking. See the Data Loss Prevention (DLP) Guide and the Data Classification Guide.

Small versus large tenants: container labels, the unmanaged device policy and DLP are available without SharePoint Advanced Management and cover most needs in a small tenant. Large tenants with thousands of sites need the SAM reports and delegated site access reviews, because manual review does not scale. Check current SAM licensing in Microsoft's documentation; it has changed alongside Copilot licensing.

Logging and detection

SharePoint and OneDrive activity is recorded in the Microsoft Purview unified audit log. The sharing operations Microsoft documents are the most useful starting point.

• Detection use cases: spikes in file downloads or sync by one account (MITRE ATT&CK T1213.002 Data from Information Repositories: Sharepoint and T1530 Data from Cloud Storage); Anyone links created on labelled sites; administrators adding themselves to sites; new app permissions with tenant-wide scopes (T1098 Account Manipulation); sign-ins by compromised cloud accounts (T1078.004).
• Phishing via OneDrive and SharePoint: attackers share lures from compromised tenants because the links come from a trusted Microsoft domain (T1566.002 Spearphishing Link). Monitor inbound sharing notifications and user reports. See the Phishing Incident Response Playbook.
• SAM reports: data access governance reports cover sharing links activity, "Everyone except external users" (EEEU) insights, permission state and sensitivity label snapshots; change history reports cover site setting changes for the last 180 days.

Metrics

• Number of active Anyone links, and the share with no expiry.
• Sites granting access to EEEU or "Everyone", trending down.
• Sites with fewer than two owners, from the site ownership policy.
• Applications with tenant-wide SharePoint or Files application permissions.
• Percentage of sites carrying a container sensitivity label.
• Site access reviews completed on time by owners of flagged sites.

Hardening baseline and rollout

1. Measure first: export sharing settings and run data access governance or equivalent reports to find Anyone links, EEEU grants, unowned and inactive sites. Do not change anything yet.
2. Set tenant ceilings: default link to Specific people, Anyone links view-only with expiry (or off), guest expiry, guests unable to reshare, external sharing limited to named groups where appropriate. Communicate changes before applying.
3. Labels for containers: publish container labels to a pilot group of site owners, then make labelling mandatory for new sites. Label the most sensitive existing sites centrally.
4. Protect the crown jewels: apply restricted access control, restricted content discovery and block download to the small set of highest-risk sites, testing with owners before enforcement.
5. Device and session policy: pilot limited web-only access for unmanaged devices with one department; then expand. Block legacy authentication.
6. DLP: run policies in simulation mode, tune false positives, enable tips, then block.
7. Apps: inventory app permissions, move integrations to Sites.Selected, remove unused apps and secrets.
8. Roll back safely: each tenant setting can be reverted from the admin centre or PowerShell, but unmanaged device policy changes take up to 24 hours either way, and re-enabling external sharing restores previous guest access. Record the previous values before each change.

On-premises SharePoint Server

SharePoint Server remains common for regulated or legacy workloads and is internet-facing more often than it should be. In July 2025 attackers exploited a chain known as ToolShell: CVE-2025-49706 (spoofing) and CVE-2025-49704 (code injection), followed by the patch bypasses CVE-2025-53771 and CVE-2025-53770. CVE-2025-53770, CVE-2025-49704 and CVE-2025-49706 are in the CISA Known Exploited Vulnerabilities catalog, which records known ransomware use. CISA advised enabling AMSI integration, running antivirus and EDR on SharePoint servers, applying Microsoft's updates, rotating ASP.NET machine keys before and after patching, restarting IIS after removing malicious modules, and disconnecting public-facing servers that could not use AMSI. The ToolShell SharePoint exploitation shows why: stolen machine keys let attackers return after patching. Treat machine keys as non-human credentials, monitor for web shells (T1505.003) and remove versions that are out of support. SharePoint Server 2013 and earlier are end of life.

Common misconfigurations

• Anyone as the default link: every share becomes a public URL that bypasses device policy and is easy to forward.
• EEEU on large sites: "Everyone except external users" added as visitors, often on intranet or project sites, exposing content to the whole organisation and to AI search.
• Guests that never expire: project guests retain access years later because no expiry or review is set.
• Tenant-wide app permissions: migration or backup tools left with Sites.FullControl.All and a long-lived secret after the project ends.
• Labels assumed to protect files: a site labelled Confidential while its documents remain unlabelled and unencrypted.
• Exposed on-premises servers: internet-facing SharePoint Server patched but with unrotated machine keys, as in ToolShell.

Framework mapping

Practitioner checklist

• Set the default sharing link to Specific people and restrict or expire Anyone links.
• Set guest access expiry and stop guests resharing items they do not own.
• Make SharePoint Administrator an eligible, approved role and keep Global Administrator for emergencies.
• Move integrations to Sites.Selected and remove unused tenant-wide app permissions and secrets.
• Publish container sensitivity labels and require them for new sites; enable file labelling separately.
• Apply restricted access control and block download to the highest-risk sites.
• Limit unmanaged devices to web-only access and block legacy authentication.
• Alert on Anyone links on sensitive sites, admin self-grants and download spikes.
• Run DLP in simulation before enforcement on SharePoint and OneDrive.
• Patch on-premises SharePoint Server, rotate machine keys and remove internet exposure.

Standards and references

• Microsoft Learn: Manage sharing settings for SharePoint and OneDrive
• Microsoft Learn: Restrict SharePoint site access with Microsoft 365 groups and Entra security groups
• Microsoft Learn: Use sensitivity labels to protect content in Microsoft Teams, Microsoft 365 groups, and SharePoint sites
• Microsoft Learn: SharePoint Advanced Management overview
• Microsoft Learn: Control access from unmanaged devices
• Microsoft Learn: Overview of Selected permissions in OneDrive and SharePoint
• Microsoft Learn: Use sharing auditing in the audit log
• CISA: Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities

Related NHI Mgmt Group resources: Microsoft 365 Security Guide · Secure File Sharing Guide · Microsoft 365 Copilot Security Deep Dive · Entra ID Applications and Consent Guide