Securing Your E-Commerce Site: A Guide to CSP, Security Headers, and Best Practices

[OlegoO]

Overview

Security is a top priority for e-commerce platforms. Ensuring your storefront and backend services follow best practices for security headers can significantly reduce vulnerabilities. The HTTP Observatory Report, developed by Mozilla, provides an easy way to analyze and improve your site’s security posture.

Using HTTP Observatory for Security Testing

You can evaluate your e-commerce site’s security headers using Mozilla’s Observatory tool:

HTTP Header Security Test - HTTP Observatory | MDN

To use the service:

1. Enter your website URL.
2. Run the security test.
3. Review the generated report and follow recommendations to enhance security.

Understanding Content Security Policy (CSP)

CSP is a powerful tool for preventing cross-site scripting (XSS) and other code injection attacks. However, integrating third-party services like Google Tag Manager (GTM) or analytics scripts can make CSP implementation challenging.

Pros of CSP:

• Protects against XSS and data injection attacks.
• Restricts loading of untrusted resources.

Cons with Third-Party Integrations:

• Some analytics and tracking scripts (e.g., GTM) require relaxed rules.
• Inline scripts may require ‘unsafe-inline’, reducing CSP effectiveness.

Browser Support for Content Security Policy

Most modern browsers support CSP, but the level of support varies depending on the CSP version and specific directives.

Browser	CSP 1.0	CSP 2.0	CSP 3.0
Google Chrome	(v25+)	(v40+)	(v67+)
Mozilla Firefox	(v23+)	(v31+)	(v59+)
Safari (MacOS & iOS)	(v7+)	(v10+)	(v16+)
Microsoft Edge	(v12+)	(v14+)	(v79+)
Opera	(v15+)	(v27+)	(v54+)
Internet Explorer	(Partial, IE10+)	(Not supported)	(Not supported)

Key Directives in CSP

Below is a breakdown of the most important CSP directives and their configurations. Also, you can find Content-Security-Policy (CSP) specifications by following link

1. default-src (Default Content Source)

Defines the default policy for loading content such as JavaScript, images, CSS, fonts, and other resources.

Example:

Content-Security-Policy: default-src 'self'

