SveltyCMS implements enterprise-grade security measures across all system components to protect data, prevent vulnerabilities, and ensure compliance with security standards.

🛡️ Security Overview

SveltyCMS security architecture includes:

• 🔐 4-Layer Defense-in-Depth — Middleware → Dispatcher → Handler → Page Action. Each layer re-validates independently. Fail-closed by default.
• 🔐 Authentication & Authorization - Multi-factor authentication, session management, RBAC
• 🔒 Cryptography - Quantum-resistant password hashing, AES-256 encryption, CSPRNG-only tokens (no Math.random() fallback)
• 🛡️ Widget Security - XSS prevention, injection protection, file validation
• 🔍 Security Monitoring - Real-time audit logging (SHA-256 chained, fire-and-forget — non-blocking on mutations)
• 🚀 Secure Development - Build-time security checks, vulnerability scanning
• ⚡ Enterprise Immunity - Self-healing load shedding, graceful shutdown, SSRF endpoint validation, and pre-compiled pipelines

---

📊 Security Scorecard

Dimension	Weight	Score	Prevents
CVE Track Record	25%	100	0 CVEs — verifiable via NVD, GitHub Advisory DB
Cryptography	15%	100	AES-256-GCM, SHA-256 chain, key rotation, timing-safe
Disclosure & Response	10%	98	security.txt, incident runbook, responsible disclosure program
Auth & Session	20%	99	Argon2id, CSPRNG, __Host- cookies, 2FA, fully tested lockout, email normalization
Input Validation	15%	99	strict CSP, safeFetch (SSRF), DOMPurify, Drizzle, body limit, MIME sniffing, SSRF IPv6 blocking, email normalization
Dependency Hygiene	15%	99	Dependabot weekly, CI audit BLOCKING, override-pinned

Weighted: 25.0 + 15.0 + 9.8 + 19.8 + 14.85 + 14.85 = ~99/100

Self-assessed (July 2026). Gaps: 3rd-party pentest, WebAuthn passkey UI, SSO/OIDC logout audit (when implemented), DOMPurify 3.4.13+ (CVEs mitigated by explicit configs).

July 25, 2026 Hardening: Permission cache instant invalidation. Media bulk delete (4x concurrency). DOMPurify toast configs restricted. Path traversal resolve() prefix checks. Required-fields publish validation (media/relations data-integrity guard).

---

📚 Security Documentation

Authentication & Access Control

• Authentication System - Enterprise-grade authentication with 3-layer caching, automatic session rotation, multi-tenancy, API Keys, Magic Links, Guest Auth, and WebAuthn/Passkeys

• Login Security - IP resolution, rate limiter secrets, OAuth HMAC validation, session/device tracking, password-reset token expiry codes, and accessibility fixes.

• License Gate Inventory - Marketplace license checks, fail-open/fail-closed policy, plugin/widget gate map.

• Access Management - Roles, Granular Permissions, and Website Token management

  • Session management
  • Token-based authentication
  • Password policies
  • Account lockout

• Two-Factor Authentication API - 2FA setup, verification, recovery codes, and backup options

• User Management API - User authentication, registration, profile management, and permissions

• User Token Management API - API token generation, management, and revocation

Cryptography & Encryption

• Cryptography Module - Enterprise-grade cryptography for password hashing and data encryption

  • Argon2id password hashing (quantum-resistant)
  • AES-256-GCM encryption
  • Secure token generation
  • Timing attack prevention

• Quantum Security - Future-proof security measures against quantum computing threats

Widget & Content Security

• Widget Security ⭐ - Comprehensive security measures across all widgets
  • XSS prevention
  • Injection attack protection
  • File upload validation (including SVG sanitization)
  • SSRF prevention (including S3 endpoint validation)
  • IDOR protection
  • Input sanitization
  • Tiptap link protocol hardening

Application Security

• Security Plugin - Build-time plugin preventing accidental exposure of private settings

  • Environment variable protection
  • Secret detection
  • Build-time validation

• Login Error Handling - Secure error handling for authentication flows

  • Rate limiting
  • Timing attack prevention
  • Information disclosure prevention

