<p>I review two permission systems before a Strapi launch. Administrator RBAC controls what people can do inside the admin panel. The Users &amp; Permissions feature controls API access for public and authenticated application users. Mixing those systems can leave a public endpoint open while the admin interface looks restricted.</p><p>The <a href="https://docs.strapi.io/cms/features/rbac">Strapi administrator RBAC documentation</a> lists administrator actions such as create, read, update, delete, and publish. The <a href="https://docs.strapi.io/cms/features/users-permissions">Strapi Users &amp; Permissions documentation</a> covers end-user roles. I test both from outside the admin panel.</p>

<h2>Inventory every public request</h2>

<p>I capture the requests made by the public site: method, path, query fields, relation population, and expected response. A page that only reads published articles should not require create, update, or delete access. I remove permissions that no visible route uses.</p><p>I repeat the inventory for previews, forms, and authenticated areas. Preview requests belong behind a protected path. A form usually calls a custom controller or another backend instead of receiving broad create access to a content type.</p>

<h2>Review the Public and Authenticated roles</h2>

<p>I open each end-user role and compare enabled actions with the request inventory. Public access starts empty and gains only the reads required by published pages. Authenticated access is not an administrator shortcut; it applies to application users who hold that role.</p><p>I send direct requests for disabled operations and keep the 401 or 403 response as evidence. Hiding buttons in Next.js does not protect a Strapi endpoint.</p>

<h2>Give editors the work they own</h2>

<p>Administrator roles follow editorial responsibility. Authors may create and manage their own content, editors may review and publish selected types, and a small number of people retain settings access. Strapi's RBAC can restrict actions and fields per content type.</p><p>I review sensitive fields such as internal notes, integration IDs, and SEO controls. Someone who can edit article copy may not need permission to change canonical URLs or delete media.</p>

<h2>Reduce Super Admin use</h2>

<p>The first administrator receives Super Admin access, and Strapi does not let teams narrow that role. I create day-to-day roles and reserve Super Admin for configuration work. Shared administrator accounts make audit and offboarding harder, so each person gets an individual identity.</p><p>I also review API tokens, provider credentials, and old accounts. A role review is incomplete if a forgotten token can still perform the same operation.</p>

<h2>Test unauthorized behavior</h2>

<p>I run requests without a token, with an ordinary application token, and with an editor account. I test missing fields, unpublished records, relation expansion, upload actions, and deletion. The expected denial matters as much as the allowed response.</p><p>For each failure I verify that the response omits private data and the logs avoid credentials. A detailed stack trace should not reach a public caller.</p>

<h2>Keep the permission review repeatable</h2>

<p>I save a table of roles, allowed actions, protected fields, and test requests. Schema or plugin changes trigger another review because new content types and routes can add permissions.</p><ul><li>Public API requests have an owner.</li><li>Unused mutations are disabled.</li><li>Editors have scoped publishing rights.</li><li>Old tokens and accounts are removed.</li><li>Unauthorized tests run outside the admin panel.</li></ul>

<h2>Need help with Strapi?</h2>

<p>Terry Hunt Dev provides <a href="/services/strapi-development">Strapi development</a> and <a href="/services/technical-seo">technical SEO support</a>. Request a launch permission review through the <a href="/contact">contact page</a> without sending tokens or private API URLs.</p>

Use this Strapi roles and permissions checklist to review public API access, administrator RBAC, publishing rights, tokens, and unauthorized requests.

Strapi Roles and Permissions I Check Before Launch

Review Strapi administrator roles and public API permissions separately before a production launch.

<p>A Strapi multi-site setup uses one content platform to support more than one website, brand, region, or audience. The hard part is not adding a <code>site</code> field. The hard part is deciding which content is shared, which content must stay separate, and which editors can publish to each destination.</p>

<h2>Choose the ownership model first</h2>
<p>Before building content types, list the sites and the people responsible for them. Decide whether each site shares legal ownership, infrastructure, release schedules, security requirements, and editorial governance. Separate Strapi instances are often safer when organizations have different administrators, compliance boundaries, or failure tolerance.</p>
<p>A shared instance is a better fit when one team governs the sites, content reuse has clear value, and the organization accepts a shared operational dependency.</p>

