Security Policy

Last updated: November 2026

Our Security Commitment

OmniColor takes the security of our site and the privacy of our users seriously. This page describes the security measures we have implemented, the principles we follow, and how you can report security issues.

Our security posture is inherently strong because of our architecture: OmniColor is a static site with no backend server, no database, and no user accounts. This eliminates entire categories of vulnerabilities that affect dynamic web applications.

Architecture Advantages

By design, OmniColor avoids the most common web security risks:

  • No backend server: No server-side code that could have vulnerabilities.
  • No database: No SQL injection risk, no data storage to breach.
  • No user accounts: No passwords, no authentication vulnerabilities, no session hijacking.
  • No file uploads to servers: All image processing happens in the browser.
  • No user-generated content: No XSS injection via comments or profiles.
  • Static HTML/CSS/JS only: Served identically to every user.

Encryption

  • HTTPS everywhere: All connections use TLS 1.2 or 1.3.
  • HSTS: HTTP Strict Transport Security enabled to prevent protocol downgrade attacks.
  • No mixed content: All resources loaded over HTTPS.
  • Automatic certificate renewal: Managed by Cloudflare.

Hosting Security

OmniColor is hosted on Cloudflare Pages, which provides:

  • Enterprise-grade DDoS protection
  • Web Application Firewall (WAF) with OWASP rules
  • Global CDN with automatic failover
  • Regular security updates to infrastructure
  • SOC 2 Type II compliance
  • ISO 27001 certification

See Cloudflare's trust hub for details.

Application Security

Content Security Policy (CSP)

We use a Content Security Policy to mitigate XSS and injection attacks. Our CSP:

  • Restricts scripts to same-origin and approved ad network origins
  • Disallows inline scripts except where structurally necessary
  • Restricts form submissions to same-origin
  • Blocks object/embed elements
  • Upgrades insecure requests to HTTPS

Secure Headers

  • X-Content-Type-Options: nosniff — prevents MIME-type sniffing attacks.
  • X-Frame-Options: DENY — prevents clickjacking via iframe embedding.
  • Referrer-Policy: strict-origin-when-cross-origin — limits referrer information leakage.
  • Permissions-Policy — restricts access to sensitive browser features (camera, microphone, geolocation).
  • Cross-Origin-Opener-Policy: same-origin — isolates our browsing context.

JavaScript Safety

All JavaScript on OmniColor is:

  • Loaded from same-origin (no third-party JS except ad networks)
  • Written by our team with security review
  • Free of eval() and Function() constructors
  • Free of dynamic code execution
  • Sanitizing all user input before DOM insertion

Input Handling

All user input (color codes, image uploads, form fields) is:

  • Validated against strict patterns before use
  • Sanitized before any DOM insertion
  • Never passed to eval() or executed
  • Never used to construct SQL (no SQL exists)
  • Never uploaded to servers

Image Processing

Images uploaded to our tools are processed entirely in the browser using the Canvas API. This means:

  • Images are never uploaded to any server
  • Images are never stored anywhere except your device's memory during processing
  • Images are never accessible to us or any third party
  • File type validation prevents malicious file types
  • File size limits prevent memory exhaustion

Cross-Site Scripting (XSS) Prevention

Every piece of user-provided data rendered to the DOM is escaped using escapeHtml(), preventing XSS attacks through:

  • URL parameters
  • Form input
  • localStorage data
  • PostMessage payloads

Third-Party Risk Management

Advertising Networks

Third-party ad scripts are a security risk. We mitigate by:

  • Only using reputable networks (Adsterra, Google AdSense)
  • Isolating ad slots from tool interfaces
  • Sandboxing ad scripts through CSP
  • Monitoring for malicious ad content
  • Disabling ads by default until consent

CDN and Fonts

We self-host fonts and assets rather than loading from third-party CDNs, eliminating third-party dependency risk.

No Third-Party Analytics Tracking Scripts

We avoid heavy third-party analytics like Google Analytics. Any analytics is privacy-respecting and consent-based.

Data Protection

What We Store

  • In your browser (localStorage): Your favorite colors, recent color history, cookie consent. Never leaves your device.
  • On our servers: Nothing except transient request logs (IP addresses for security, deleted within 30 days).
  • In a database: Nothing — we have no database.

What We Do Not Store

  • Passwords (we have no accounts)
  • Payment information (we accept no payments)
  • Personal identifying information (unless you contact us)
  • Browsing history
  • User-generated content
  • Images uploaded to tools

Incident Response

In the event of a security incident, we commit to:

  • Immediate containment: Take action to stop ongoing damage within 1 hour of detection.
  • Investigation: Determine scope, cause and impact.
  • Notification: Notify affected users within 72 hours if personal data was compromised (GDPR requirement).
  • Remediation: Fix the vulnerability and verify the fix.
  • Transparency: Publish a post-mortem (without exposing sensitive details) on our trust center.

Given our minimal data collection, the risk of any incident affecting users is inherently low.

Secure Development Practices

Code Review

All code changes undergo review for:

  • Security implications
  • Input validation correctness
  • XSS and injection risks
  • Dependency security

Dependency Management

OmniColor uses minimal dependencies:

  • No JavaScript frameworks (React, Vue, etc.)
  • No build tools with complex dependency trees
  • Self-hosted fonts
  • Regular review of any dependencies added

Testing

We test for security vulnerabilities by:

  • Manual security review of new features
  • Automated scanning (Cloudflare WAF, OWASP ZAP where applicable)
  • Testing input validation boundaries
  • Testing with malicious payloads in development

User Security Best Practices

While we implement security on our side, you can protect yourself:

  • Keep your browser updated: Security patches fix known vulnerabilities.
  • Use HTTPS: Always access OmniColor at https://omnicolor.pages.dev — never over HTTP.
  • Be cautious with downloaded files: Files downloaded from our tools (JSON, CSS, PNG, SVG) are safe, but treat downloads from any site with care.
  • Report suspicious activity: If you notice unusual behavior, email us.
  • Verify the URL: Phishing sites may imitate OmniColor — always check the domain in your browser's address bar.

Compliance Frameworks

  • OWASP Top 10: Our architecture avoids most OWASP Top 10 risks.
  • GDPR Article 32: Appropriate technical and organizational measures for data protection.
  • WCAG 2.2: Accessibility is also a security-adjacent concern — screen reader users need reliable content.

Reporting Security Vulnerabilities

If you discover a security issue, we want to hear about it. Please follow responsible disclosure:

  • Email: security@omnicolor.pages.dev
  • PGP key: Available on request for sensitive reports.
  • Include: Description, steps to reproduce, impact assessment, and any proof-of-concept (no exploitation of real users).

See our Responsible Disclosure Policy for full details.

We acknowledge all security reports within 48 hours, investigate thoroughly, and credit reporters (with permission) in our security acknowledgments.

What We Do Not Have Bug Bounties For

We are a small free project and cannot currently offer monetary bug bounties. However, we deeply appreciate all responsible security research and will credit contributors in our Hall of Fame.

Changes to This Policy

We may update this security policy as our infrastructure evolves. The "last updated" date reflects the most recent change. Material changes will be announced on the homepage.

Contact

Security questions and reports: security@omnicolor.pages.dev

General inquiries: Contact page