Skip to content

Security

Security is a top priority for Sveltia CMS. This document outlines the security features of Sveltia CMS and provides best practices for securing your CMS installation.

Our Approach

Sveltia CMS employs multiple layers of security measures to protect your data and ensure a safe content management experience. Our security approach includes the following features and practices:

Security Features

  • XSS protection - The unpatched XSS vulnerability in Decap CMS does not affect Sveltia CMS. The sanitize_preview RichText field option defaults to true.
  • No proxy required - The local workflow eliminates attack surfaces from compromised dependencies and unauthorized API access.
  • Secure contexts only - HTTPS is required for all site content and CMS configuration.
  • Automatic security headers - The same-origin referrer policy is automatically set.
  • Simplified CSP - No unsafe-eval or unsafe-inline needed in script-src.
  • Signed commits - GitHub commits are automatically GPG-signed and verified.
  • Signed uploads - Media uploads to Uploadcare are signed using secure API keys.

Security Practices

What You Can Do

To protect your Sveltia CMS installation and data, follow these best practices:

  • Keep your Sveltia CMS installation up to date. If you use the CDN version, you’ll always get the latest version unless you specify an exact version number in the URL. If you self-host, regularly check for updates and apply them promptly.
  • Set up PKCE authentication for your Git backend. Sveltia CMS supports quick PAT authentication, but it’s mainly for individual developers and not recommended for multi-user teams, especially when non-technical members are involved.
  • Set up two-factor authentication (2FA) for your Git instance.
  • Keep your Git instance up to date if you’re self-hosting it.
  • Use HTTPS for your site to ensure secure communication between the client and server. All major hosting providers use HTTPS by default. If you self-host, consider using Let’s Encrypt to obtain free TLS certificates. Sveltia CMS doesn’t work on HTTP sites.
  • Set up Content Security Policy (CSP) for your site. See the section below for recommended policies.
  • Do not disable the sanitize_preview option for RichText and Markdown fields unless you fully understand the implications. Disabling this option may expose your site to XSS attacks if untrusted users can edit content.

Setting up Content Security Policy

If your site adopts Content Security Policy (CSP), use the following policy for Sveltia CMS, or some features may not work.

style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
img-src 'self' blob: data:;
media-src blob:;
frame-src blob:;
script-src 'self' https://unpkg.com;
connect-src 'self' blob: data: https://unpkg.com;

Note for Netlify/Decap CMS users

Sveltia CMS does not require the unsafe-eval and unsafe-inline keywords in the script-src CSP directive. Also, the script-src CSP directive is not required for the Cloudinary integration to work, as we implemented it without using their hosted widget script.

Allowing Image URLs

If you have image field(s) and expect that images will be inserted as URLs, you may want to allow any source using a wildcard instead of specifying individual origins:

img-src 'self' blob: data: https://*;

About UNPKG origin

UNPKG is used not only to download the CMS script bundle, but also to check for the latest version and retrieve additional dependencies such as PDF.js and Prism language definitions.

Then, add the following origins depending on your Git backend and enabled integrations.

Backends

GitHub

If you’re running a GitHub Enterprise Server, you’ll also need to add the origin to these directives.

  • img-src
    https://*.githubusercontent.com
  • connect-src
    https://api.github.com https://www.githubstatus.com

GitLab

If you’re running a self-hosted instance, you’ll also need to add the origin to these directives.

  • img-src
    https://gitlab.com https://secure.gravatar.com
  • connect-src
    https://gitlab.com https://status-api.hostedstatus.com

Gitea/Forgejo

If you’re running a self-hosted instance, use the origin instead.

  • img-src
    https://gitea.com
  • connect-src
    https://gitea.com

Map Providers

OpenStreetMap

  • img-src
    https://*.openstreetmap.org
  • connect-src
    https://*.openstreetmap.org

Media Storage Providers

Cloudinary

  • img-src
    https://res.cloudinary.com
    or a custom domain if configured
  • frame-src
    https://console.cloudinary.com

Uploadcare

  • img-src
    https://*.ucarecd.net https://ucarecdn.com
    or a custom domain if configured
  • connect-src
    https://upload.uploadcare.com https://api.uploadcare.com

Stock Photo Providers

Pexels

  • img-src
    https://images.pexels.com
  • connect-src
    https://images.pexels.com https://api.pexels.com

Pixabay

  • img-src
    https://pixabay.com
  • connect-src
    https://pixabay.com

Unsplash

  • img-src
    https://images.unsplash.com
  • connect-src
    https://images.unsplash.com https://api.unsplash.com

AI Integrations

Google Cloud Translation

  • connect-src
    https://translation.googleapis.com

Google Gemini

  • connect-src
    https://generativelanguage.googleapis.com

Anthropic

  • connect-src
    https://api.anthropic.com

OpenAI

  • connect-src
    https://api.openai.com

Video Embeds

YouTube

  • frame-src
    https://www.youtube-nocookie.com

CI/CD Providers

If you choose to disable automatic deployments and have configured a webhook URL, you may need to add the origin to the connect-src directive. Here are some examples:

Cloudflare Pages

  • connect-src
    https://api.cloudflare.com

Netlify

  • connect-src
    https://api.netlify.com

Vercel

  • connect-src
    https://api.vercel.com

Released under the MIT License.