• Middleware Security Hardening - Real-time security at the protocol layer

  • Content Security Policy: Strictly-scoped CSP (script-src 'self', zero unsafe-inline or unsafe-eval) emitted globally on all pages and API routes — the highest-leverage single-line XSS mitigation in SvelteKit
  • Multi-Tenant Batch Isolation: batch-module.ts rejects coalesced operations containing mixed tenant IDs, preventing cross-tenant data leaks in shared-DB deployments
  • Timing-Safe Auth Cache: Turbo auth cache uses absolute expiry (fixed at SET time, never extended on GET) — prevents attackers from inferring session liveness through TTL reset pattern analysis
  • GraphQL Validation Hardening: Query depth is strictly limited to 8 levels (preventing resource exhaustion), and NoSchemaIntrospectionCustomRule is explicitly enforced in production to block unauthenticated schema enumeration.

Infrastructure Security

• Cloud Storage Implementation - Secure cloud storage integration patterns

  • Signed URLs
  • Access control
  • Encryption at rest

• Database Resilience - Database security and reliability

  • Connection pooling
  • Query timeout protection
  • Injection prevention

---

🔒 Security Features by Category

1. Authentication Security

Features:

• ✅ Argon2id password hashing (125ms+ computational cost)

• ✅ Automatic session rotation every 15 minutes for active users (industry best practice)

• ✅ 3-layer session caching (memory, Redis, database)

• ✅ Two-factor authentication (TOTP)

• ✅ Account lockout after failed attempts

• ✅ Secure password reset with time-limited tokens

• ✅ API token generation with granular permissions

• ✅ Website Tokens with expiration policies and granular access control

• ✅ Internal System Authorization using shared secrets (JWT_SECRET_KEY) for system-to-system calls

• ✅ Cascading Password Change: All other active sessions across all devices immediately invalidated on password change (L0/L1/L2 purge)

• ✅ Session & Device Tracking: User-Agent and IP captured at session creation for auditing; Active Devices API for session management (GET/DELETE /api/user/sessions)

Implementation:

• Password validation with entropy requirements
• Session fixation prevention
• CSRF Protection: Multi-layer origin and referer validation for all mutation requests (POST, PUT, DELETE, PATCH)
• Secure cookie attributes (httpOnly, secure, sameSite: Strict)

Every request to SveltyCMS passes through an enterprise-grade pre-compiled pipeline in hooks.server.ts to ensure maximum security with minimal overhead. The entire chain is wrapped in a Global Security Guard for unified header enforcement.

1. 🛡️ Security Headers: CSP, HSTS, and X-Frame-Options applied first to all responses.
2. 🗜️ Compression: ESM-native streaming compression (Brotli/Gzip).
3. 🧪 Test Isolation: Worker-index based database isolation for CI.
4. 🔥 Dynamic Firewall: Scans for SQLi, XSS, and Command Injection threat patterns.
5. 📉 Load Shedding: Automatically rejects mutations when memory usage > 90%.
6. 🚦 Rate Limiting: Per-IP sliding window token bucket with adaptive cost multipliers (0.8x–2.0x based on system pressure). Returns 429 with Retry-After and X-RateLimit-* headers.
7. 🚧 Setup Guard: Blocks initialization endpoints after the system is live.
8. 🔐 Authentication: Resolves session and enforces tenant isolation.
9. 🛂 Authorization: Granular RBAC and Fail-Closed API dispatching.

3. Data Protection

Features:

• ✅ AES-256-GCM encryption for sensitive data
• ✅ Field-level encryption support
• ✅ SHA-256 checksums for data integrity
• ✅ Encrypted database backups
• ✅ Secure cloud storage with signed URLs

Implementation:

• Encryption at rest and in transit
• Key rotation support
• Secure key storage
• HTTPS enforcement

3. Input Validation & Sanitization

Features:

