Power Apps Content Security Policy: 2026 Setup Guide

If you build or govern Power Apps, especially code apps (preview) or canvas apps in Dataverse, put Content Security Policy (CSP) on your near‑term roadmap. CSP, delivered via HTTP headers, tells the browser which sources your app can load (scripts, styles, images, frames, and more).

It’s a leading defense against XSS and clickjacking, and Microsoft now supports environment‑level configuration in Power Platform.

As of late January 2026, Microsoft is tightening CSP enforcement for Power Apps code apps (preview): requests to external sources not explicitly allowed will be blocked by default. That means you should audit, configure, and test CSP now (ideally in dev/test) so production apps don’t silently lose critical assets.

This guide shows you exactly how to configure CSP in Power Apps, with step‑by‑step instructions, opinionated best practices, and answers to “people also ask” questions we hear from enterprise Microsoft 365 teams.

What is Content Security Policy (CSP) & How it Fits Power Apps in 2026

A CSP is a header (e.g., Content-Security-Policy) comprised of directives such as script-src, style-src, img-src, frame-ancestors, etc. Each directive contains an allowlist of valid sources (like 'self', https://cdn.contoso.com, or keywords such as 'unsafe-inline'). The browser enforces the policy for every page load, blocking disallowed resources and optionally sending violation reports to your chosen endpoint.

Where CSP applies in Power Platform

Microsoft supports CSP across model‑driven, canvas, and code apps. For model‑driven and canvas apps, CSP is an environment‑level setting (Dataverse required) with defaults you can enable, report, and tune, especially frame-ancestors. For code apps (preview), there’s a richer set of configurable directives (e.g., script-src, connect-src, img-src) and a first‑class report‑only vs. enforce mode you can toggle per environment.

Why this matters now?

Microsoft announced strict CSP enforcement for code apps beginning late January 2026. If your code app calls external APIs, CDNs, or iframes third‑party content, you must explicitly 'allowlist' those sources; otherwise, those requests will be blocked after enforcement.

Microsoft recommends temporarily disabling enforcement and enabling reporting to capture violations, then adding the required sources before turning enforcement back on.

Bottom line: CSP is no longer optional hygiene, it’s becoming a platform expectation. Think of it as a hardened perimeter for the front end of your Power Apps.

How CSP Works in Power Apps

Model‑driven & canvas apps (Dataverse environments)

When you enable CSP at the environment level, default directives are applied. Historically, these included wildcards and unsafe allowances (e.g., script-src * 'unsafe-inline' 'unsafe-eval') but Microsoft now offers a “Strict CSP” toggle that largely removes wildcards/unsafe directives and adds additional directives like img-src, connect-src, frame-src, base-uri, etc.

The strict defaults differ slightly between model‑driven and canvas apps, and Microsoft may adjust platform domain lists over time.

• Environment scope: A single setting impacts all apps in the environment, so you should pilot in Dev/Test, then use report‑only in Prod, then enforce when violations are resolved.
• What you can customize today: In the admin center UI, the customizable directive is frame-ancestors (add allowlisted host origins for embedding). You can also enable reporting and choose enforcement independently for model‑driven vs canvas apps.

Code apps (preview)

For code apps, you can configure a broader set of directives (e.g., script-src, connect-src, img-src, frame-src, font-src, style-src, etc.) and choose enforce vs report-only, either via the Power Platform admin center or the REST API.

Microsoft’s default policy includes safe baselines like default-src 'self', frame-ancestors 'self' https://*.powerapps.com, and locked‑down values like connect-src 'none' unless you add sources. If a default value is 'none', your custom values replace it; otherwise they’re appended.

Reporting 101

Turn on Enable reporting and supply a valid endpoint to receive JSON POSTs for CSP violations. Reporting works even when enforcement is off (i.e., report‑only mode), giving you a safe way to discover which sources your app actually needs before you enforce CSP.

Pro tip: Use report‑only in production for a few days to capture real‑world traffic, then reconcile violations with your allowlist. This is the fastest path to a policy that’s both secure and non‑breaking.

Step‑by‑Step: Configuring CSP in Power Platform

A) Configure CSP for Power Apps code apps (preview)

Option 1: Power Platform admin center (easiest)

