CSP - Content Security Policy

What Is Content Security Policy (CSP)?

Modern eCommerce sites rely on dozens of third-party tools — analytics, personalization, monitoring, payments, chat, and more. That flexibility is powerful, but it also opens the door to security risks.

That’s where Content Security Policy (CSP) comes in.

CSP is one of the web’s most important security layers. It helps protect websites from malicious scripts, unauthorized resources, and common attacks like Cross-Site Scripting (XSS).

The challenge?
A strict CSP can accidentally block critical tools — including analytics and monitoring platforms like Webeyez.

What Is Content Security Policy?

Content Security Policy is an HTTP response header that tells browsers:

“Only load resources from trusted sources.”

Instead of allowing scripts, images, frames, or network requests from anywhere, CSP creates a whitelist of approved domains.

Here’s a simple example:

Content-Security-Policy:
default-src 'self';
script-src 'self' https://cdn.example.com;

This policy means:

• Load resources only from the same domain by default
• Allow JavaScript from:
• • the website itself
  • cdn.example.com

Everything else gets blocked.

Why CSP Matters

CSP helps prevent:

• Cross-Site Scripting (XSS)
• Malicious third-party injections
• Data exfiltration
• Unauthorized scripts
• Compromised browser extensions

For enterprise and regulated environments, CSP is often mandatory.

But strict policies require every legitimate third-party vendor to be explicitly approved.

That includes:

• Analytics tools
• Monitoring platforms
• A/B testing systems
• Payment providers
• Customer support widgets

And yes — Webeyez too.

How CSP Override Logic Works

A critical thing to understand about Content Security Policy is this:

More specific directives override broader ones.

This means that once you define a lower-level directive, the browser stops inheriting permissions from higher-level directives.

When implementing Webeyez, make sure to add the CSP to the correct level, otherwise it can break higher-level CSP setings.

In other words:

Specific directive > inherited fallback

Example of CSP Inheritance

Let’s start with this policy:

Content-Security-Policy:
default-src 'self' https://*.webeyez.com;

Because no other directives are defined, the browser uses default-src as the fallback for:

• script-src
• connect-src
• worker-src
• and others

So Webeyez is allowed everywhere.

What Happens When You Add a Lower-Level Directive

Now imagine you later add:

script-src 'self';

Your policy becomes:

Content-Security-Policy:
default-src 'self' https://*.webeyez.com;
script-src 'self';

At this point:

• script-src NO LONGER inherits from default-src
• The browser ignores the Webeyez domain previously allowed in default-src
• Only 'self' is now allowed for scripts

Result:

• Webeyez JavaScript gets blocked
• Monitoring stops working
• Browser console shows CSP violations

Content-Security-Policy:
default-src 'self';
script-src 'self' https://*.webeyez.com;
connect-src 'self' https://*.webeyez.com https://webeyez.blob.core.windows.net;
worker-src 'self' blob:;

Required Webeyez CSP Directives by Hierarchy

When defining more specific CSP directives, you must explicitly add Webeyez permissions at each level where they are needed.

Here’s what each directive controls and why it matters.

script-src

script-src 'self' https://*.webeyez.com;

What it does

Controls which JavaScript sources are allowed to execute on the page.

Why Webeyez needs it

This allows the Webeyez tracking and monitoring scripts to load properly.

Without it:

• the Webeyez tag may fail to initialize
• monitoring scripts can be blocked entirely

connect-src

connect-src 'self' https://*.webeyez.com https://webeyez.blob.core.windows.net;

What it does

Controls outbound network requests such as:

• API calls
• analytics events
• beacon requests
• fetch/XHR requests

Why Webeyez needs it

Webeyez sends monitoring and analytics data to its collection endpoints and may retrieve assets from Azure Blob Storage.

Without it:

• session data may not be sent
• analytics can stop reporting
• screenshots/assets may fail to load

worker-src

worker-src 'self' blob:;

What it does

Controls which sources can create:

• Web Workers
• Service Workers
• background browser processing threads

Why Webeyez needs it

Some advanced monitoring and replay capabilities rely on browser workers and blob-based execution contexts.

Without it:

• session replay features may break
• background processing can fail silently

Important Reminder About CSP Hierarchy

Once you define:

• script-src
• connect-src
• worker-src

they no longer inherit permissions from default-src.

So even if Webeyez is already allowed in:

default-src 'self' https://*.webeyez.com;

you must still explicitly add Webeyez to each lower-level directive where required.

Because in CSP:

inheritance stops when a more specific directive exists.