• ✅ Schema-based validation (Valibot)
• ✅ HTML sanitization (DOMPurify)
• ✅ File upload validation (type, size, extension)
• ✅ Binary MIME sniffing for large file uploads — server-side verifies file signatures against client-declared MIME types (prevents MIME type spoofing)
• ✅ SSRF IPv6 transition address blocking — blocks IPv4-mapped IPv6 (::ffff:), 6to4 (2002:), and Teredo (2001:) patterns in egress guard
• ✅ Email normalization — unified normalizeEmail() utility with Unicode NFC normalization and trimming applied consistently across all auth adapters
• ✅ Path traversal prevention
• ✅ Safe Query Mapping & Parameterization: All JSON/RichText queries are strictly mapped to whitelisted database columns and natively parameterized (via Drizzle ORM) protecting against SQL Injection and blind SQL attacks out-of-the-box.
• ✅ ReDoS prevention (input length limits)
• ✅ NoSQL Injection Protection: MongoDB $where, $function, $expr, and $accumulator operators blocked at mapQuery level in src/utils/security/mongo-sanitize.ts; $regex patterns validated for ReDoS

Implementation:

• Whitelist-based validation
• Multi-layer validation (client + server)
• Content Security Policy
• X-Content-Type-Options header

4. Widget-Specific Security

Features:

• ✅ XSS prevention in RichText and MegaMenu widgets
• ✅ SSRF prevention in RemoteVideo widget
• ✅ IDOR prevention in Relation widget
• ✅ CSS injection prevention in ColorPicker widget
• ✅ Meta tag injection prevention in SEO widget
• ✅ File validation in MediaUpload widget
• ✅ Format validation in Email, PhoneNumber, Currency widgets

Implementation Details: See Widget Security Documentation

6. AI Defensive Layers

Features:

• ✅ AI Bot Detection & Blocking: Proactive User-Agent fingerprinting detects and blocks known AI crawlers (GPTBot, Claude, Perplexity, CommonCrawl, Bytespider, FacebookBot) and reconnaissance tools (Nmap, SQLMap, Nikto, Burp Suite, Zgrab, Masscan, Nessus) before they can map the system surface.

• ✅ Multi-Layer Honeypot Grid: 45+ decoy routes mimicking WordPress, Drupal, Joomla, AWS metadata endpoints, and common config/backup files. Any probe triggers immediate IP blacklisting.

• ✅ Progressive Tarpit: Randomized 5–15 second response delays waste bot resources while legitimate users experience zero latency.

• ✅ Response Poisoning: Bots receive fake JSON payloads (phantom users, false config) designed to corrupt scraper datasets rather than revealing real system information.

• ✅ Silent Tarpit: Honeypot routes return empty 200 OK (Content-Length: 0, text/plain) — no JSON structure or server info leaked.

• ✅ Cross-Origin Isolation Headers: All API responses include Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp, and Cross-Origin-Resource-Policy: same-origin preventing Spectre-style side-channel attacks.

• ✅ AI Crawler Honeypot (Tarpitting): Detects automated reconnaissance bots hitting shadow routes (e.g., /wp-admin, /.env) and traps them in a high-latency “tarpit” while automatically flagging their IP.

• ✅ Draft-by-Default Airgap: A fundamental security boundary for AI agents. Any content created or modified via the Model Context Protocol (MCP) is forcefully saved as draft, requiring a human administrator to manually approve/publish it.

• ✅ Prompt Injection Shielding: Native <user_data> delimiters and strict systemPromptPrefix configurations prevent “Ignore previous instructions” payloads from hijacking AI enrichment workflows.

• ✅ RAG Context Isolation (Ollama): Remote knowledge-base context is moved to the user message role with <rag_context> XML delimiters and control-character stripping, preventing external context from overriding system-level instructions. RAG results are sanitized for hidden control characters before injection.

• ✅ AI Reconnaissance Blinding: The full OpenAPI specification is strictly locked behind administrative authentication, preventing automated agents from mapping the system’s API surface.

7. Access Control

Features:

• ✅ Architectural Immunity to Permission Bloat: SveltyCMS is immune to the “SQL Choking” that plagues platforms like Directus. By pre-calculating route-level RBAC in memory, we resolve permissions in sub-milliseconds without injecting massive, recursive SQL WHERE clauses into every query.

