Content Security Policy (CSP) Configuration Guide for AppNavi

Overview

This document guides on configuring Content Security Policy (CSP) for integrating AppNavi into your web application.

CSP is a security mechanism implemented by modern web browsers to prevent unauthorized execution of scripts, styles, and other resources. Incorrect CSP configurations may prevent AppNavi from functioning correctly.

More information about CSP can be found here.

What is a Content Security Policy (CSP)?

CSP restricts the types of content that a web page can load. It is defined using:

• HTTP Headers (Recommended)
• HTML<meta> Tags (Alternative)

A correctly configured CSP helps prevent security vulnerabilities such as Cross-Site Scripting (XSS) and data injection attacks.

ℹ️ Note: AppNavi, via its Chrome extension, never updates or modifies the host website's CSP policy.

Identifying CSP Errors

When AppNavi is blocked by CSP, your browser may display errors in the developer console (F12 → Console tab).

Common CSP Errors and Their Causes

Configuring CSP for AppNavi

Recommended: Using HTTP Headers

The best practice is to configure your web server to include the following CSP directive in the response headers:

Content-Security-Policy: 
  default-src 'none'; 
  connect-src api-prod-eu-central-1.inappnavi.com data-prod.inappnavi.com; 
  script-src data-prod.inappnavi.com; 
  img-src data: data-prod.inappnavi.com; 
  font-src data:; 
  style-src 'unsafe-inline' data-prod.inappnavi.com;
  frame-src www.youtube.com; //requires for adding youtube videos in the tooltip.

Example of configuring CSP for AppNavi using http Headers

Alternative: Using an HTML <meta> Tag

If you do not have access to server configurations, you can include the CSP policy in your HTML:

<meta http-equiv="Content-Security-Policy" 
            content="default-src 'none'; 
            connect-src api-prod-eu-central-1.inappnavi.com data-prod.inappnavi.com; 
            script-src 'unsafe-inline' data-prod.inappnavi.com; 
            img-src data: data-prod.inappnavi.com; 
            font-src data: data-prod.inappnavi.com; 
            style-src 'unsafe-inline' data-prod.inappnavi.com;">

Example of configuring CSP for AppNavi using meta tag

Explanation of CSP Directives

Option 1: Standard Configuration

Option 2: Nonce-Based Configuration (Direct Integration only)

This approach is only supported in Direct Integration (an-loader). If you are using the Chrome Extension, use Option 1.

Replace {{NONCE}} with the unique random value your server generates on each request.

Applying the Nonce to AppNavi's Direct Integration An-Loader Script

Once your server is generating a nonce and including it in the CSP header, you need to pass that same value to AppNavi's loader script tag. Without this, the browser will block the script even if your CSP header is correct.

<script
  nonce="{{NONCE}}"
  type="text/javascript"
  src="https://data-prod.inappnavi.com/client/an-loader.js?tenant={{TENANT_ID}}&delay=250&environment=prod">
</script>

Replace the following placeholders before use:

What is a Nonce?

A nonce (short for “number used once”) is a unique, randomly generated value that is created for each request and used only once. It acts like a one-time security token that ensures only trusted scripts are allowed to execute in the browser. Since it is generated dynamically and cannot be predicted, it significantly reduces the risk of unauthorized script execution.

A nonce serves as an alternative to the above table/standard-based configuration. Instead of allowing an entire domain of AppNavi in the Content Security Policy (CSP), you can restrict execution more tightly by allowing only scripts that contain the correct nonce value.

When Should You Use a Nonce?

Use a nonce if you want to avoid unsafe-eval and unsafe-inline in your CSP policy. A nonce allows script and style execution without these directives. However, nonces only cover script and style execution — they do not allow network requests or asset loading. You must still whitelist data-prod.inappnavi.com in connect-src, img-src, and font-src directives.

The difference is in script-src and style-src:

Option 1: Standard

script-src data-prod.inappnavi.com style-src data-prod.inappnavi.com

Option 2: Nonce-Based (Strict)

script-src 'nonce-{{NONCE}}' style-src 'nonce-{{NONCE}}'

With a nonce, the domain is no longer required in script-src and style-src — the browser will only execute scripts and styles that carry the matching nonce value.

