API & Security Settings

Global Content Security Policy (CSP) Configuration

Overview

The Global Content Security Policy (CSP) defines the default security rules applied to all Znode storefronts. CSP controls which external scripts, APIs, frames, and other resources are allowed to load in the browser, helping protect storefronts from security threats such as cross-site scripting (XSS) and malicious code injection.

In Znode, the Global CSP is centrally managed and automatically applied to every store.


Who Should Use This Feature

This feature is intended for Znode Admin responsible for:

  • Managing storefront security at a global level
  • Maintaining default third-party integrations
  • Ensuring consistent CSP enforcement across all stores

Prerequisites and Permissions

  • Administrator access to the Znode Admin Console
  • Permission to manage User-defined Fields (Attributes)
  • Authorization to update API and security configurations


Use Cases

Use Case 1: View the Global Content Security Policy

Admin review the Global CSP to verify which external resources are allowed across all storefronts.

Use Case 2: Update the Global Content Security Policy

Admin update the Global CSP when new third-party integrations are required or when existing rules must be modified.


View the Global Content Security Policy

  1. Sign in to the Znode Admin Console.
  2. Navigate to System Settings > Global Settings > API and Security Settings.
  3. Locate the Content Security Policy field.
  4. Default CSP is already Added.
  5. Save the Changes.
  6. The Default CSP applied to storefronts.

Note: Any changes to the API or Security settings can directly impact the storefront and APIs, potentially causing service disruptions or functionality issues. Do not save or apply any changes unless they have been thoroughly reviewed, validated, and verified to be safe and accurate. Unauthorized or unverified changes are strictly prohibited. 


Validation Rules

  • The CSP value must include a valid directive such as default-src, script-src, or connect-src.
  • If an invalid CSP is entered, the following error message is displayed:
     “CSP must include a directive like default-src, script-src, or connect-src before the URL.” 
  • The total CSP applied to a storefront must remain under 7,000 characters.

Examples of Global Content Security Policy Behavior

Scenario 1: Global CSP Applied with Store-Level Extensions

The Global Content Security Policy is automatically applied to all stores. If additional CSP entries are explicitly configured for a specific store, those entries are merged with the Global CSP for that store.

Example:

  • At the Global level, five APIs are configured in the default CSP and apply to all stores.
  • For Store A, two additional APIs are configured at the store level.

Result:

  • Store A: Seven CSP entries are applied (five Global + two store-specific).
  • Other stores: Only the five Global CSP entries are applied, since no additional store-level CSP is configured.

Scenario 2: Impact of Removing a Required API from Global CSP

If a required third-party API is removed from the Global Content Security Policy, the browser blocks all requests to that API across storefronts.

Example:

The Spreedly payment API is removed from the Global CSP. When a customer proceeds to checkout and enters payment details, the storefront attempts to call the Spreedly API to tokenize or process the payment.

Because the Spreedly domain is no longer allowed in the CSP, the browser blocks the request.

Result:

  • The payment request to the Spreedly API fails.
  • Customers are unable to complete checkout.
  • The storefront may display a payment error or remain stuck during checkout.

Important Notes and Best Practices

  • Always test Global CSP changes in a lower environment before production.
  • Ensure all required third-party domains are included before saving.
  • Global CSP changes take effect immediately and impact all storefronts.
  • Use browser developer tools to identify blocked resources after changes.

Backward Compatibility

  • Existing storefronts continue to function after Global CSP is introduced.
  • Stores without store-level CSP automatically inherit the Global CSP.
  • Global CSP updates do not overwrite existing store-level CSP configurations.

Limitations

  • The system does not display warnings if a Global CSP change breaks an integration.
  • CSP-related issues must be identified using browser console errors or logs.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.