Manage Lists lets you read other people's items on a WriteSecurity 2 list, but not edit them — that takes Override List Behaviors

Symptom

A security review asks you to take Full Control away from the group that runs an application ("the maintainers can change permissions and group membership — they don't need that"). You move the group to Edit on the site and on the lists. Everything you try as the site owner still works. Then a maintainer reports that:

• they can no longer fix a record a colleague entered,
• a settings row (created by whoever installed the app) can no longer be saved,
• a lookup table they maintain rejects every change.

The responses are 403 Access is denied, although the maintainer's effective permissions on the list show both Edit Items and Manage Lists.

Cause

WriteSecurity = 2 means "users can modify only items they created". The common wisdom — repeated in many places — is that Manage Lists overrides item-level settings. That is true for reading: a user with Manage Lists sees every item on a ReadSecurity = 2 list. It is not true for writing. Measured on SharePoint Online (11 November 2026), same user, same item, created by another account:

The only difference between the two masks is 0x100 — CancelCheckout, shown in the UI as Override List Behaviors: "Discard or check in a document which is checked out to another user, and change or override settings which allow users to read/edit only their own items". Full Control and Design carry it, Edit and Contribute do not.

Full Control hides the problem: it carries every bit, so testing from an owner or administrator account always succeeds. That is also why the dependency appears only on the day you take Full Control away.

Fix

1. Inventory first. Before narrowing a role, read the item-level settings of every list the group works with:

   GET /_api/web/lists?$select=Title,ReadSecurity,WriteSecurity,HasUniqueRoleAssignments&$top=5000

   Any list with WriteSecurity ≠ 1 where the group must edit other people's items needs Override List Behaviors.

2. Create a custom level instead of falling back to Full Control or Design: Edit (or Contribute) plus CancelCheckout, without Manage Permissions, Manage Web or Enumerate Permissions.

   // Derive from the site's own Edit level so localisation and tenant tweaks don't matter.
   const edit = defs.find(d => d.RoleTypeKind === 6);            // Editor
   const base = Number(edit.BasePermissions.Low);
   // Low can exceed int32, so no bitwise OR – add the bit only if it is missing.
   const low  = Math.floor(base / 0x100) % 2 ? base : base + 0x100;   // + Override List Behaviors
   await post(`${web}/_api/web/roledefinitions`, {
     '@odata.type': '#SP.RoleDefinition',
     Name: 'App maintainers',
     Description: 'Edit + Override List Behaviors, no permission management',
     Order: 160,
     BasePermissions: { '@odata.type': '#SP.BasePermissions', Low: low, High: Number(edit.BasePermissions.High) }
   });

   Read the level back and check the bits you rely on — not its name.

3. Bind it before you remove Full Control, on the site and on every list with unique permissions where the group writes. If lists are hardened by breaking inheritance with a copy of the site's role assignments, binding the level on the site also carries it to lists created later.

4. Test the write as the maintainer, not as the owner: update an item another account created, then read it back.

Notes

• Design also carries Override List Behaviors and would work, but it adds page customisation and theme rights. The custom level is narrower.
• WriteSecurity = 4 ("nobody can modify items") was not measured here. Earlier reports that "Design gets through" are consistent with this finding, because Design carries Override List Behaviors. Don't assume Edit is enough there either — measure it.
• Item-level read (ReadSecurity = 2) is bypassed by Manage Lists alone. See A count over a ReadSecurity 2 list is only the reader's share.
• Related: WriteSecurity 4 ignores Contribute, Item-level permission defaults on provisioned lists.