403 FORBIDDEN and Access Denied in SharePoint Online and OneDrive

Fix it now

403 means the service knows exactly who you are and will not let you in. Microsoft documents it as access being denied because the caller does not have enough permission, or does not have a required licence – and where Conditional Access applies, as a 403 carrying error=insufficient_claims. 401 is the different problem: no usable identity was presented.

Connect-SPOService -Url https://contoso-admin.sharepoint.com
Get-SPOSite -Identity https://contoso.sharepoint.com/sites/team | Select-Object LockState,StorageQuota,StorageUsageCurrent

1. Read LockState first. NoAccess blocks all traffic and returns 403 unless a redirect URL is configured; ReadOnly refuses writes with a maintenance message. Neither is a permissions problem.
2. Confirm which account the browser is really using. Open a private window, sign in deliberately, and reproduce the error there.
3. On the site, open Settings then Site permissions and run Check Permissions against the failing user. It reports what they have and which group grants it.
4. Narrow the scope: site root, then library, then folder, then file. The level where it starts failing is where inheritance was broken.
5. If only external people are refused, check sharing at both levels – a site can be at the same or a more restrictive setting than the organisation, never a more permissive one.
6. If the user works in the office and fails on a personal device, read the Entra sign-in record; unmanaged-device restrictions have their own Access Denied text.

If the user can do the thing they were trying to do, stop here. If the account is fine and the answer is still no, the next section works through the layers above the permission model.

Why it happens

SharePoint evaluates every request against the permissions that apply at the exact scope you asked for. By default a library inherits from the site and an item inherits from the library, so one decision covers everything. The moment somebody shares a single file or breaks inheritance on one folder, that object gets its own permission set and stops following the site. Weeks later nobody remembers doing it, and Check Permissions at the site level reports access the item does not honour.

Above that sits a second layer that has nothing to do with permissions. Site lock states are set directly: NoAccess blocks all traffic to a site and returns 403 where no redirect URL is configured, ReadOnly makes it read-only with a maintenance message, and neither can be applied to the root site collection. Sharing settings decide whether external people can be granted anything at all, with the documented rule that a site’s setting must be at the same or a more restrictive level than the organisation’s. Device restrictions decide whether a session from a particular device may use the access it holds.

For code and integrations the picture is the same shape with different words. Microsoft’s Graph documentation defines accessDenied as the caller not having permission to perform the action, and states that a 403 can also mean the caller does not have a required licence. An application that authenticates successfully still gets 403 if its granted permissions do not cover the operation, if it was granted specific sites and not this one, or if the tenant blocks the authentication method it is using. The token is valid; the authorisation behind it is not.

Full reference

Which layer is refusing you

The lock states, and what each one does

None of these can be set on the root site collection, and none of them is visible in the permission model. A site owner looking at Site permissions will see nothing wrong, which is exactly why LockState is the first thing to read rather than the last.

401 against 403, in practice

Microsoft defines 401 as required authentication information being missing or not valid for the resource, and 403 as access denied to the requested resource where the caller lacks permission or a required licence. In practice that means 401 sends you to the sign-in: the token is missing, expired, or issued for the wrong audience. 403 sends you to the authorisation: the identity is fine and the answer is still no. Chasing a 403 with more sign-in attempts is the single most common waste of time on this error, and the licence clause is worth remembering too – a 403 can mean the caller is not licensed for what they asked for.

Conditional Access, seen from the API

Where Conditional Access policies apply to a resource, Microsoft documents that the response is an HTTP 403 carrying error=insufficient_claims. That is a useful signal in a log: it separates a policy decision from a permission decision without needing access to the Entra sign-in records. An application that handles it properly can prompt for the additional claims rather than failing outright.

Check Permissions, and what it cannot see

• It is the right tool for the permission layer and reports which group grants what.
• It does not see lock states, sharing settings, retention holds or Conditional Access.
• A user who passes Check Permissions and still gets 403 is being stopped by one of those.
• Run it at the failing scope, not at the site, or you will confirm access the object does not honour.
• Site collection administrators bypass most permission checks but not the layers above the permission model.

Every code this article covers

Confirm the fix worked

1. The affected user reproduces the original action and it now succeeds.
2. Check Permissions at the exact scope that was failing reports the expected permission.
3. Get-SPOSite shows LockState Unlock and storage within the site’s limit.
4. For an application, the failing call returns something other than 403 or accessDenied.

Questions people ask about this