Adjusting your CSP

Learn how to configure Content Security Policy reporting with cside’s reporting endpoint. CSP reporting is available across all cside subscription tiers.

Service Limits

Plan	Retention Period	Event Capacity
Free	30 days	500,000 events
Business	90 days	1,000,000 events
Enterprise	90 days in dashboard 365 cold storage	Unlimited events

Implementation Guide

Step 1: Configure CSP Headers

Content Security Policy uses directives to control resource loading and execution. For a full list of available directives, refer to the Mozilla Developer Documentation.

Deployment Modes

CSP supports two operational modes:

• Report-Only Mode: Monitors violations without enforcement
• Enforcement Mode: Actively blocks policy violations

Best Practice: Implement CSP through HTTP response headers rather than HTML meta tags for stronger protection.

Implementation Recommendations

1. Begin with Report-Only mode for impact assessment
2. Implement essential directives first:
   • script-src: Control JavaScript source origins
   • image-src: Manage image loading sources
   • font-src: Restrict font loading sources
3. Use script-src 'self' as a baseline security measure

Note: Automated CSP configuration tooling is coming soon.

Step 2: Configure Reporting Endpoint

Each cside customer can receive a customer endpoint so please navigate to the CSP reports section of the cside dashboard to view the CSP reporting endpoint assigned to your account.

Exporting CSP Reports

You can export the raw violation reports behind the dashboard table as a CSV file. Open the CSP reports section of the cside dashboard and select Export CSV.

Each row in the export is an individual violation report, with more detail than the aggregated dashboard view. The columns, in order:

Column	Description
reported_at	When the violation was reported.
domain	The domain the report belongs to.
blocked_url	The URL that was blocked.
offending_domain	The domain of the blocked URL.
effective_directive	The directive that caused the violation.
disposition	Whether the policy was enforced or report-only.
blocked_type	The type of resource that was blocked.
document_uri	The page where the violation happened.
status_code	HTTP status code of the document.
referrer	Referrer of the document.
source_file	The file that triggered the violation.
line_number	Line in the source file.
column_number	Column in the source file.
user_agent	Browser user agent that reported the violation.
script_sample	Sample of the offending script, when available.
original_policy	The policy in force when the violation occurred.

• The export applies the domain you have selected plus the offending-domain and blocked-URL filters that are active in the table.
• The export dialog opens on the date range selected in the table, or the last 7 days if you have not set one. One export can cover up to 92 days. Raw violation reports are kept for 3 months, so that is the furthest back an export can reach.
• Exports are prepared in the background. cside emails you a download link when the file is ready, and the link opens in your dashboard.
• An export is capped at 500,000 reports and 500 MB. If your request matches more than 500,000 reports, cside rejects it right away and asks you to narrow the date range or add an offending-domain or blocked-URL filter. A separate 500 MB size cap applies while the file is being generated; if an export trips either cap at that stage, cside emails you to say it was too large rather than failing silently.

Best Practices and Considerations

cside Compatibility

When CSP Changes Are Not Required

In most cases, no CSP adjustments are needed for the cside monitoring script to work. If your Content Security Policy uses broad directives that allow HTTPS sources, cside will work out of the box.

For example, if your CSP looks like this:

Content-Security-Policy: default-src https: data: 'unsafe-inline' 'unsafe-eval'

The cside script will load without any issues because it is served over HTTPS from *.csidetm.com. A CSP that allows scripts from any HTTPS origin will automatically permit cside.

When CSP Changes Are Required

You only need to update your CSP if you have explicit script-src or connect-src directives that restrict which domains can load scripts or make network requests.

If your CSP includes specific script-src or connect-src directives, add *.csidetm.com to those directives:

Content-Security-Policy: script-src 'self' *.csidetm.com; connect-src 'self' *.csidetm.com

You only need to update directives you already use. If you don’t have script-src or connect-src in your CSP, no changes are needed for those directives.

Add these to your existing CSP settings without removing your current policies. As part of your cside plan, you can also direct CSP violations to our dashboard for monitoring.

Environment Management

CSP implementation often varies between development and production environments. Maintain consistent CSP configurations across all environments to prevent deployment issues and security gaps.

Policy Design Strategy

Balance your CSP implementation between:

• Strict Policies: Stronger security through specific rules, but requires more maintenance
• Permissive Policies: Easier maintenance but may introduce security vulnerabilities

cside’s monitoring capabilities let you implement broader rules while maintaining security through detailed violation reporting and analysis.

Known Challenges

The connect-src directive requires careful consideration due to dynamic client-side dependencies. When implementing this directive, ensure you account for all endpoints your scripts connect to, including analytics, APIs, and third-party services.