• ✅ Memory Stability (WeakRef Isolation): Unlike traditional architectures that can experience memory leaks and OOM crashes under high concurrency, SveltyCMS uses WeakRef session caching.

• ✅ Self-Healing Load Shedding: Detects high memory pressure and gracefully rejects mutation traffic (503) with compressed error responses to prevent OOM.

• ✅ Graceful Shutdown Instrumentation: Tracks in-flight requests and ensures clean database/cache disconnection on SIGTERM.

• ✅ Batched Ghost Relation Hydration: Eliminates the N+1 query bottleneck. Relational data is hydrated in optimized batches only as it enters the viewport.

• ✅ Fail-Closed API Authorization: All REST API endpoints must be explicitly registered. Unmapped routes are denied by default.

• ✅ Tenant-Based Access Control (TBAC): User roles are dynamically resolved and isolated per tenantId during the authentication handshake.

• ✅ Informative 403 Feedback: The Admin Area natively detects authorization failures and provides granular feedback including the specific required permission.

• ✅ UUIDv4 Primary Keys Out-of-the-box: Protects against Cross-Collection IDOR (Insecure Direct Object Reference) vulnerability collision chains.

• ✅ Defense-in-Depth Handler Checks: System handlers (handleSettingsRoutes, handleSystemMgmtRoutes, handleAutomationRoutes) enforce admin verification.

  Media handlers enforce media:write and media:delete permissions. Page actions use centralized permission guards.

• ✅ Cookie Prefix Hardening: __Host- prefixed session cookies strictly enforced on secure connections; never leaked on insecure connections.

• ✅ Setup Session Cookie Consistency: Setup handler now uses the same __Host- cookie prefix logic as the authentication hook, eliminating the prefix inconsistency between setup and runtime session cookies.

• ✅ Zero-Bias Token Generation: generateRandomToken uses rejection sampling to eliminate the ~3.125% modulo bias, guaranteeing uniform distribution across all characters for session tokens and API keys.

• ✅ Setup Completion Gating: All /api/setup endpoints blocked with 403 after initialization; bootstrap routes redirect to login. Hardened with a deep database check for existing admin users to prevent setup wizard hijacking if config files are deleted.

• ✅ Stateless CSRF Exemption: Excludes Bearer-authenticated API key and Website token requests from CSRF validation, allowing external headless mutations while keeping admin sessions fully protected.

• ✅ Permission-based authorization

• ✅ Multi-tenant isolation

• ✅ Resource-level permissions

• ✅ Admin privilege separation

• ✅ Automated Setup Guard (blocks installation endpoints after initialization)

• ✅ GraphQL DoS Protection: Query depth limited to 7 levels and aliases capped at 15 via securityValidationPlugin envelop plugin

• ✅ Account Lockout: 5 consecutive failed logins lock the account for 15 minutes; enforced in both Auth.authenticate() and AuthNamespace.login()

Implementation:

• Central Dispatcher: Permission checks enforced at the single entry point for all /api/[...path] routes.
• Namespace Fallback: Dynamic resource IDs (e.g., /api/collections/[id]) are authorized via parent namespace permissions (e.g., api:collections).
• Database query filtering by tenant
• Cache key prefixing for isolation
• Tamper-Evident Audit Logging: Immutable, database-backed audit trail for all sensitive operations

6. Monitoring & Auditing

Features:

• ✅ Comprehensive database-backed audit logging
• ✅ Security event tracking (login failures, permission violations)
• ✅ Real-time security dashboards and widgets
• ✅ Audit statistics and anomaly detection
• ✅ Automatic log retention and cleanup policies

Implementation:

• Structured logging with correlation IDs
• Security event aggregation
• Anomaly detection
• Alert thresholds

---

🛡️ No Backdoor Policy

SveltyCMS is designed with a zero-backdoor philosophy. Every testing and benchmarking path is explicitly gated, auditable, and production-impossible — even with full source code access.

🔒 Physical Isolation (Triple-Lock)

