SharePoint Visitors Can Edit Files Despite Read Permission: What Site Owners Should Check

You set a SharePoint site member group to Read permission, but users in that group can still edit files. This problem occurs because SharePoint has multiple permission layers that override the site-level Read setting. The most common cause is a broken permission inheritance on a document library, folder, or individual file that grants Edit or Contribute rights to the same group or a broader group like Everyone except external users. This article explains exactly where to check and how to fix the four permission layers that allow visitors to edit files despite a Read permission.

Why SharePoint Visitors Can Edit Files Despite Read Permission

SharePoint permission evaluation is additive. The effective permission a user has on a file is the sum of all permissions they receive from site groups, library-level permissions, folder-level permissions, file-level permissions, and sharing links. A Read permission at the site level does not block edit access granted at a lower level. This means a user in the Visitors group (Read) can edit a file if the library, folder, or file itself has unique permissions that include that user or a group they belong to.

Broken Permission Inheritance

When a library, folder, or file stops inheriting permissions from its parent, it gets its own Access Control List (ACL). If that ACL includes the Visitors group with Contribute or Edit permission, users in that group can edit files inside that container. This is the most common scenario.

Sharing Links with Edit Permission

A site owner or member can create a sharing link set to Edit and send it to anyone, including users in the Visitors group. If the link type is Anyone (anonymous), anyone with the link can edit the file. If the link type is People in your organization, all authenticated users in the tenant can edit. These links bypass site-level Read permissions entirely.

Microsoft 365 Group Membership

Group-connected team sites have a hidden Microsoft 365 Group. If a user is added as a member of that group (not the SharePoint Visitors group), they get Edit access to the site through the group’s default SharePoint permission level. The SharePoint Visitors group and the Microsoft 365 Group are separate. A user can be in the Visitors group (Read) but also be a member of the Microsoft 365 Group (Edit).

App or Service Principal Permissions

Power Automate flows, Power Apps, or third-party applications can be granted SharePoint permissions through Azure AD app registrations. If an app has Sites.ReadWrite.All or Sites.FullControl.All, it can edit files on behalf of any user, including visitors. The user sees the edit capability in the browser because the app’s permission is applied to the user’s session.

Steps to Check and Fix Each Permission Layer

Check Broken Inheritance on Libraries, Folders, and Files

1. Navigate to the site where the problem occurs
   Open the SharePoint site in your browser. Go to the document library that contains the editable files.
2. Check library permission inheritance
   Select the library. Click the gear icon (Settings) and choose Library settings. Under Permissions and Management, click Permissions for this document library. If the ribbon shows a button labeled Stop Inheriting Permissions, the library uses unique permissions. Click that button to see the current ACL. Remove any groups that have Edit or Contribute permission if they should only have Read.
3. Check folder and file inheritance
   Navigate to a folder or file that visitors can edit. Right-click the item and select Manage access. Under Advanced settings, click Stop Inheriting Permissions. Review the list of users and groups. Remove any entries that grant Edit or Contribute to the Visitors group or to users who should have Read only.
4. Restore inheritance if appropriate
   If the unique permissions are not needed, click Delete Unique Permissions on the ribbon. This restores inheritance from the parent site. All users will then have the site-level Read permission.

Check and Restrict Sharing Links

1. Open the file or folder that visitors can edit
   Select the file or folder. Click the Share button in the toolbar.
2. Review existing sharing links
   In the Share dialog, click the link settings dropdown. Look for any link that shows Can edit. If the link type is Anyone with the link, click the gear icon next to the link and select Remove link.
3. Disable Anyone links at the site level
   Go to Site settings > Site permissions. Click Sharing settings. Under Sharing, set the link type to Only people in your organization or Specific people. Uncheck Allow editing. This prevents creation of anonymous edit links.
4. Disable Anyone links at the tenant level
   Open SharePoint admin center > Policies > Sharing. Under External sharing, set SharePoint and OneDrive to New and existing guests or Only people in your organization. Uncheck Allow guests to share items they don’t own. This is a tenant-wide control.

Check Microsoft 365 Group Membership

1. Open the SharePoint site and go to Site permissions
   Click the gear icon and select Site permissions. Under Microsoft 365 Group, click the group name.
2. Review group members
   In the Microsoft 365 Group page, click Members. Look for users who are also in the SharePoint Visitors group. If a user is listed here, they have Edit access through the group. Remove them from the group if they should only have Read access.
3. Change the group’s SharePoint permission level
   If you want the Microsoft 365 Group to have Read only, you cannot change it directly. You must create a separate SharePoint group with Read permission and add users there instead. Then remove users from the Microsoft 365 Group.

Check App Permissions

1. Open SharePoint admin center
   Go to admin.microsoft.com > SharePoint admin center. Under Advanced, click API access.
2. Review approved apps
   Look for any app that has Sites.ReadWrite.All or Sites.FullControl.All permission. Click the app name to see details. If the app is not needed, click Remove permission.
3. Check Power Automate flows
   Go to flow.microsoft.com. Select Solutions > Default Solution. Look for flows that use SharePoint connectors with Edit permission. Remove or modify the flow to use Read-only permissions.

If SharePoint Still Has Issues After the Main Fix

Users Can Edit Files After You Removed Unique Permissions

If you restored inheritance but users still edit, check whether the site is group-connected and the user is a member of the Microsoft 365 Group. Also check if the user has a sharing link that was created before you changed permissions. Existing links remain valid until they expire or are deleted.

Visitors Can Edit Files in a Subsite

A subsite can have its own permission settings. If the subsite inherits from the parent site, the parent’s Read permission applies. But if the subsite has unique permissions, it can grant Edit to the Visitors group. Check the subsite’s permission settings and either restore inheritance or remove the Edit permission.

Users Can Edit Files Through a Power App

A Power App might use a connection reference that has Edit permission. Go to make.powerapps.com. Select the app and click Edit. Under Data sources, review the SharePoint connection. If the connection uses a service account with Edit permission, users of the app can edit files through the app even if their own account has Read only. Change the connection to use a user-delegated permission or a service account with Read only.

Site Permission Levels vs Microsoft 365 Group Permissions

Item	SharePoint Site Group	Microsoft 365 Group
Permission scope	Only the SharePoint site	All group-connected resources (site, Planner, Teams, etc.)
Default permission level	Read, Edit, or Full Control	Edit on the site (Members), Read on the site (Guests)
How users are added	Manually via Site permissions	Manually via Microsoft 365 admin center or SharePoint
Can be changed to Read only	Yes, by editing the group’s permission level	No, the group’s site permission is fixed. Users must be moved to a SharePoint group instead

To prevent this issue, always check both the SharePoint Visitors group and the Microsoft 365 Group membership when you assign Read permission. Use SharePoint admin center > Active sites > select the site > Permissions to see a consolidated view of all permission levels. If you need to restrict a user to Read only, remove them from the Microsoft 365 Group and add them only to the SharePoint Visitors group.

After making these changes, test with a user who has only Read permission. Open the site in a private browser window, sign in as that user, and try to edit a file. If the edit option is still available, recheck the library and folder permissions for any remaining unique permissions.