Silverstripe CMS uses a group-based permission system backed by a relational database. Users belong to one or more Security Groups, each group is assigned Permission Codes (string-based permissions), and content access is further refined with page-level access controls that restrict who can view, edit, or delete specific sections of the site tree. The system is extensible through PHP code, so developers can register custom permission codes and access checks.
Permission model
Silverstripe's access control has three layers:
- Security Groups -- named containers for users. Groups can be nested (a group can have a parent group), creating an inheritance hierarchy. A user's effective permissions are the union of all permissions from all groups they belong to.
- Permission Codes -- string identifiers like
ADMIN,CMS_ACCESS_CMSMain,EDIT_SITECONFIG,VIEW_DRAFT_CONTENT. Each group is assigned one or more codes. Codes are registered by modules and can be added by custom code viaPermission::declare_permissions(). - Page-level access -- each SiteTree page has "Who can view" and "Who can edit" settings that can be set to "Anyone", "Logged-in users", "Only these groups", or "Inherit from parent". This provides content-tree-scoped permissions on top of global permission codes.
Permission checks in code use Permission::check('CODE_NAME') or $member->canEdit() / $member->canView() on DataObjects.
Built-in groups and permission codes
| Group / Code | Access level | Description |
|---|---|---|
Administrators (group) + ADMIN |
Full system access | Bypass all permission checks, manage all settings |
Content Authors (group) + CMS_ACCESS_CMSMain |
CMS page editing | Access to the Pages section, create/edit/publish pages |
CMS_ACCESS_AssetAdmin |
File management | Upload, organize, and delete files in the Files section |
CMS_ACCESS_SecurityAdmin |
User management | Manage users and groups in the Security section |
CMS_ACCESS_ReportAdmin |
Reports access | View reports section (SEO, broken links, etc.) |
CMS_ACCESS_LeftAndMain |
Base CMS access | Required to log into the CMS admin at all |
EDIT_SITECONFIG |
Site settings | Modify global site settings (site name, theme, etc.) |
VIEW_DRAFT_CONTENT |
Preview drafts | View unpublished content on the frontend |
SITETREE_GRANT_ACCESS |
Page access control | Change "Who can view/edit" settings on pages |
Custom permission codes are registered in _config.php or via the providePermissions() method on DataObject classes.
Admin UI paths
| Task | CMS path |
|---|---|
| Manage users | Security section (left sidebar) > Users tab |
| Manage groups | Security section > Groups tab |
| Assign permission codes | Security > Groups > [Group] > Permissions tab |
| Set group roles | Security > Groups > [Group] > Roles tab (if roles module installed) |
| Page-level access | Pages > [Page] > Settings tab > Access section |
| Site configuration | Settings section (left sidebar) |
| Reports | Reports section (left sidebar) |
API access management
- Built-in GraphQL server at
/graphql - Schema defined in YAML config (
app/_graphql/) and auto-generated from DataObject classes - Authentication via session cookie (CMS login) or custom authenticator middleware
- Permissions enforced via
canView(),canEdit(),canCreate(),canDelete()on DataObjects - Each query/mutation respects the authenticated user's group permissions
RESTful API (via restfulserver module):
- Module
silverstripe/restfulserverexposes DataObjects as REST endpoints - CRUD operations at
/api/v1/ClassName/ID - Authentication via HTTP Basic Auth or session
- Access controlled by DataObject permission methods
Custom API endpoints:
- Created via
Controllersubclasses - Manually check permissions with
Permission::check()in action methods - No built-in API key system; implement via custom middleware or token-based auth
Analytics-specific permissions
Silverstripe's analytics access depends on how tracking is implemented:
- Reports section -- the built-in Reports admin lists SEO reports, broken links, and custom reports. Access requires
CMS_ACCESS_ReportAdminpermission. Custom report classes extendingSilverStripe\Reports\Reportappear here automatically. - Google Analytics module (
silverstripe-google-analytics) -- typically adds a SiteConfig field for the tracking ID. Modifying requiresEDIT_SITECONFIGpermission. Only Administrators or users with site settings access can change the tracking code. - Template-level tracking -- if analytics scripts are in
.sstemplates, changes require code deployment (file system access). This provides natural separation from CMS-managed content. - Content blocks with tracking -- if using Elemental or similar block modules, analytics code blocks can be created as page content. Page-level edit permissions control who can modify these blocks.
- Custom analytics dashboard -- build a custom CMS section by extending
LeftAndMain. Register a permission code likeCMS_ACCESS_AnalyticsDashboardand assign it to a dedicated "Analytics" group.
To create an analytics-only user:
- Create an "Analytics" group in Security > Groups
- Assign:
CMS_ACCESS_LeftAndMain(base CMS access) +CMS_ACCESS_ReportAdmin(reports) - Optionally add a custom
VIEW_ANALYTICSpermission if you have a custom analytics section - Do not assign
CMS_ACCESS_CMSMain,CMS_ACCESS_SecurityAdmin, orEDIT_SITECONFIG
Sub-pages
- Roles and Permissions -- permission code reference, group inheritance, and page-level access configuration
- Adding and Removing Users -- creating members, group assignment, and deactivation in the Security admin