Security

createCMS is defensive by default — every endpoint runs through your auth, the scope resolver, and hooks — but a CMS sits between the public internet and your database, so some defenses only make sense at the edge of your deployment. This page lists what the framework does not do for you, and how to close each gap.

Authentication is required

createCMS throws at construction if you don't pass an authMiddleware. There is no implicit "allow everything" default — auth is an explicit decision, not an omission.

Pass a real middleware that resolves the user and permissions from the request:

import { createCMS } from '@createcms/core';

export const cms = createCMS({
  db,
  collections,
  media,
  // Resolve the user/permissions per request (from a cookie, token, etc.).
  authMiddleware: async (ctx) => {
    const session = await getSession(ctx);
    return { userId: session.userId };
  },
});

Or, to run public/dev with no auth, opt out explicitly with allowAnonymous():

import { createCMS, allowAnonymous } from '@createcms/core';

export const cms = createCMS({
  db,
  collections,
  media,
  // Every request runs unauthenticated. This authorizes writes too, so use
  // it only for a public-read demo or local dev — never a production app
  // that accepts mutations.
  authMiddleware: allowAnonymous(),
});

Media privacy

Uploaded objects are stored public-read in your bucket. The status: 'private' flag is enforced by the CMS gate (GET /media/asset/{id} returns ASSET_ACCESS_DENIED for a private asset) — not by the object store. Anyone who knows or guesses the direct ${publicUrl}/${objectKey} URL can fetch a "private" object straight from the bucket, bypassing the gate.

So private is a "should this be shown" flag, not a hard-privacy boundary. Do not put secrets or regulated data behind it; if bytes must be truly access-controlled, keep them out of public object storage entirely. See Media → Private vs public.

Serve assets from a cross-origin host. Point publicUrl at a domain that is not your app's origin (a dedicated asset/CDN host), so an uploaded file can never execute as same-origin against your app — it can't read your app's cookies or ride a logged-in session. This is defense in depth: even a malicious upload that slips past validation runs in an origin with nothing to steal.

const media = {
  provider: 'cloudflare',
  // …bucket + credentials…
  // A separate host, not https://your-app.com — so assets are cross-origin.
  publicUrl: 'https://assets.example-cdn.net',
};

Rate limiting

The framework does not throttle anything on its own. The public read paths — getPublishedContent, the /media/asset/{id} gate — and every mutation run as fast as the caller sends them. Throttling is a deployment-layer concern: put a CDN, WAF, or reverse proxy in front and rate-limit there.

If you want it in-process instead, use the plugin onRequest seam — it runs before routing, so you can 429 a request before any DB work. The A/B plugin's public event ingest uses exactly this, exposed as an option:

import { abTest } from '@createcms/core/plugins/ab-test';

abTest({
  rateLimit: {
    limit: 60,
    windowMs: 60_000,
    // store: myDistributedStore,  // see the caveats below
  },
});

To rate-limit your own endpoints, build the same seam into a plugin — see onRequest in the plugin guide, and abTest({ rateLimit }) for the reference implementation.

CSRF

The realtime SSE route and every mutation authenticate through your authMiddleware. If that middleware reads cookies, the browser attaches them automatically on cross-site requests — so a cookie-session app is CSRF-exposed unless you defend it:

• Set your session cookie SameSite=Strict (or Lax), and
• verify an Origin/Referer header or a CSRF token inside your authMiddleware, rejecting requests that fail the check.

Token-in-header auth (e.g. an Authorization: Bearer … header your client sets explicitly) is not CSRF-exposed — browsers don't auto-attach custom headers on cross-site requests, so a forged request can't carry the credential.

Multi-tenant

With the multi-tenant plugin, resolveTenantSlug is session-only by default: it returns the tenant from your session fallback and ignores any tenantSlug in the request body or query. That default is what keeps one tenant from reading or writing another's data. See Multi-tenant → Usage for the resolveTenantSlug API and its allowRequestOverride opt-in.