To prevent accidental exposure or exploitation of testing features, we employ a “Triple-Lock” system:

1. Environment Gating: Testing and benchmarking code paths are only active when explicit environment variables (TEST_MODE=true, BENCHMARK=true) are set at the OS level — impossible to enable via HTTP requests. In production, these paths return 401 Unauthorized.

2. Cryptographic Handshake: The /api/testing endpoint uses timingSafeEqual() from node:crypto for constant-time secret comparison, preventing timing side-channel attacks. The HyperTurbo hook uses standard comparison gated behind the BENCHMARK=true environment check.

3. Auth Path Exclusion: Authentication paths (/api/auth/login, /api/auth/logout) always use real password verification with full account lockout enforcement. No test bypass exists for login — tests must seed a user via /api/testing and authenticate with real credentials. Audit trails are always populated.

🧪 Secure Testing Approach

Our integration tests authenticate like real users:

1. Setup Phase: Tests use the /api/testing endpoint (strictly guarded by the Triple-Lock) to:

   • Reset the test database
   • Seed default data (roles, themes, settings)
   • Create a test admin user

2. Authentication Phase: Tests must login to get a valid session cookie:

   // Tests login just like real users
   await postAction("login", { email: "admin@test.com", password: "Test123!" });

3. Test Phase: Authenticated requests proceed normally through the security middleware. Every request includes the x-test-worker-index for database isolation and the x-test-secret for the cryptographic handshake.

✅ Why This Matters

• Environment-Gated, Not Stripped: Testing code paths exist in all builds but are unconditionally gated behind OS-level environment variables. An attacker needs server filesystem access to enable them.
• Tests Real Security: Authentication and authorization are tested end-to-end exactly as users experience them.
• Compliance Ready: Audit logs show real user-like behavior, not bypasses.
• No Secrets in Code: Test secrets are generated at runtime and never persisted.