• 'self' – Allows loading content only from the same origin.
• none – Blocks all external content unless explicitly allowed.
• Specific domains can be added (https://example.com).

---

2. script-src (JavaScript Security)

Restricts which scripts can be executed, preventing malicious inline scripts.

Example:

Content-Security-Policy: script-src 'self' https://trusted-cdn.com 'nonce-random123' 'strict-dynamic'

• 'self' – Allows scripts from the same origin.
• 'nonce-random123' – Allows scripts with a specific nonce (random token).
• 'strict-dynamic' – Dynamically loaded scripts inherit the policy of the initial script.
• 'unsafe-inline' – (Not recommended) Allows inline scripts.
• 'unsafe-eval' – (Not recommended) Allows JavaScript eval().

---

3. style-src (CSS Security)

Controls allowed sources for stylesheets.

Example:

Content-Security-Policy: style-src 'self' https://fonts.googleapis.com 'unsafe-inline'

• 'self' – Allows styles from the same origin.
• 'unsafe-inline' – Allows inline styles (not recommended unless absolutely necessary).
• https://trusted-styles.com – Allows styles from a specific external domain.

---

4. img-src (Image Sources)

Specifies valid sources for loading images.

Example:

Content-Security-Policy: img-src 'self' https://cdn.example.com data:

• 'self' – Allows images from the same origin.
• data: – Allows base64-encoded images.
• Specific domains can be added.

---

5. font-src (Font Loading Security)

Defines trusted sources for fonts.

Example:

Content-Security-Policy: font-src 'self' https://fonts.gstatic.com

• 'self' – Allows fonts from the same origin.
• Specific font CDNs (e.g., Google Fonts) can be added.

---

6. connect-src (AJAX & WebSocket)

Limits which URLs can be connected to via fetch, XMLHttpRequest, WebSockets, etc.

Content-Security-Policy: connect-src 'self' https://api.example.com

• 'self' – Allows connections to the same origin.
• https://api.example.com – Allows API requests to a specific endpoint.

---

7. media-src (Audio/Video Content)

Defines allowed sources for media files.

Example:

Content-Security-Policy: media-src 'self' https://media.example.com

---

8. object-src (Blocking Flash & Plugins)

Controls which sources can load <object>, <embed>, or <applet> elements.

Example:

Content-Security-Policy: object-src 'none'

• 'none' – Disables all plugins (recommended for security).

---

9. frame-src (Embedding & iFrames)

Defines allowed sources for embedding via <iframe>.

Example:

Content-Security-Policy: frame-src 'self' https://trusted-site.com

---

10. worker-src (Web Workers & Shared Workers)

Controls sources for Worker, SharedWorker, and ServiceWorker.

Example:

Content-Security-Policy: worker-src 'self'

---

11. form-action (Form Submission Security)

Restricts where forms can be submitted.

Example:

Content-Security-Policy: form-action 'self'

• 'self' – Allows form submissions only to the same origin.
• Specific trusted domains can be added.

---

12. base-uri (Preventing Base Tag Manipulation)

Restricts the allowed sources for <base> elements to prevent base URL modification.

Example:

Content-Security-Policy: base-uri 'self'

---

13. frame-ancestors (Preventing Clickjacking)

Controls which domains can embed the page via an <iframe>.

Example:

Content-Security-Policy: frame-ancestors 'self' https://trusted-site.com

• 'none' – Prevents the page from being embedded.
• 'self' – Allows embedding only on the same origin.

---

14. upgrade-insecure-requests

Automatically upgrades HTTP requests to HTTPS.

Example:

Content-Security-Policy: upgrade-insecure-requests

---

15. report-uri & report-to (Reporting Violations)

Used to log CSP violations for debugging and monitoring.

Example:

Content-Security-Policy: default-src 'self'; report-uri https://csp-report.example.com

• report-uri – Sends reports to a specified endpoint (deprecated in favor of report-to).
• report-to – Uses structured reporting for CSP violations.

Best Practices for CSP Implementation

1. Start with Report-Only Mode - Before enforcing CSP, use Content-Security-Policy-Report-Only to monitor violations.

Content-Security-Policy-Report-Only: default-src 'self'; report-to https://csp-report.example.com

2. Use nonce or hash Instead of unsafe-inline - Avoid allowing inline JavaScript and CSS. Use nonce (random tokens) or hash for trusted scripts.

3. Be Specific in Defining Allowed Sources - Limit allowed domains to trusted ones.

4. Regularly Monitor CSP Reports - Check reported violations and adjust policies accordingly.

5. Enable upgrade-insecure-requests - Ensures all HTTP requests upgrade to HTTPS.

6. Restrict frame-ancestors - Prevents clickjacking attacks by limiting iframe embedding.

Debugging CSP in Edge/Chrome

To debug and refine your CSP settings:

1. Open Developer Tools (F12).
2. Go to the Console tab to check for CSP violations.
3. Adjust rules iteratively based on blocked resources.
4. Use the Network tab to monitor blocked requests.

Why CSP is a problem?

A strict CSP would require whitelisting every script and domain, which can be nearly impossible with e-commerce dynamic content and frequent third-party integrations.

Usually, an e-commerce website relies on numerous third-party services for analytics, advertising, tracking, and personalization. These include:

• Google Analytics, Facebook Pixel (marketing & tracking)
• Affiliate programs (external referrals)
• A/B testing services (personalized shopping experience)
• Payment processors (secure transactions)

Plan B. Securing a Site Without a Strict CSP

If you can’t enforce a strict Content Security Policy (CSP) due to third-party dependencies, legacy code, or business requirements, you can still significantly improve security using alternative security measures:

1. Minimal CSP Configuration:

Content-Security-Policy: "default-src 'self'; script-src 'self' 'unsafe-inline';"

2. Essential Security Headers Without CSP:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

3. Subresource Integrity (SRI) security strategies
   Instead of strict CSP, you can use other security strategies, such as: Subresource Integrity (SRI) for external scripts:
   *. Strict input validation & output encoding to prevent XSS
   *. Content filtering for user-generated content
   *. Web application firewalls (WAFs) for real-time attack mitigation
   *. SameSite cookies & HTTPS enforcement for session security

Achieving an A+ Security Rating

Ensuring your e-commerce platform meets the highest security standards requires a combination of strong HTTP security headers, a well-structured Content Security Policy (CSP), and other security best practices. Many security testing tools, such as Mozilla’s HTTP Observatory, SSL Labs, and SecurityHeaders.com, assess your site’s security configuration and provide actionable recommendations.

Why an A+ Security Rating Matters?

Achieving an A+ rating means your website follows industry best practices, protecting against threats such as:
Cross-Site Scripting (XSS) – Prevents injection of malicious scripts.
Clickjacking Attacks – Stops unauthorized embedding of your website.
Man-in-the-Middle (MITM) Attacks – Enforces HTTPS to prevent data interception.
Data Leakage Risks – Ensures secure transmission of sensitive user information.

To improve your security rating, implement the following security headers in your e-commerce frontend and backend:

X-Content-Type-Options: nosniff
Content-Security-Policy: >
    "default-src 'self';
    script-src 'self' https://www.googletagmanager.com https://js.skyflow.com https://jstest.authorize.net https://testflex.cybersource.com https://static.cloudflareinsights.com https://cdn.builder.io https://runtime-dom.esm-bundler.js;
    style-src 'self' 'unsafe-inline';
    frame-src https://testflex.cybersource.com https://js.skyflow.com;
    img-src 'self' data: https://ae01.alicdn.com https://virtostart-main.govirto.com https://cdn.builder.io https://www.thecakery.com https://google.com https://vcst-qa.govirto.com https://img.freepik.com;
    font-src 'self' data: https://fonts.gstatic.com;
    connect-src 'self' https://cdn.builder.io https://jstest.authorize.net;
    frame-ancestors 'self' https://builder.io https://virtostart-demo-admin.govirto.com;
    object-src 'none';
    base-uri 'self';
    form-action 'self';
    upgrade-insecure-requests;"

Explanation of CSP Parameters:

• default-src ‘self’ – Allows resources to be loaded only from the same origin unless otherwise specified.
• script-src – Defines trusted sources for JavaScript files.
• style-src – Specifies trusted sources for stylesheets. The ‘unsafe-inline’ value allows inline styles.
• frame-src – Defines allowed sources for embedding content in iframes.
• img-src – Specifies trusted sources for loading images.
• font-src – Defines permitted sources for font files.
• connect-src – Controls where the site can make network requests (e.g., API calls).
• frame-ancestors – Specifies what origins can embed the site in a frame (e.g., iframe, object, embed, applet).
• object-src ‘none’ – Disables the use of <object> , <embed> , and <applet> elements for security.
• base-uri ‘self’ – Restricts the URLs that can be used as a base URL for relative paths.
• form-action ‘self’ – Limits where forms can submit data.
• upgrade-insecure-requests – Automatically upgrades insecure HTTP requests to HTTPS.

This configuration improves security while maintaining compatibility with essential third-party scripts. Although eliminating 'unsafe-inline' for scripts is ideal, certain tools like Builder.io may require it.

Conclusion

Ensuring strong security for your e-commerce site is an ongoing process. Tools like Mozilla’s HTTP Observatory help assess and improve security headers, while CSP and other security headers significantly reduce risks. Implementing the recommended settings can elevate your site’s security grade and protect both your business and customers.