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_previewRichText field option defaults totrue. - 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-originreferrer policy is automatically set. - Simplified CSP - No
unsafe-evalorunsafe-inlineneeded inscript-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
- Dependency security - Constant updates, Dependabot alerts, and
pnpm auditprevent vulnerabilities. We use versioncooldownandminimumReleaseAgeto protect against supply chain attacks. - Transparent releases - We use pnpm, Vite, GitHub Actions, and npm package provenance for verifiable, reliable releases.
- Publishing security - Trusted publishing and 2FA enabled.
- Security policy - Published security policy for responsible disclosure.
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_previewoption 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-srchttps://*.githubusercontent.comconnect-srchttps://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-srchttps://gitlab.com https://secure.gravatar.comconnect-srchttps://gitlab.com https://status-api.hostedstatus.com
Gitea/Forgejo
If you’re running a self-hosted instance, use the origin instead.
img-srchttps://gitea.comconnect-srchttps://gitea.com
Map Providers
OpenStreetMap
img-srchttps://*.openstreetmap.orgconnect-srchttps://*.openstreetmap.org
Media Storage Providers
Cloudinary
img-srcor a custom domain if configuredhttps://res.cloudinary.comframe-srchttps://console.cloudinary.com
Uploadcare
img-srcor a custom domain if configuredhttps://*.ucarecd.net https://ucarecdn.comconnect-srchttps://upload.uploadcare.com https://api.uploadcare.com
Stock Photo Providers
Pexels
img-srchttps://images.pexels.comconnect-srchttps://images.pexels.com https://api.pexels.com
Pixabay
img-srchttps://pixabay.comconnect-srchttps://pixabay.com
Unsplash
img-srchttps://images.unsplash.comconnect-srchttps://images.unsplash.com https://api.unsplash.com
AI Integrations
Google Cloud Translation
connect-srchttps://translation.googleapis.com
Google Gemini
connect-srchttps://generativelanguage.googleapis.com
Anthropic
connect-srchttps://api.anthropic.com
OpenAI
connect-srchttps://api.openai.com
Video Embeds
YouTube
frame-srchttps://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-srchttps://api.cloudflare.com
Netlify
connect-srchttps://api.netlify.com
Vercel
connect-srchttps://api.vercel.com