Sharepoint Rest APIs does not work without FullControl permissions

Hi @Moheb Mithani

You are encountering two different authorization behaviors: ordinary SharePoint content APIs and SharePoint security or tenant-administration APIs. The short answer is that SharePoint REST does not universally require Sites.FullControl.All, but the specific permission-management and tenant-admin endpoints you are calling can require it in application-only scenarios.

1. Does SharePoint REST require Sites.FullControl.All?

SharePoint REST API does not require Sites.FullControl.All for every operation. If an application only needs to read ordinary content such as sites, lists, list items, files, or folders, Sites.Read.All may be sufficient. If you want to restrict the application to specific sites, you can use Sites.Selected and grant the application the read role on each required site.

However, the endpoints you are using do not all belong to the same category. An endpoint that retrieves a list item, such as:GET /_api/web/lists/GetById('{listId}')/items({itemId})is an ordinary content-reading operation. Therefore, Sites.Read.All, or Sites.Selected combined with a site-specific read grant, will normally be sufficient.

In contrast, the roleassignments endpoints retrieve permission configuration, while the SPO.Tenant endpoint is a tenant-administration API. These operations can require more privileged permissions than ordinary content retrieval.

Ref: SharePoint admin APIs authentication and authorization

2. Why is Read insufficient when you are only retrieving role assignments?

The key distinction is between:

1. Reading the content of a site.
2. Reading the security configuration protecting that content.

SharePoint treats RoleAssignments, RoleDefinitionBindings, unique permission scopes, and inheritance information as elements of its authorization system rather than ordinary content. A role assignment associates a principal with one or more role definitions on a securable object, such as a web, list, folder, or item.

This means: GET /_api/web/lists/GetById('{listId}')/items({itemId})is a content read, whileGET /_api/web/lists/GetById('{listId}')/items({itemId})/roleassignmentsis an ACL or security-descriptor read. The requested HTTP operation might be GET, but the returned information describes:

• Which users and groups have access
• Which role definitions are assigned
• Whether the object has unique permissions
• How access is inherited
• Potentially, which identities have privileged access

SharePoint therefore does not map every HTTP GET operation to the Sites.Read.All permission. Authorization is based on the protected operation and resource, not merely the HTTP verb.

The same distinction exists in Microsoft Graph. Even Graph’s site-level permissions listing endpoint:GET /sites/{site-id}/permissionsdocuments Sites.FullControl.All as its least-privileged delegated and application permission. This is useful official evidence that Microsoft intentionally classifies permission enumeration as a highly privileged operation, even though it is read-only.

Ref: List permissions

Microsoft does not currently provide a comprehensive public endpoint-by-endpoint permission table for every legacy SharePoint REST route under /_api. Consequently, the requirement for /_api/.../roleassignments is less clearly documented than the requirement for SharePoint admin APIs.

Nevertheless, the observable behavior is consistent with Microsoft’s documented authorization model:

• Content enumeration can use Read.
• Permission enumeration is treated as privileged.
• Tenant admin APIs require Full Control for app-only access.
• Permission modifications, including breaking inheritance or adding role assignments, require permission-management rights. Microsoft’s REST example for setting custom permissions explicitly requires Full Control add-in permission at the web scope.

Ref: Set custom permissions on a list by using the REST interface

3. Does Sites.Selected still require Full Control on the selected site?

No, not necessarily. This is the key correction to your understanding.Sites.Selected separates authorization into two dimensions:

1. Which resources the application can access
2. What role the application has on those resources

After granting Sites.Selected to the application in Entra ID, the application initially has access to no sites. It must then receive an explicit permission assignment for each selected site. Microsoft documents this as a multi-step model consisting of Entra consent, a resource-specific assignment, and a token containing the Selected scope. The site-specific role does not always need to be fullcontrol. Depending on the operation, the assignment can use:read write manage fullcontrol

Microsoft’s SharePoint guidance explicitly describes resource-specific consent as supporting read, write, manage, or full-control application-only access to selected site collections.

For example:

POST https://graph.microsoft.com/v1.0/sites/{site-id}/permissions
Content-Type: application/json
{
 "roles": ["read"],
 "grantedToIdentities": [
 {
 "application": {
 "id": "{target-app-client-id}",
 "displayName": "Role Assignment Reader"
 }
 }
 ]
}

However, there is an important practical point for your scenario:

If the SharePoint REST roleassignments endpoint requires Full Control, giving the application Sites.Selected plus a read site grant will not bypass that requirement.

In that case, the valid least-broad configuration is:

SharePoint application permission: Sites.Selected
Selected site assignment: fullcontrol

That is still substantially safer than:

SharePoint application permission: Sites.FullControl.All

because the first configuration limits Full Control to specifically assigned sites, while the second applies across all site collections in the tenant.

4. What permission should you configure for your exact endpoints?

A. Tenant settings and tenant site administration

GET https://contoso-admin.sharepoint.com/_api/SPO.Tenant/sites

Use: SharePoint API, Application permission, Sites.FullControl.All

Sites.Selected is not an appropriate replacement for tenant-wide SharePoint administration because the selected grant is scoped to a site collection, while SPO.Tenant operates at the tenant administration level. Microsoft officially documents Sites.FullControl.All for SharePoint admin APIs called without a signed-in user.

B. Ordinary content retrieval

GET /_api/web/lists/GetById('{listId}')/items({itemId})

Use one of: Sites.Read.All or Sites.Selected + read grant on the target site if you do not want tenant-wide read access.

I hope this information helps.