📖 Related Documentation {#related-documentation-compliance}

• Tested Security Features - Comprehensive list of tested security features
• Black-Box Testing - Test architecture and isolated test configurations
• Integration Tests - Running integration tests securely

---

🧪 Security Testing

Test Coverage

SveltyCMS includes comprehensive security testing:

# Encryption and cryptography tests
bun test tests/unit/utils/security.test.ts

# Account lockout and session security tests
bun x vitest run tests/unit/auth/auth-lockout.test.ts

# Middleware security (firewall, rate-limit, auth)
bun test tests/unit/hooks/

# API security tests
bun test tests/integration/api/security.test.ts

Security Test Categories:

• ✅ Encryption & Cryptography (14 tests) - AES-256-GCM, Argon2id, key derivation
• ✅ Account Lockout & Session Security (23 tests) - Block/unblock, timeouts, policies
• ✅ Authentication flows (50+ tests)
• ✅ Authorization checks (40+ tests)
• ✅ Input validation (80+ tests)
• ✅ XSS prevention (30+ tests)
• ✅ Injection prevention (40+ tests)
• ✅ File upload security (20+ tests)

Security Vulnerabilities Fixed

Issue	File	Fix Date
Rate limiting bypass (localhost)	src/hooks/handle-rate-limit.ts	March 2026 (Protected)
Firewall bypass (TEST_MODE)	src/hooks/handle-firewall.ts	March 2026 (Protected)

See Tested Security Features for details.

Penetration Testing

Recommended security testing tools:

• OWASP ZAP - Web application security scanner
• Burp Suite - Security testing platform
• SQLMap - SQL injection testing
• XSStrike - XSS vulnerability scanner

---

🚦 Is Your Setup Secure? (Hardening Checklist)

While the CMS provides built-in tools, a secure production deployment requires proper environmental configuration.

Item	Requirement	Status	Verification
JWT_SECRET_KEY	32+ characters of high entropy.	[ ]	Auth flow
ENCRYPTION_KEY	32+ characters (AES-256-GCM baseline).	[ ]	Data decryption
HTTPS/SSL	CMS should only be served over TLS 1.3.	[ ]	security-headers.test
Database Access	DB must reside on a private VPC/Network.	[ ]	Infrastructure
Admin Password	Enterprise standard (16+ chars, mixed).	[ ]	Auth.validatePassword
Firewall	Enable internal firewall via FIREWALL_ENABLED.	[ ]	firewall.test

| Audit Logs | Retention policy matches compliance (Default 365). | [ ] | AuditLogService |

---

📋 Security Checklist

Application Deployment

• Environment variables secured (no secrets in code) - Tested via config validation
• Content Security Policy configured - tests/unit/hooks/security-headers.test.ts
• Security headers enabled (HSTS, X-Frame-Options, etc.) - tests/unit/hooks/security-headers.test.ts
• Rate limiting configured - tests/unit/hooks/rate-limit.test.ts
• CORS policies defined - tests/unit/hooks/security-headers.test.ts
• HTTPS enabled with valid SSL certificate (infrastructure)
• Database credentials rotated (operational)
• API tokens with minimal required permissions (operational)

User Management

• Adaptive Rate Limiting (Hardware-Aware): Automatically scales request costs based on real-time CPU load and Event Loop lag, preventing resource exhaustion during traffic spikes.
• Password complexity requirements enforced - tests/integration/routes/login/signup.test.ts
• User roles and permissions reviewed - tests/unit/hooks/authorization.test.ts
• 2FA enabled for admin accounts - tests/integration/api/auth-2fa.test.ts
• Default admin account password changed (setup wizard requires this)
• Account lockout policy configured (not fully tested)
• Session timeout configured (not fully tested)
• API access logs monitored (not fully tested)

Data Protection

• Audit logging enabled - tests/integration/api/*
• Sensitive data encrypted at rest - tests/unit/utils/security.test.ts
• Backup encryption enabled (infrastructure)
• Key rotation schedule defined (operational)
• Data retention policies configured (not tested)
• PII handling compliant with regulations (not tested)

Widget Security {#checklist-widget-security}

• All widgets reviewed for security - docs/architecture/security/widget-security.mdx
• Custom widgets follow security guidelines - docs/architecture/security/widget-security.mdx
• File upload restrictions configured - tests/unit/plugins/sandbox.test.ts
• Input validation enabled - tests/unit/hooks/firewall.test.ts
• Output encoding verified - docs/architecture/security/richtext-security.mdx
• Widget permissions configured - RBAC tests

---

🚨 Security Incident Response

Incident Detection

Monitor for:

• Multiple failed login attempts
• Unusual API access patterns
• Permission violation attempts
• File upload anomalies
• SQL injection attempts
• XSS payload detection

Response Procedure

1. Identify - Detect and confirm security incident
2. Contain - Isolate affected systems
3. Investigate - Analyze logs and determine scope
4. Remediate - Fix vulnerabilities
5. Recover - Restore normal operations
6. Document - Record incident details and lessons learned

Reporting

Security issues should be reported to:

• Email: security@sveltycms.org
• GitHub: Private security advisory
• Severity Levels: Critical, High, Medium, Low

---

🔐 Security Best Practices

Development

1. Never commit secrets - Use environment variables
2. Validate all input - Client and server side
3. Sanitize all output - Prevent XSS
4. Use parameterized queries - Prevent SQL injection
5. Implement least privilege - Minimal permissions
6. Log security events - Enable audit trail
7. Keep dependencies updated - Regular security patches

Scaffolding Security Defaults

When a new SveltyCMS project is created via the setup wizard, the following bootstrap values are written to config/private.ts:

• JWT_SECRET_KEY — 32-character CSPRNG-generated signing key
• ENCRYPTION_KEY — 32-character CSPRNG-generated encryption key

All other security settings (password policy, rate limiting, SAML/SSO keys) are seeded into the database and managed via the System Settings UI at /config/system-settings:

• PASSWORD_MIN_LENGTH — default 8, adjustable via Security settings
• RATE_LIMIT_SECRET — auto-generated on first use, managed via Security settings
• SAML/SSO keys — RSA-2048 key pair generated during setup, managed via SAML / Enterprise SSO settings

Review and customize all values before deploying to production.

Deployment

1. Use HTTPS everywhere - Encrypt all traffic
2. Enable security headers - CSP, HSTS, etc.
3. Configure CORS properly - Restrict origins
4. Implement rate limiting - Prevent abuse at both app and edge
5. Place behind a WAF — Cloudflare, AWS WAF, or similar for edge protection
6. Monitor security logs - Real-time alerts
7. Regular security audits - Quarterly reviews, annual pentests
8. Backup encryption - Protect data at rest

Edge Protection Checklist

For production, layer these in front of SveltyCMS:

• Cloudflare / AWS WAF with managed OWASP + bot control rule sets
• DDoS Protection (Cloudflare Magic Transit / AWS Shield)
• IP allowlisting for admin panel access
• Edge rate limiting before origin
• Geo-IP filtering for high-risk regions

Operations

1. Rotate credentials regularly - Passwords, tokens, keys
2. Review permissions - Audit user access
3. Monitor failed logins - Detect brute force
4. Update security policies - Keep current with threats
5. Train users - Security awareness
6. Test disaster recovery - Backup restoration
7. Maintain audit logs - Compliance requirements

---

📊 Compliance

SveltyCMS security features support compliance with:

GDPR (General Data Protection Regulation)

• ✅ Data encryption
• ✅ User consent management
• ✅ Right to erasure
• ✅ Data portability
• ✅ Audit logging
• ✅ Data breach notification

SOC 2 (Service Organization Control)

• ✅ Access controls
• ✅ Audit logging
• ✅ Change management
• ✅ Risk assessment
• ✅ Incident response
• ✅ Monitoring and alerting

OWASP Top 10

• ✅ Injection prevention
• ✅ Broken authentication protection
• ✅ Sensitive data exposure prevention
• ✅ XML external entities (XXE) prevention
• ✅ Broken access control prevention
• ✅ Security misconfiguration prevention
• ✅ XSS prevention
• ✅ Insecure deserialization prevention
• ✅ Using components with known vulnerabilities (dependency scanning)
• ✅ Insufficient logging and monitoring (comprehensive audit logs)

7. Supply Chain Security

Features:

• ✅ Pinned GitHub Actions to specific commit SHAs
• ✅ Enforced frozen lockfiles in CI/CD
• ✅ Automated dependency updates with verification
• ✅ CycloneDX SBOM generation (bun run audit:sbom)

Implementation:

• All GitHub workflows use immutable action references (e.g., actions/checkout@11bd7...) to prevent tag hijacking.
• bun install --frozen-lockfile is enforced in all CI jobs to prevent lockfile poisoning.
• Secure update scripts ensure lockfile integrity during maintenance.
• bun run update regenerates the SBOM after dependency updates; the pre-commit hook also re-syncs sbom.json whenever bun.lock/package.json change. The SBOM (CycloneDX 1.5, SHA-512 hashes) provides a verifiable inventory of every dependency for vulnerability scanners (e.g., Dependency-Track, Grype) and SOC 2 / GDPR Art. 32 compliance.

---

🔗 Related Documentation {#related-documentation-links}

Architecture

• Authentication System
• Cryptography Module
• Security Plugin
• Database Resilience

API Security

• Authentication 2FA API
• User Management API
• User Token Management API

Widget Security {#widget-security-2}

• Widget Security
• Widget Development Guide
• Widget Architecture

Testing

• Database & Authentication Testing
• API Test Coverage
• Widget Test Coverage

---

📞 Security Contact

For security-related questions or to report vulnerabilities:

• Security Email: security@sveltycms.org
• GitHub Security Advisories: Private Reporting
• Bug Bounty: Coming soon

Response Time:

• Critical vulnerabilities: 24 hours
• High severity: 48 hours
• Medium severity: 1 week
• Low severity: 2 weeks

---

Last Updated: June 27, 2026 Security Review Status: ✅ A++ Grade (April 2026 Assessment - AI Hardened) Next Review: Quarterly (July 2026)

---

Related

• Architecture Overview
• Getting Started
• API Reference