Content Security Policy

Last Updated: March 26, 2025

1. Introduction

This Content Security Policy (CSP) document explains how ViolaRead, operated by LYDovate, protects our website visitors and extension users from various security risks such as cross-site scripting (XSS) attacks, data injection attacks, and other code injection attacks. Our CSP is designed to enhance security while ensuring full functionality of our services.

2. What is a Content Security Policy?

A Content Security Policy is a security mechanism that helps prevent unauthorized code execution by controlling what resources (such as scripts, stylesheets, images, etc.) can be loaded by web pages. It acts as an additional layer of security for web applications by specifying which content sources are approved and should be allowed to load.

3. Our Content Security Policy Framework

ViolaRead implements a comprehensive CSP across our web application and browser extension. Our policy is designed to:

  • Mitigate the risk of content injection vulnerabilities
  • Protect user data from exfiltration
  • Ensure only authorized scripts execute in user contexts
  • Prevent malicious iframes and object embedding
  • Control communication with external domains

4. Core Policy Directives

Our Content Security Policy includes the following key directives:

4.1 default-src

The default-src directive defines the fallback policy for fetching resources when more specific directives are not defined. ViolaRead uses a restrictive default-src:

  • 'none' - We start with the most restrictive setting and explicitly define allowed sources

4.2 script-src

Controls which scripts can be executed. We allow scripts from:

  • 'self' - Scripts from our origin
  • Specific subdomains rather than wildcards (e.g., app.posthog.com instead of *.posthog.com)
  • www.googletagmanager.com, apis.google.com - Google services
  • js.stripe.com - Payment processing
  • 'nonce-[dynamic]' - We use cryptographic nonces for any inline scripts instead of 'unsafe-inline'

4.3 connect-src

Restricts URLs to which scripts can connect using fetch(), XMLHttpRequest, WebSocket, etc.:

  • 'self' - Our own origin
  • Specific API endpoints (minimizing wildcards where possible)
  • firestore.googleapis.com, identitytoolkit.googleapis.com - Firebase services
  • app.posthog.com - Analytics connections
  • api.stripe.com - Payment API calls
  • vercel.com, vercel.live - Hosting provider

4.4 img-src

Controls from where images can be loaded:

  • 'self' - Images from our own domain
  • data: - For inline data URIs (carefully validated)
  • images.unsplash.com - Our image sources
  • i.imgur.com - User content images

4.5 style-src

Controls from where styles can be loaded:

  • 'self' - Styles from our domain
  • 'nonce-[dynamic]' - We use cryptographic nonces for inline styles instead of 'unsafe-inline'
  • fonts.googleapis.com - Google Fonts

4.6 font-src

Specifies valid sources for fonts:

  • 'self' - Fonts from our domain
  • fonts.googleapis.com, fonts.gstatic.com - Google Fonts
  • data: - For inline font data (carefully monitored)

4.7 frame-src

Controls valid sources for nested browsing contexts (iframes):

  • 'self' - Frames from our domain
  • www.youtube.com - For embedded videos
  • js.stripe.com - For payment forms

4.8 Additional Critical Directives

We implement these important security directives that are often overlooked:

  • object-src 'none' - Blocks Flash, Java, and other potentially dangerous plugins
  • base-uri 'self' - Prevents attackers from manipulating base URLs for relative paths
  • form-action 'self' https://api.stripe.com - Controls where forms can be submitted
  • worker-src 'self' blob: - Controls valid sources for web workers
  • manifest-src 'self' - Controls valid sources of application manifests

5. Special Considerations for the ViolaRead Extension

Our browser extension operates under a different security model than traditional web applications. As a browser extension, ViolaRead needs to interact with content on various websites that users visit. We ensure security through:

  • Scoped Permissions: The extension only accesses the specific permissions declared in its manifest, which users review during installation.
  • Content Script Isolation: Extension content scripts run in an isolated JavaScript environment to prevent conflicts with website scripts.
  • Message Validation: All communications between the extension's components undergo strict validation to prevent injection attacks.
  • Limited Origins: Background processes only communicate with our approved API endpoints.

6. Third-Party Service Providers

ViolaRead integrates several third-party services to provide a complete experience. Each service provider must adhere to strict security standards and is only granted the minimum necessary permissions:

6.1 Firebase (Google)

Used for authentication, database, and hosting services. Our CSP allows connections to Firebase domains for these essential functions.

6.2 PostHog

Used for analytics to understand how users interact with our application. PostHog scripts and connections are restricted to specific domains and functions.

6.3 Stripe

Used for payment processing. Stripe scripts and connections are limited to payment-related functions only.

6.4 Vercel

Our hosting provider. Resources from Vercel domains are permitted for application delivery and performance monitoring.

7. CSP Reporting and Violation Handling

We actively monitor CSP violations to identify and address potential security issues:

  • Violation Reporting: Our CSP includes a report-uri directive that sends detailed violation reports to our security team.
  • Regular Review: We analyze violation patterns to detect potential attacks and improve our policy.
  • Graduated Response: We use a report-only mode when testing policy changes before enforcement.

We adhere to CSP best practices and keep our policies up-to-date with the latest security standards to provide maximum protection for our users.

8. Data Protection Measures

In addition to our CSP, we implement multiple layers of data protection:

  • Transport Layer Security (TLS): All communications with ViolaRead services use secure HTTPS connections.
  • Cross-Site Request Forgery (CSRF) Protection: We implement CSRF tokens to prevent cross-site request forgery attacks.
  • Input Validation: All user inputs are validated and sanitized before processing.
  • Content Encoding: We use proper output encoding to prevent XSS attacks.
  • Security Headers: We implement various HTTP security headers in addition to CSP, including:
    • X-Content-Type-Options: nosniff
    • X-Frame-Options: SAMEORIGIN
    • X-XSS-Protection: 1; mode=block
    • Strict-Transport-Security: max-age=31536000; includeSubDomains
    • Referrer-Policy: strict-origin-when-cross-origin

9. User Controls and Privacy

ViolaRead is committed to user privacy and security. Our CSP implementation is designed to protect users while respecting their privacy:

  • We do not use CSP to track users beyond necessary security monitoring
  • CSP violation reports are anonymized and only used for security purposes
  • Users can report security concerns through our Contact page

10. Changes to This Policy

We may update our Content Security Policy from time to time to address new security challenges or incorporate new technologies. Major changes to this policy document will be noted with an updated "Last Updated" date at the top of this page.

While we may make technical changes to our actual CSP implementation at any time to address security needs, we will document significant changes that affect user experience or third-party integrations in this policy document.

11. Contact Us

If you have any questions about our Content Security Policy or security practices, please contact us at:

12. Additional Resources

To learn more about Content Security Policies and web security, we recommend these resources: