Comprehensive guide to Strapi's powerful role-based access control (RBAC) system for both Admin Panel users and API end users.
Understanding Strapi's Permission Architecture
Two Permission Systems
Strapi has two distinct permission systems:
1. Admin Panel Permissions (Content Creators):
- Controls access to Strapi Admin Panel
- Manages content creation/editing
- System administration
- This guide's primary focus
2. Users & Permissions Plugin (End Users):
- Controls API access for frontend users
- Public/authenticated routes
- Custom application roles
- Mobile app users
Permission Architecture
├── Admin Panel Roles (Content Team)
│ ├── Super Admin
│ ├── Editor
│ ├── Author
│ └── Custom Roles
└── API Roles (End Users)
├── Public
├── Authenticated
└── Custom Roles
Admin Panel Roles
Default Admin Roles
Strapi provides three default admin roles:
Super Admin
Complete system access:
Permissions:
- ✓ Full access to all content types
- ✓ Create/read/update/delete all content
- ✓ Manage users and roles
- ✓ Configure plugins
- ✓ Manage settings
- ✓ Access database
- ✓ Deploy and configure
- ✓ View logs and metrics
- ✓ All admin panel features
Use cases:
- System administrators
- Technical leads
- DevOps engineers
- Site owners
Security note: Limit to 2-3 trusted individuals.
Cannot restrict: Super Admin has unrestricted access.
Editor
Content management focus:
Permissions (default, customizable):
- ✓ Create/read/update content
- ✓ Delete own content
- ✓ Publish/unpublish content
- ✓ Upload media
- ✓ Manage content types
- ✗ Cannot manage users
- ✗ Cannot configure plugins
- ✗ Cannot change settings
- ✗ Limited access to system features
Use cases:
- Content managers
- Editorial leads
- Marketing managers
- Senior content creators
Best for: Team members who manage content without needing system access.
Author
Content creation focus:
Permissions (default, customizable):
- ✓ Create content
- ✓ Read all content
- ✓ Edit own content
- ✓ Delete own content
- ✓ Upload media (own only)
- ✗ Cannot edit others' content
- ✗ Cannot publish (may require approval)
- ✗ Cannot manage settings
- ✗ No user management
Use cases:
- Content writers
- Bloggers
- Junior editors
- Contributors
Best for: Content creators who need review/approval workflow.
Custom Admin Roles
Create custom roles for specific organizational needs:
Creating Custom Role
Via Admin Panel:
Settings → Administration Panel → Roles → Add new role
Step 1: Define Role
- Name: Role identifier (e.g., "SEO Manager")
- Description: Role purpose
Step 2: Configure Permissions
Permission categories:
- Content types: Per-content-type permissions
- Plugins: Plugin-specific access
- Settings: System configuration access
- Media Library: Asset management
- Webhooks: Webhook management
Step 3: Set Granular Permissions
For each content type:
- Create: Can create new entries
- Read: Can view entries
- Update: Can edit entries
- Delete: Can remove entries
- Publish: Can publish/unpublish
Additional options:
- Apply to all fields or specific fields
- Conditions (own content vs. all content)
- Filters and limits
Example: SEO Manager Role
Purpose: Manage SEO fields across content without full editing access
Permissions:
Articles Content Type:
☑ Read (all entries)
☑ Update (SEO fields only)
☐ Create
☐ Delete
SEO Fields:
☑ meta_title
☑ meta_description
☑ slug
☑ canonical_url
Other Fields:
☐ title (read-only)
☐ content (read-only)
Media Library:
☑ Read
☐ Create
☐ Update
☐ Delete
Settings:
☐ All settings disabled
Example: Product Manager Role
Purpose: Manage e-commerce products only
Permissions:
Products Content Type:
☑ Create
☑ Read
☑ Update
☑ Delete
☑ Publish
Categories Content Type:
☑ Read
☑ Update (limited)
Media Library:
☑ Create (product images)
☑ Read
☑ Update
☑ Delete
Other Content Types:
☐ All disabled
Settings:
☐ No access
Permission Granularity
Content Type Permissions
Four CRUD operations:
- Create: Add new entries
- Read: View entries
- Update: Edit existing entries
- Delete: Remove entries
Additional actions: 5. Publish: Make content live 6. Unpublish: Take content offline
Field-Level Permissions
Control access per field:
All fields: Apply permission to all fields Selected fields: Choose specific fields
Example:
Article Content Type:
├── Title (all roles can edit)
├── Content (all roles can edit)
├── SEO Title (SEO Manager only)
├── Internal Notes (Editor and Super Admin only)
└── Published At (Editor and Super Admin only)
Configure:
Role → Content Type → Update → Fields
Select specific fields for update permission
Conditional Permissions
Own vs. All:
- Own content: User can only modify their own entries
- All content: User can modify any entry
Example:
Author Role - Articles:
├── Create: Yes
├── Read: All entries
├── Update: Own entries only
├── Delete: Own entries only
└── Publish: No (requires Editor approval)
Editor Role - Articles:
├── Create: Yes
├── Read: All entries
├── Update: All entries
├── Delete: All entries
└── Publish: Yes
Plugin Permissions
Content-Type Builder
Who can access:
- Super Admin: Full access
- Custom roles: Restrict for safety
Permissions:
- Create content types
- Edit content types
- Delete content types
Security: Limit to developers/admins (structural changes).
Media Library
Permissions:
- Upload: Add new media
- Read: View media
- Update: Edit metadata
- Delete: Remove media
Configuration:
Role → Plugins → Upload
☑ Read
☑ Create (upload)
☐ Update (limited roles)
☐ Delete (limited roles)
Email Plugin
Permissions:
- Configure email settings
- Send emails
- View email templates
Typical access: Super Admin and specific roles only.
API Permissions (Users & Permissions Plugin)
End User Roles
For frontend application users:
Public Role
Unauthenticated access:
- No login required
- Read-only access (typically)
- Limited endpoints
Common permissions:
☑ Articles: Find (list)
☑ Articles: FindOne (single)
☐ Articles: Create
☐ Articles: Update
☐ Articles: Delete
☑ Products: Find
☑ Products: FindOne
☐ Products: Create
Use: Public website content, product listings.
Authenticated Role
Logged-in users:
- Requires authentication
- More permissions than public
- Custom application features
Common permissions:
☑ Comments: Create
☑ Comments: Update (own)
☑ Comments: Delete (own)
☑ Profile: Update (own)
☑ Orders: Create
☑ Orders: Find (own)
Use: User-specific features, user-generated content.
Custom API Roles
Create role for specific user types:
Example: Premium Member Role
Settings → Users & Permissions → Roles → Add role
Name: Premium Member
Permissions:
Articles:
☑ Find
☑ FindOne
☑ Premium-Content: Find (custom route)
Downloads:
☑ Create (download resources)
☑ Find (own downloads)
Public Role:
☐ Premium-Content: Find (restricted from public)
Configuring API Permissions
Via Admin Panel:
Settings → Users & Permissions → Roles → Select Role
For each content type:
- ☑ find - List entries
- ☑ findOne - Get single entry
- ☑ create - Create new entry
- ☑ update - Update entry
- ☑ delete - Delete entry
Custom routes: Enable custom controller actions.
Permission Scenarios
Small Content Team
Setup:
├── Super Admin (1): Technical lead
├── Editor (2): Content managers
└── Author (3): Content writers
Workflow:
- Authors create drafts
- Editors review and publish
- Super Admin maintains system
Marketing Department
Setup:
├── Super Admin (1): IT administrator
├── Marketing Manager (1): Custom role (full content access)
├── Content Creators (5): Author role
├── SEO Specialist (1): Custom role (SEO fields only)
└── Social Media (2): Custom role (blog + social posts)
Custom roles:
- Marketing Manager: Editor-equivalent
- SEO Specialist: SEO fields across content
- Social Media: Blog and social content only
Multi-Brand Organization
Setup per brand:
Brand A Team:
├── Brand A Manager: Custom role (Brand A content only)
└── Brand A Writers: Custom role (Brand A content only)
Brand B Team:
├── Brand B Manager: Custom role (Brand B content only)
└── Brand B Writers: Custom role (Brand B content only)
Super Admins:
└── Can access all brands
Implementation: Use content type filters or separate Strapi instances.
E-commerce Platform
Admin roles:
├── Super Admin: System administration
├── Store Manager: Products, orders, customers
├── Product Manager: Products and categories only
├── Customer Service: Orders and customers (read/update)
└── Content Team: Blog and marketing content
API roles (customer-facing):
├── Public: Browse products
├── Customer: Place orders, view order history
├── Premium Customer: Early access, special pricing
└── Wholesaler: Bulk ordering, custom pricing
Security Best Practices
Principle of Least Privilege
Start minimal:
- ✓ Grant minimum permissions needed
- ✓ Use Author role before Editor
- ✓ Use custom roles for specific needs
- ✗ Don't default to Super Admin
- ✗ Don't grant all permissions "just in case"
Questions to ask:
- What content does user need to manage?
- Should they publish or need approval?
- Do they need settings access?
- Should they see others' content?
Separate Duties
Don't combine:
- Content editing + System administration
- User management + Content creation (unless needed)
- Plugin configuration + General editing
Create specific roles:
- Content-only roles (no settings)
- Settings-only roles (no content)
- Department-specific roles
Regular Audits
Monthly review:
- List all users and roles
- Verify permissions appropriate
- Check for inactive users
- Review custom role usage
- Test permission restrictions
Quarterly audit:
- Full permission review
- Update role definitions
- Verify principle of least privilege
- Document changes
Dangerous Permissions
Limit to Super Admin:
☐ Plugin configuration
☐ User management
☐ Role editing
☐ Settings management
☐ Database access
☐ API token management
For custom roles: Be very selective with these permissions.
Programmatic Permission Management
Create Custom Role via API
// Create custom role
const role = await strapi.admin.services.role.create({
name: 'SEO Manager',
description: 'Manages SEO fields across content types'
});
// Assign permissions
await strapi.admin.services.role.assignPermissions(role.id, {
permissions: [
{
action: 'plugin::content-manager.explorer.read',
subject: 'api::article.article'
},
{
action: 'plugin::content-manager.explorer.update',
subject: 'api::article.article',
fields: ['meta_title', 'meta_description', 'slug']
}
]
});
Check User Permissions
// Check if user has permission
const hasPermission = await strapi.admin.services.permission.canAccess({
userId: user.id,
action: 'plugin::content-manager.explorer.create',
subject: 'api::article.article'
});
if (hasPermission) {
// User can create articles
}
Troubleshooting
User Cannot Access Content
Check:
- User role has read permission for content type
- User is active
- Content is within their scope (own vs. all)
- No conflicting permissions
Solution: Review role permissions, grant read access.
User Can See But Not Edit
Expected: Read permission but not update permission.
To grant edit: Add update permission to role.
User Can Edit But Not Publish
Expected: Author role typically cannot publish.
Solution: Upgrade to Editor role or add publish permission to custom role.
Permissions Not Taking Effect
Solutions:
- Log out and back in
- Clear browser cache
- Restart Strapi server (for role changes)
- Verify permissions saved correctly
Next Steps
- Adding and Removing Users - User management
- Strapi User Management - Overview
- Strapi Documentation - Official docs
Related Resources
Quick Reference
Default Role Comparison
| Feature | Super Admin | Editor | Author |
|---|---|---|---|
| Create content | ✓ | ✓ | ✓ |
| Edit own content | ✓ | ✓ | ✓ |
| Edit all content | ✓ | ✓ | ✗ |
| Delete content | ✓ | Own/All | Own |
| Publish | ✓ | ✓ | ✗ |
| Manage users | ✓ | ✗ | ✗ |
| Configure plugins | ✓ | ✗ | ✗ |
| Change settings | ✓ | ✗ | ✗ |
Permission Actions
CRUD operations:
create- Create new entriesread- View entriesupdate- Edit entriesdelete- Remove entries
Publishing:
publish- Make content liveunpublish- Take offline
Special:
plugin::*- Plugin-specific actionsadmin::*- Admin panel actions