APIM Developer Portal – Content Security Policy (CSP) Violation Issue

Question

We are using Azure API Management (APIM) along with the Developer Portal. Recently, a security scan identified a violation related to an incorrect Content Security Policy (CSP).

We have been asked to investigate and remediate this issue; however, we were unable to find sufficient guidance in the official Microsoft documentation regarding this specific concern.

Additionally, from the CSP configuration settings, we understand that enabling the CSP option would result in configuring the default-src directive. We are unsure how this might impact the existing setup and whether it would address the reported violation without affecting current functionalities.

Answer 1

Hi @Neelavathy

Thank you for reaching out to Microsoft Q&A.

In Azure API Management (APIM), the Developer Portal supports Content Security Policy (CSP) through an HTTP response header that controls which external resources (such as scripts, styles, images, and API calls) the browser is allowed to load. By default, CSP is disabled in APIM, which often leads security scans to report a violation for a missing or weak CSP configuration. When CSP is enabled with only the default-src directive, it acts as a fallback for all resource types. This can unintentionally block essential portal resources—such as authentication redirects, API test console calls, and Azure-hosted scripts—causing the Developer Portal to malfunction. Due to limited official documentation, enabling CSP without a staged approach can result in breaking existing portal functionality instead of resolving the security finding.

Refer below points to resolve this issue or this is the workaround:

Enable CSP in Report-Only mode first Enable Content Security Policy in Report-Only mode so that violations are logged in the browser developer console without blocking any resources. This allows you to safely identify which resources the Developer Portal depends on before enforcing CSP.

Review CSP violation logs to identify required sources Use the browser’s developer tools (F12) to review CSP warnings. These messages clearly indicate which directive (for example, script-src, connect-src, or style-src) and which domain is being blocked. This helps determine exactly which sources must be allowed.

Avoid relying only on default-src Do not use a restrictive default-src alone (such as 'self'). Instead, define explicit directives like script-src, style-src, connect-src, img-src, and frame-src. This prevents unintended blocking of portal features such as OAuth sign-in, API testing, and embedded documentation.

Gradually enforce CSP after validation Once all required domains are identified and added, switch CSP from Report-Only mode to Enforced mode. This approach satisfies security scan requirements while ensuring that existing Developer Portal functionality remains unaffected.

Answer 2

In Azure API Management and its Developer Portal, Content Security Policy (CSP) behaves like in other Microsoft web properties: it is an additional HTTP header that restricts which resources (scripts, styles, images, frames, etc.) the browser is allowed to load. The default-src directive is the fallback for any resource type that does not have its own explicit directive.

To investigate and remediate the scan finding, use the same approach documented for other Power Platform/Power Pages properties:

1. Start in report-only mode (if available in your setup)
   Configure CSP in report-only mode first so that violations are logged but nothing is blocked. This is the recommended pattern:
   • Use a Content-Security-Policy-Report-Only header (or equivalent setting) to define the policy.
   • Review the browser developer tools console for CSP violation messages and, if you configure a reporting endpoint, review the reports there.
2. Interpret the violations from the scan and browser console
   CSP violations will tell which resource type and which URL are being blocked. For example, similar to the Commerce example:
   • If a script is blocked, the violation will reference script-src.
   • If a stylesheet is blocked, it will reference style-src.
   • If inline scripts are blocked, you may see messages about unsafe-inline or nonce issues.
   Use these messages to decide which domains or patterns must be allowed and which should remain blocked.
3. Understand the impact of enabling default-src
   When CSP is enabled and only default-src is configured:
   • default-src acts as the baseline for all resource types that do not have a more specific directive.
   • A restrictive default-src (for example, only 'self') will block any external scripts, images, fonts, frames, or XHR/WebSocket connections unless you explicitly add more specific directives (script-src, style-src, img-src, connect-src, frame-src, etc.) or extend default-src to include the required domains.
   From the Power Platform and Power Pages guidance:
   • Default policies typically allow 'self' plus required platform domains and then add more specific directives as needed.
   • Overly broad wildcards (for example, https: everywhere) are discouraged; instead, add only the specific domains required.
4. Incrementally extend the policy to satisfy the scan without breaking functionality
   Follow the same pattern as in the Power Pages and Commerce guidance:
   • Start with a strict but functional baseline (for example, 'self' and required platform domains in default-src or script-src/style-src).
   • For each violation:
     • Confirm the external resource is trusted and required.
     • Add the specific domain to the appropriate directive, not just to default-src.
   • Examples from the context that illustrate this pattern:
     • Allowing external scripts:

              script-src 'self' content.powerapps.com content.powerapps.us content.appsplatform.us content.powerapps.cn 'nonce' https://blocked-domain.com;
       

     • Allowing external stylesheets:
       • Add the stylesheet’s domain to style-src.
     • Allowing images or fonts:

              img-src 'self' https: data:;
              font-src 'self' https://fonts.gstatic.com https://fonts.googleapis.com;
       

     • Allowing frames (for embedded content):

              frame-src 'self' https://www.youtube.com https://app.powerbi.com;
       

5. Avoid common pitfalls
   Based on the CSP best practices in the context:
   • Avoid unsafe-inline for scripts; prefer nonce-based or external scripts.
   • Use specific domains instead of broad wildcards like https: where possible.
   • Regularly review and tighten the policy as dependencies change.
6. Roll out to enforcement mode
   After verifying that no critical functionality is blocked in report-only mode:
   • Move the policy to enforcement (Content-Security-Policy header or equivalent setting).
   • Continue monitoring browser console and any reporting endpoint for new violations.
7. How this addresses the scan finding
   A scan that reports an “incorrect” CSP typically expects:
   • A CSP to be present at all (not missing), and
   • A CSP that is not overly permissive (for example, not using * or https: everywhere, and not relying on unsafe-inline/unsafe-eval unless strictly necessary).
   By:
   • Enabling CSP,
   • Defining a restrictive default-src and specific directives for scripts, styles, images, frames, and connections, and
   • Removing unnecessary wildcards or unsafe directives,
   the policy will generally satisfy security scanners while preserving Developer Portal functionality.

If the Developer Portal has a UI toggle that “enables CSP” and sets only default-src, treat that as a starting point, then extend with explicit directives (as shown above) based on actual violations observed in report-only mode.

---

References:

• Manage your site's Content Security Policy
• Manage Content Security Policy (CSP)
• How to: Configure Content Security Policy
• Content security policy