Note: In both options, if your application uses AppNavi's Custom Code Execution Mode set to Dynamic, add unsafe-eval to script-src. If it is set to Inline, you can skip it.

Current Support

At present, nonce is supported only in Direct Integration (an-loader).

How Does It Improve Security?

Nonce enhances security by enforcing strict execution rules:

1. The server generates a nonce and sends it in the CSP header
2. The same nonce is added to trusted script tags
3. The browser only executes scripts that contain the matching nonce
4. Any script without the correct nonce is blocked

This ensures that even if an attacker injects a script, it will not execute because it won’t have the valid nonce.

Nonce Flow:

1. Server generates a random nonce for each request

2. The nonce is added to the CSP header in the response

3. The same nonce value is added to AppNavi's direct Integration script (an-loader.js)

4. AppNavi script then will use the same nonce value to load its own resources (styles, scripts)

5. Browser validates and executes only matching scripts

Frequently Asked Questions (FAQs)

Q1: Why is my AppNavi integration blocked by CSP?

If you see CSP errors in the browser console, it means that the policy is too restrictive. Make sure that script-src,connect-src, img-src, font-src, andstyle-src include data-prod.inappnavi.com.

Q2: How can I check if my CSP settings are correct?

Use browser developer tools:

1. Open Chrome DevTools (F12 → Console).
2. Look for CSP violation messages.
3. Adjust the CSP policy accordingly.

Use Google’s CSP Evaluator:

• CSP Evaluator helps analyze security risks in your CSP settings.

Q3: What if I need to allow scripts/styles from multiple domains?

You can specify multiple domains by separating them with a space:

script-src 'self' https://cdn.example.com data-prod.inappnavi.com;

This allows scripts from your own site ('self'), cdn.example.com, and inappnavi.com.

Q4: Can I test my CSP before enforcing it

Yes! Use CSP Report-Only Mode to log violations without blocking resources:

Content-Security-Policy-Report-Only: script-src data-prod.inappnavi.com;

This helps identify potential issues before enforcing strict CSP rules.

Q5: Do I need to configure CSP at all, or does AppNavi handle it?

CSP is enforced by your web server, not by AppNavi. AppNavi will never modify your existing CSP. You need to update your server config yourself to allow AppNavi's resources — otherwise the browser will block them silently.

Q6: I configured CSP but AppNavi still isn't loading. What do I check first?

Open your browser console (F12) and look for lines starting with "Refused to load" or "Refused to execute." Each violation tells you exactly which directive is missing and which URL was blocked. Match that URL against the directives table and add it to the right directive.

Q7: Should I use the standard approach or the nonce-based approach?

With the standard approach, script-src and style-src require data-prod.inappnavi.com. With the nonce approach, the domain is no longer needed in those two directives — the browser will only execute scripts and styles that carry the matching nonce value.

In both approaches, connect-src, img-src, and font-src still require data-prod.inappnavi.com — nonces do not cover network requests or assets.

Also in both approaches, if your application uses AppNavi's Custom Code Execution Mode set to Dynamic, add unsafe-eval to script-src. If it is set to Inline, you can skip it.

If your server can generate a fresh random nonce on every request and inject it into both the CSP header and the script tag, the nonce approach is the better choice. If that's not easy to set up, the standard approach is fine. If you're using the Chrome Extension, only the standard approach applies — nonces are supported in Direct Integration only.

Q8: My CSP was working and then broke after an AppNavi update. Why?

AppNavi may load additional subresources (scripts, styles, fonts) as it updates. If a new resource comes from a URL that wasn't previously needed, your existing CSP will block it. Check the console for new violation errors and update your directives accordingly. Watching for these in staging before production is worth it.

Q9: What's the risk of using unsafe-inline in script-src?

It disables a core XSS protection — browsers normally block inline scripts injected by attackers, but unsafe-inline turns that off. For style-src it's less critical, but for script-src you should avoid it. Use a nonce or hash instead for any inline scripts you actually own.

Q10: Does the nonce expire?

A nonce is valid for a single page load. Your server generates a new one for every request, so there's no long-term expiry concern. The risk would be reusing the same nonce across requests, which would defeat its purpose — make sure your generation is random and per-request.

If you require further assistance, please contact your AppNavi support team.