1. Sign in to the Power Platform admin center → Manage → Environments → select your environment → Settings → Product → Privacy + Security → Content security policy → App.
2. Enable reporting and set your reporting endpoint (recommended first).
3. In Configure directives, keep defaults toggled on or add sources for items like script-src, connect-src, img-src, etc. Remember:
   • If a directive’s default is 'none', your custom list replaces 'none'.
   • Otherwise, your custom list is merged with the default.
4. Toggle Enforce content security policy on when you’ve validated there are no harmful violations.

Option 2: REST API (automation‑friendly)

Use the Power Platform Environment Management Settings API to get/set:

• PowerApps_CSPEnabledCodeApps (enforcement on/off),
• PowerApps_CSPReportingEndpoint (report target or null),
• PowerApps_CSPConfigCodeApps (JSON containing your directives).

Example payload shape for PowerApps_CSPConfigCodeApps:

{
  "default-src": { "sources": [{ "source": "'self'" }] },
  "script-src":  { "sources": [{ "source": "'self'" }, { "source": "https://cdn.contoso.com" }] },
  "connect-src": { "sources": [{ "source": "'self'" }, { "source": "https://api.contoso.com" }] },
  "img-src":     { "sources": [{ "source": "'self'" }, { "source": "data:" }] }
  // Add other directives as needed
}
``

Microsoft also provides PowerShell helper functions (Get-CodeAppContentSecurityPolicy, Set-CodeAppContentSecurityPolicy) that wrap the API for you; authenticate with Microsoft’s CLI, then patch directive lists or toggle enforcement/reporting as required.

What to allowlist for code apps (typical cases):

• CDNs for your scripts and styles (script-src, style-src).
• APIs your app calls (connect-src), including WebSocket endpoints (wss:) if used.
• Image hosts (img-src) and font providers (font-src).
• Embedding targets (frame-ancestors), if your app is framed.

Remember: After Microsoft’s January 2026 enforcement, external assets won’t load unless they appear in your directive allowlists—plan and test accordingly.

B) Configure CSP for model‑driven & canvas apps (Dataverse environments)

Enable, report, and enforce

