Security in a headless CMS ecosystem involves protecting content authoring, database storage, API distribution, and editorial workflows. Because SCHMA connects directly to customer-owned PostgreSQL databases, security is organized around a clear shared responsibility model.

The SCHMA shared responsibility model

Maintaining high security requires understanding which controls are enforced by SCHMA and which controls are managed by your team:

Database credential protection and network boundaries

When connecting your database to SCHMA in Settings > Database:

• Never use root/superuser credentials: Avoid connecting with the default postgres superuser. Instead, create a dedicated database user (e.g. schma_app) granted access only to the target database and public schema.
• Always enforce SSL mode: Ensure the connection string includes sslmode=require or higher to encrypt all in-transit queries between the CMS API and your database server.
• Restrict networking where possible: If your database provider supports IP allowlisting, ensure SCHMA's egress IPs are permitted while blocking open public access to port 5432.

API key lifecycle: scoping, rotation, and storage

API keys provide programmatic access to your content. Follow strict credential hygiene:

• Enforce least privilege: Use delivery keys for read-only frontend applications. Only create management keys for automated backend pipelines that require write, update, or schema evolution permissions.
• Prevent public repository leaks: Never commit API keys to version control. Add .env and .env.local to .gitignore. If a secret is committed accidentally, immediately revoke and rotate it in SCHMA Studio under Settings > API Keys.
• Rotate production keys periodically: Establish a regular rotation schedule for long-lived integration keys. Create the replacement key first, deploy it to your servers, verify traffic, and delete the legacy key.

Securing webhooks with HMAC signatures

Every outgoing webhook from SCHMA includes a cryptographic signature in the x-schma-signature header. Unverified webhook receivers are vulnerable to spoofing and replay attacks. Always compute the HMAC SHA-256 digest of the raw incoming request body using your webhook secret and verify that it matches the header before triggering cache revalidations.

Workspace access governance and role segmentation

Protect workspace integrity by maintaining tight governance over collaborator roles:

• Audit team members regularly: Review active collaborators under Settings > Team. Remove accounts belonging to former employees or concluded contractor engagements immediately.
• Block disposable email addresses: SCHMA automatically rejects invitations sent to disposable email domains (such as temp-mail or mailinator) to maintain team accountability.
• Scope editor permissions: Apply content-type restrictions (allowedContentTypes) to external contributors to prevent modifications to critical global settings or legal documents.

BYOK AI key storage and data privacy

When using Bring-Your-Own-Key (BYOK) AI features with OpenAI-compatible, Anthropic-compatible, Google AI, OpenRouter, or custom/local LLM endpoints, your provider API keys and credentials are encrypted at rest using industry-standard AES encryption in the SCHMA control plane. Keys are never returned in cleartext to client browsers, and all AI completions execute server-to-server.

Furthermore, because your content lives in your own PostgreSQL database, SCHMA does not use your customer data or content entries to train proprietary foundation models.