About controlling access to sites and site content
In this article
As a site owner, when you create the permission structure for your site or group of sites, you should balance ease of administration with the need to control specific permissions for individual securable objects, such as a site, list, or document. As with any Web site, it is also important to follow the principle of least privilege when authorizing access to the site. That is, you should grant users the fewest possible permissions they require to perform their tasks on the site.
For easiest administration, begin by using the standard SharePoint groups (which are Site name Owners, Site name Members, and Site name Visitors) and assigning permissions at the site level. We recommend that you make most users members of the Site name Visitors or Site name Members SharePoint groups. Do not add every user as a member of the Site name Owners SharePoint group. By default, site members can contribute to the site by adding or removing items or documents, but they cannot change the structure of the site or change site settings or appearance. You can create additional SharePoint groups and permission levels if you need finer control over the actions that your users can take.
If there are particular lists, libraries, folders, list items, or documents that contain sensitive data that must be even more secure, you can use fine-grained permissions to grant permissions to a specific SharePoint group or individual user. Note, however, that managing fine-grained permissions can be a very time-consuming task.
How security elements are assigned to a securable object
You can grant individual users and SharePoint groups specific permissions for a securable object, such as a site, list, library, folder, item, or document. Because it is inefficient to maintain user accounts directly, use SharePoint groups as much as possible to manage users.
The following figure illustrates how users and SharePoint groups are assigned specific permission levels for a site or a securable object in a SharePoint site.
A single user can be directly assigned permission without needing to be a member of a SharePoint group.
A permission assignment is created on a particular securable object. This permission assignment includes a user or SharePoint group and a permission level. Each permission level has a specific set of individual permissions.
You can assign different users and SharePoint groups different permission levels for a specific site, list, library, folder, list item, or document. Individual users or SharePoint groups can have different permission levels for different securable objects.
Anyone with the Manage Permissions permission can can create SharePoint groups and assign permission levels for the site as a whole. Note, however, that they may not be able to add or remove users or domain groups to or from a SharePoint group. Site collection administrators and site owners have this permission, by default.
List or library administrators can specify more or less restrictive permissions for their list or library (or a folder within the list or library) by adding or removing users or SharePoint groups, or changing the permission levels for users or SharePoint groups.
List item or document creators can specify more or less restrictive permissions for an individual item or document by adding or removing users or SharePoint groups, or by changing the permission levels for users or SharePoint groups.
Hierarchy and inheritance
By default, permissions on lists, libraries, folders, items, and documents are inherited from the parent site. However, you can break this inheritance for any securable object at a lower level in the hierarchy by editing the permissions on that securable object (that is, creating a unique permission assignment) . For example, you can edit the permissions for a document library, which breaks the permissions inheritance from the site.
Web sites are themselves a securable object on which permissions can be assigned. You can configure subsites to inherit permissions from a parent site or break the inheritance and create unique permissions for a particular site. Inheriting permissions is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent, that set of permissions is shared.
Owners of subsites that inherit permissions from the parent site can edit the permissions of the parent. Ensure that any changes you make to the permissions on the parent site are appropriate for the parent site and all subsites that inherit those permissions.
The following figure shows a site collection hierarchy with a top-level Web site and subsites that inherit permissions from their parent site as well as a subsite with unique permissions.
In the preceding figure, subsite 1 inherits permissions from the top-level Web site. This means that changes made to SharePoint groups and permission levels on the top-level site also affect subsite 1.
Subsite 2 is also inheriting permissions from its parent (subsite 1). However, because subsite 1 is also inheriting permissions from its parent, changes made to SharePoint groups and permission levels on the top-level site affect both subsite 1 and subsite 2. This is because you cannot manage permissions on a subsite that is inheriting permissions. Instead, you either manage the permissions of the parent (which is the top-level Web site for subsite 1 and subsite 2) or you can break the inheritance and create unique permissions.
Notice that subsite 3 has unique permissions. This means that it does not inherit permissions from its parent site. Therefore, any changes made to the permission levels and SharePoint groups on subsite 3 do not affect its parent site. Because subsite 4 is inheriting permissions from subsite 3, any changes to permission levels or SharePoint groups on subsite 3 affect both sites.
Each site contains additional securable objects that have a particular position in the site hierarchy, as shown in the following figure:
Lower-level securable objects automatically inherit permissions from their parent. For example, a list or library inherits permissions from the site, and list items and documents inherit permissions from the list, library, or folder that contains them. You can break this inheritance at any point in the hierarchy and assign unique permissions. When you break the inheritance from the parent, the securable object from which you broke the inheritance receives a copy of the parent's permissions. You can then edit those permissions to be unique — meaning that any changes you make to the permissions on that securable object do not affect the parent.
Plan for permission inheritance
It is easiest to manage permissions at the site level, whenever possible. This means you should create your site hierarchy in a way that allows you to assign permissions to sites that are appropriate for all securable objects within the site, such as lists, libraries, folders, documents, and items. Although you can assign unique permissions on any securable object in the site hierarchy, to do so is more cumbersome than inheriting permissions. When planning SharePoint sites you will need to evaluate both your organization's security requirements and the complexity of managing unique permissions on multiple securable objects.
Managing permissions becomes more difficult when some lists or libraries within a site have fine-grained permissions applied, and when some sites have a range of subsites with both unique permissions and inherited permissions. Whenever possible, try to set up sites, subsites, lists, and libraries so that they can inherit most permissions. If necessary, put sensitive data into separate subsites, lists, or libraries.
For example, it is much easier to manage permissions using a hierarchy like the one shown in the following example, than it would be to mix sensitive and non-sensitive data in the same sites, lists, and libraries.
Site A Group home page
List A Non-sensitive data (inherits permissions from Site A)
Document Library A Non-sensitive data (inherits permissions from Site A)
Subsite B Sensitive data (unique permissions)
List B Sensitive data (inherits permissions from Subsite B)
Document Library B Sensitive data (inherits permissions from Subsite B)
Notice that the list and library in Site A contain non-sensitive data and Subsite B was created below Site A to contain a list and library for storing sensitive data. In this scenario, you can assign permissions to Site A that are appropriate to List A and Document Library A and create unique permissions on Subsite B which are appropriate for List B and Document Library B.