1. In the admin center, navigate to Environment → Settings → Product → Privacy + Security → Content security policy. You’ll see pivots for model‑driven and canvas.
2. Enable reporting and add your endpoint to capture violations.
3. Choose whether to Enforce content security policy per app type (start in dev/test; use report‑only in prod; then enforce).
4. Customize frame-ancestors (the directive controlling who can embed your app). You can append hosts to the default ('self' https://*.powerapps.com) for approved embedding scenarios.

Common frame-ancestors allowlists (straight from Microsoft’s guidance):

• Microsoft Teams (Dynamics 365 app):

‍https://teams.microsoft.com/

https://teams.cloud.microsoft/

https://msteamstabintegration.dynamics.com/

• Outlook (Dynamics 365 App for Outlook):

Your Outlook Web App homepage origin, plus https://outlook.office.com and https://outlook.office365.com

• Embedding Power Apps in Power BI reports:

https://app.powerbi.com‍

https://ms-pbi.pbi.microsoft.com

Advanced (without UI):

You can set organization properties directly (IsContentSecurityPolicyEnabled, ContentSecurityPolicyConfiguration, etc.) via a script in dev tools. The payload is a small JSON object defining Frame-Ancestor sources. This path is useful for automation or on‑prem scenarios.

Practical Scenarios, Best Practices & Pitfalls

Scenario 1: “My code app uses an external API and CDN.”

• Set connect-src to include the API origin(s) and script-src/style-src for your CDN(s). Start by turning report-only on, exercise your app, collect violation reports, and then add the missing hosts. Once stable, enforce.
• Keep default-src 'self' and avoid blanket wildcards like * or https: unless you have a strong reason, wildcards weaken your policy.

Scenario 2: “We embed our app in Teams and Power BI.”

• Add the specific Teams and Power BI embed origins to frame-ancestors (see the exact hostnames above). Test both browser and desktop clients.

Scenario 3: “We want a safer default for all apps in this environment.”

• For model‑driven/canvas apps, enable Strict CSP to reduce unsafe-inline/wildcards where possible, and then layer in any required hosts. For code apps, rely on the default 'self' posture and selectively allow additional origins.

Scenario 4: “How do we test and iterate without breaking production?”

• Enable report‑only with a reporting endpoint to capture violations before enforcement. Roll this out in prod during a normal usage window to collect realistic telemetry, then tune your allowlist and flip enforce. This is Microsoft’s recommended enablement flow.

Best‑practice checklist

• Least privilege: Start with 'self' and add only what you need (cdn.contoso.com, api.contoso.com).
• Minimize unsafe keywords: Avoid 'unsafe-inline' and 'unsafe-eval' whenever possible. If you must allow inline JS, prefer hashes or nonces; note that nonce workflows are better documented for Power Pages, while code apps and model/canvas rely on directive allowlists and platform defaults.
• Separate concerns: Use specific directives (script-src, connect-src, etc.) rather than broad default-src changes. This limits blast radius.
• Iterate with reporting: Keep report‑only on for at least a few business days; analyze violations, then enforce.
• Document and automate: Store your directive lists in source control and manage them via the Settings API or PowerShell for repeatability.
• Align with broader security baselines: CISA’s Power Platform secure configuration guidance encourages environment‑level controls and systematic governance, CSP fits neatly into that posture.

Pitfalls to avoid

• Turning off a directive by accident. In the code apps UI, if you disable a directive and leave the source list blank, that directive is omitted from the policy (which can reduce protection). Make that choice intentionally.
• Assuming per‑app scope for model/canvas. The admin center setting is environment‑level; plan communications and test coverage accordingly.
• Embedding unsupported content. Some iframe scenarios are unsupported or constrained (e.g., iFraming content behind certain auth boundaries in model‑driven web resources); always validate your embedding approach.

Make CSP a Core Part of Your Power Platform Security Posture

CSP is one of the most impactful client‑side controls you can implement. In Power Platform, it’s now first‑class and environment‑wide, with richer control for code apps (preview) and safer strict defaults for canvas and model‑driven apps. The right rollout plan is straightforward:

1. Enable report‑only and capture real violations.
2. Allowlist only what you need (prefer 'self' by default).
3. Enforce, monitor, and iterate.

If you’d like a proven playbook, environment assessment, report endpoint setup, directive design, testing, and automation via API/PowerShell, we can help you implement CSP without slowing delivery.

People Also Ask: CSP for Power Apps (FAQ)

1. Does CSP break existing apps?

It can if you enforce without testing. Use report‑only mode to identify missing allowlist entries, then enforce. For code apps, this is particularly important due to the January 2026 enforcement posture.

2. Is CSP configured per app or per environment?

• Model‑driven & canvas: Environment‑level (Dataverse only). Settings apply to all apps in that environment.
• Code apps (preview): Also environment‑level, you configure defaults for all code apps, then specify per‑directive allowlists as needed.

3. What’s the difference between frame-ancestors and frame-src?

• frame-ancestors controls who can embed your app (parents).
• frame-src controls what your app can embed inside iframes.

Power Apps exposes frame-ancestors customization broadly (model‑driven/canvas) and more directives, including frame-src for code apps.

4. How do we collect violation logs?

Turn on Enable reporting and set a URL to receive JSON violation reports. Reporting works even if enforcement is off (report‑only).

5. Can we use nonces or hashes?

CSP nonces/hashes are a core web CSP capability, and Power Pages explicitly supports a nonce option in CSP for inline scripts. For code apps and model‑driven/canvas apps, Microsoft’s UI emphasizes allowlisting sources at the directive level rather than providing a nonce workflow, plan on externalizing scripts and avoiding inline JS for stricter policies.

6. Does CSP replace X-Frame-Options?

Yes, modern guidance is to use frame-ancestors in CSP (the newer, more flexible control).

7. How do we harden CSP without breaking styling?

• Keep style-src 'self' and add trusted CDNs as needed.
• Avoid 'unsafe-inline' where possible; if you must keep it (common with legacy components), track it as a tech‑debt item to remove. Start strict in dev/test and expand only when necessary.

8. Where do we configure CSP for Power Pages sites?

Use the Portal Management app and the HTTP/Content-Security-Policy site setting. Power Pages also supports nonce for inline scripts; just add script-src 'nonce' as documented. This is separate from the Power Apps environment settings discussed above.