Overview

Znode strengthens storefront and API security through two centralized capabilities:

• Global Content Security Policy (CSP) – Defines which external scripts, APIs, and resources are allowed to load in the browser, protecting storefronts from threats such as cross-site scripting (XSS) and malicious code injection.
• Enable IDOR Validation – Enforces API-level ownership validation to ensure users can only access resources they own, preventing unauthorized data access.

Both features are managed centrally and applied across all storefronts, providing consistent and controlled security enforcement.

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. 

Who Should Use This Feature

These features are intended for Administrators responsible for:

• Managing storefront security at a global level
• Maintaining third-party integrations
• Configuring API security policies
• Ensuring consistent security enforcement across all stores

Prerequisites and Permissions

• Administrator access to the Admin Console
• Permission to manage Global Settings and API configurations
• Authorization to modify security policies
• Updated Storefront version (required for IDOR validation support)

Key Concepts

Global Content Security Policy (CSP)

• Controls which external resources are allowed in the browser
• Automatically applied to all storefronts
• Can be extended at the store level without overriding global rules

IDOR Validation

• Restricts access to only user-owned resources
• Prevents unauthorized API access
• Controlled via a global feature toggle

Request Context Requirement

• Mandatory header: Z-Request-Context
• Contains encrypted user context generated by the Storefront
• Required for enforcing IDOR validation

Use Case 1: View the Global Content Security Policy

Steps

1. Sign in to the Admin Console.
2. Navigate to System Settings > Global Settings > API and Security Settings.
3. Locate the Content Security Policy field.
4. Review the configured value.
5. Click Save if no changes are required.

Expected Outcome

• The default CSP is visible and applied across all storefronts.

Use Case 2: Update the Global Content Security Policy

Steps

1. Sign in to the Admin Console.
2. Navigate to System Settings > Global Settings > API and Security Settings.
3. Locate the Content Security Policy field.
4. Add or update CSP directives (for example, default-src, script-src, connect-src).
5. Click Save.

Expected Outcome

• Updated CSP rules are applied immediately across all storefronts.

Use Case 3: Enable IDOR Validation

Steps

1. Sign in to the Admin Console.
2. Navigate to Global Settings > General.
3. Locate Enable IDOR Validation.
4. Select Yes.
5. Click Save.

Expected Outcome

• IDOR validation is enabled for supported APIs (Cart APIs).
• Unauthorized access attempts return a 403 Forbidden response.

Use Case 4: Validate IDOR Behavior

Expected Behavior

• Valid request with correct ownership → Access granted
• Valid request with mismatched ownership → 403 Forbidden
• Missing header → Falls back to existing authorization logic

Validation Rules

CSP Validation

• Must include valid directives (default-src, script-src, connect-src)
• Maximum size: 7,000 characters
• Invalid input error:
  “CSP must include a directive like default-src, script-src, or connect-src before the URL.”

IDOR Validation

• Header must be present and valid
• Header structure cannot be modified
• Custom formats are not supported

Behavioral Scenarios

Scenario 1: Global + Store-Level CSP

• Global CSP applies to all stores
• Store-level CSP adds additional rules

Result:

• Store with additional rules → Combined CSP
• Other stores → Global CSP only

Scenario 2: Removing Required API from CSP

• Removing a required API blocks browser requests
• Example: Payment API removed

Result:

• Payment requests fail
• Checkout is blocked
• Customers cannot complete transactions

Security Behavior

CSP

• Blocks unauthorized scripts and resources
• Prevents browser-based attacks

IDOR

• Enforces ownership validation
• Prevents unauthorized data access

Request Context

• Identifies authenticated users and CSR impersonation
• Encrypted and tamper-proof
• Ensures secure API communication

Backward Compatibility

IDOR

CSP

• Existing storefronts continue to function
• Store-level configurations are preserved
• Global CSP does not overwrite store-level settings

Guest User Behavior

• IDOR validation does not apply to guest users
• Guest cart flows continue to function using existing logic

Limitations

• No system warning if CSP changes break integrations
• Issues must be identified using browser developer tools
• IDOR validation currently applies to selected APIs only

Important Notes

• IDOR validation is a breaking change when enabled
• CSP changes take effect immediately across all storefronts
• Older Storefront versions may not fully support IDOR validation
• Only Cart APIs are covered in the current phase

Recommendations and Guidelines

To ensure a secure and stable implementation, follow these best practices:

General

• Always test changes in a lower environment before applying to production
• Carefully review all updates before saving, as changes take effect immediately

CSP Configuration

• Ensure all required third-party domains (payments, APIs, integrations) are included
• Use valid CSP directives such as default-src, script-src, and connect-src
• Avoid insecure configurations such as wildcards (*) unless absolutely necessary
• Keep CSP optimized by removing duplicate or unused entries
• Use Global CSP as a baseline and apply store-level CSP only when additional rules are needed
• Use browser developer tools to identify blocked resources and troubleshoot issues