Security

Security is a top priority for Sveltia CMS so that you can manage your content with confidence. This document outlines the security features and practices of Sveltia CMS. It also 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: HTML sanitation is performed using the DOMPurify library. 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 referrer policy: The same-origin policy is automatically set globally in the app. An exception is OpenStreetMap integration for the Map field type, which requires strict-origin to load tiles properly.
• Link rel attributes: All external links in the admin interface have rel="noopener noreferrer" to prevent tabnabbing and protect user privacy.
• Sandboxed iframes: All iframes in the admin interface are sandboxed with appropriate restrictions to prevent malicious content from executing harmful actions.
• Simplified CSP: No unsafe-eval or unsafe-inline needed in script-src. We provide a CSP builder tool to help users generate a secure policy based on their specific configuration and deployment setup.
• Signed commits: GitHub commits are automatically GPG-signed and verified.
• Signed uploads: Media uploads to Uploadcare are signed using secure API keys.

Security Practices

• AI-assisted coding: Claude and GPT assistants are used to ensure secure coding practices and identify potential vulnerabilities during development.
• Dependency security: Constant full updates with ncu -u && pnpm up, manual and CI-driven pnpm audit, and Dependabot alerts deal with vulnerabilities quickly. pnpm’s minimumReleaseAge option protect against supply chain attacks.
• Transparent releases: We use pnpm, Vite, GitHub Actions, and npm package provenance for verifiable, reliable releases.
• Frequent releases: Regular releases ensure users get the latest security fixes and improvements promptly. Timely dependency updates also reduce the risk of vulnerabilities in third-party packages.
• Publishing security: Trusted publishing and 2FA enabled.
• Responsible disclosure: We publish a security policy and encourage the responsible disclosure of vulnerabilities. We maintain a public list of security advisories to keep users informed about issues and their resolutions. We give credit to security researchers who report vulnerabilities, although we do not offer bounties at this time.
• Swift response: We prioritize security fixes and aim to address vulnerabilities within 12 hours of discovery, regardless of severity. In fact, we fixed the first XSS vulnerability reported to us in just two hours, despite it being low severity with no known exploits.

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 if possible. 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 tool below to generate a CSP header based on your specific configuration and deployment setup. You can copy the generated header and add it to your server configuration or use it in a <meta> tag in your HTML.

Backends

GitHubℹGitLabℹGitea/Forgejoℹ

Media Storage Providers

CloudinaryℹUploadcareℹ

Stock Photo Providers

Lorem PicsumPexelsPixabayUnsplash

AI Integrations

Google Cloud TranslationGoogle GeminiAnthropicDeepSeekMistral AIOpenAI

Map Providers

OpenStreetMap

Video Embeds

YouTube

CI/CD Providers

Cloudflare PagesNetlifyVercel

Merged CSP

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;

Base valueAdded by selected service

Allowing All Image Sources

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://*;

Recommended CSP for Media Libraries

Please refer to the documentation for your specific storage provider for recommended CSP directives, as they typically depend on your configuration (e.g. custom domain vs default endpoint) and may require allowing specific origins for API calls and asset URLs.

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.

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.