<h2>Three practical Strapi multi-site patterns</h2>
<h3>1. Site relation on each entry</h3>
<p>Create a <code>Site</code> collection with fields such as name, key, domain, locale defaults, theme reference, and publishing status. Content entries relate to one or more sites. The frontend requests entries for its site key.</p>
<p>This pattern is explicit and easy to query. It also requires validation so editors cannot publish an entry with missing or conflicting site relationships.</p>

<h3>2. Shared entries with site-specific overrides</h3>
<p>Keep reusable information, such as an organization description or service definition, in a shared entry. Store site-specific title, introduction, call to action, or metadata in related override records. This reduces copied content while preserving local or brand-specific language.</p>
<p>Use overrides only for fields that need them. A content model with an override for every field becomes harder to understand than separate entries.</p>

<h3>3. Separate instances with a shared frontend package</h3>
<p>Some organizations should keep content and permissions in separate Strapi instances while sharing frontend components, schemas, and deployment tooling. This costs more to operate but reduces the effect of one site's publishing or infrastructure problem on the others.</p>

<h2>Example content model</h2>
<pre><code>Site
- name
- key
- primaryDomain
- defaultLocale
- active

Page
- title
- slug
- site (relation)
- pageType
- sections (dynamic zone)
- seo (component)
- publishStart
- publishEnd

GlobalSetting
- site (relation)
- navigation
- footer
- contactDetails
- defaultSeo</code></pre>
<p>Use a composite rule in application logic for <code>site + slug</code>. A slug that is unique in one site may be valid in another, so a global slug rule can block legitimate pages.</p>

<h2>Query by site, not by hostname alone</h2>
<p>The frontend should resolve the current site from controlled configuration, then request content with that site key. Do not trust an arbitrary request hostname to select private content. Preview and webhook endpoints need the same site validation.</p>
<p>Cache keys and revalidation tags should include the site identifier. Otherwise, publishing one site's page can invalidate or overwrite another site's cached response.</p>

<h2>Roles, permissions, and editorial boundaries</h2>
<p>Strapi roles can limit administrative actions, but the exact site-level permission model needs testing against your Strapi edition and workflow. If editors must be isolated from other brands or legal entities, confirm that the required restrictions apply in the admin interface and API. Use separate instances when the boundary cannot be enforced and audited.</p>

<h2>SEO requirements for every site</h2>
<ul>
  <li>Generate canonicals from the correct domain and route.</li>
  <li>Keep XML sitemaps separate by hostname.</li>
  <li>Store site-specific titles, descriptions, social images, and robots directives.</li>
  <li>Use structured data that names the correct organization and visible service area.</li>
  <li>Prevent preview, duplicate-domain, and inactive-site URLs from being indexed.</li>
</ul>
<p>Shared content does not mean every site should publish the same page. Each site needs a reason for the page and enough distinct information to serve its audience.</p>

<h2>Deployment and recovery planning</h2>
<p>A shared Strapi instance creates a shared dependency. Review database backups, uploaded media, environment separation, migrations, restore testing, rate limits, monitoring, and the effect of a failed deployment on every site. Record how each frontend behaves if the CMS is unavailable.</p>

<h2>Questions to answer before building</h2>
<ul>
  <li>Which content is shared, localized, or owned by one site?</li>
  <li>Can an editor see or change another site's content?</li>
  <li>Who approves global changes?</li>
  <li>How are domains, redirects, previews, and sitemaps generated?</li>
  <li>Can one site deploy or recover without the others?</li>
</ul>
<p>A short architecture review can answer these questions before the content model hardens around the wrong ownership assumptions. See <a href="/services/strapi-development">Strapi development services</a> for implementation help and the <a href="/portfolio/railway-and-strapi-projects">Strapi and Railway portfolio</a> for related project context.</p>

Plan a Strapi multi-site CMS with site relations, shared content, permissions, routing, SEO controls, cache isolation, deployment, and recovery.

Permissions Resources & Benchmarks

Strapi Roles and Permissions I Check Before Launch

How to Structure Strapi for Multiple Websites

Need hands-on help with Permissions?