Skip to content

Security: mantisdarling/Cosmic

Security

SECURITY.md

Security Policy

At Cosmic, security and user safety are fundamental priorities. We maintain a proactive posture to ensure data integrity, user privacy, and protection against web vulnerabilities.


πŸ›‘οΈ Supported Versions

We actively release security updates for the following version branch:

Version Branch Supported Notes
main βœ… Yes Production release branch
Prior Releases ❌ No Please upgrade to main

πŸ“© Reporting a Vulnerability

If you discover a security vulnerability or potential issue, please disclose it responsibly.

Responsible Disclosure Process:

  • Email: Send vulnerability reports to security@cosmic-roadmap.com (or contact the maintainer directly via GitHub).
  • Details to Include:
    • Clear description of the vulnerability and potential impact.
    • Detailed step-by-step instructions or proof-of-concept payload to reproduce the issue.
    • Affected routes, files, or API parameters.

Response SLA:

  • Acknowledgement: Within 24 to 48 hours.
  • Assessment & Fix: Critical vulnerabilities will be patched within 7 business days.

⚠️ Notice: Please do not open public GitHub issues for unpatched security vulnerabilities.


πŸ”’ Security Architecture & Controls

Cosmic implements a defense-in-depth security model across all components:

1. Serverless API Proxy Architecture

  • API Key Isolation: All Groq AI requests pass through the serverless route (/api/ai). Third-party API keys are stored in secure server environment variables and are never exposed to client bundles or browser DOM.

2. Strict Input Validation & Schema Enforcement

  • Zod Validation: Every external input, route parameter, slug, and API payload is validated against strict Zod schemas (src/lib/security.ts). Invalid requests are rejected at the edge.

3. Content Sanitization

  • DOMPurify HTML Cleaning: Markdown responses generated by AI or rendered from content collections pass through DOMPurify with strict element allowlists to prevent XSS (Cross-Site Scripting).

4. Security Headers & CSP Policies

  • Content Security Policy (CSP): Applied to enforce strict source origin rules (default-src 'self').
  • Standard Security Headers: Enforces X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and secure Referrer-Policy.

5. Rate Limiting Controls

  • Brute-Force & Abuse Mitigation: Keyed rate-limiting mechanisms prevent automated scraping, credential stuffing, or serverless endpoint abuse.

🎯 In-Scope vs. Out-of-Scope

In-Scope:

  • Cross-Site Scripting (XSS) in roadmap diagrams, search, or drawer interfaces.
  • Serverless API proxy bypass or key leakage.
  • Unauthorized access or data manipulation in progress storage mechanisms.
  • Content Security Policy (CSP) bypasses.

Out-of-Scope:

  • Denial of Service (DoS/DDoS) attacks requiring massive traffic volume.
  • Attacks requiring physical access to an unlocked victim device.
  • Issues related to third-party browser extensions.

There aren't any published security advisories