Face Client SDK violates strict CSP header

Hello Mike Roberts,

Welcome to Microsoft Q&A and thank you for reporting this issue to us.

You’re not misconfiguring CSP, this behavior is caused by how the Azure AI Vision Face Client SDK (v1.4.6) is implemented.

The error occurs because the bundled file AzureAIVisionFace_SIMD.js uses the Function constructor (dynamic code generation). Browsers treat this the same as eval(), and under a strict CSP policy that does not allow:

script-src 'unsafe-eval'

the execution is blocked, resulting in the SDK failing to initialize.

This is expected behavior under a hardened CSP configuration.

Why This Happens

The SIMD build used for liveness detection is likely generated via a toolchain such as Emscripten and uses runtime JS invocation wrappers for WebAssembly bindings. These wrappers rely on dynamic function construction, which violates strict CSP rules.

So this is a library design constraint, not an issue in your CSP implementation.

Is Adding 'unsafe-eval' Recommended?

From a security standpoint, broadly enabling 'unsafe-eval' is not ideal. It increases exposure to XSS-style attacks and weakens your CSP guarantees. For security-focused platforms, this is typically avoided unless tightly scoped.

Recommended Mitigation Options

1.Check for an Alternative Build

Before modifying CSP:

• Verify whether a non-SIMD build exists.

Check if a CSP-compliant or non-eval variant is available.

Confirm whether a newer SDK version has refactored this behavior.

Upgrading or switching builds is the cleanest solution if available.

2.Scope CSP Relaxation

If no alternative build exists, avoid globally enabling 'unsafe-eval'. Instead:

Isolate the liveness component in a sandboxed iframe.

Apply a relaxed CSP only to that specific route or origin.

Limit exposure strictly to the required asset context.

This preserves overall platform security while allowing the component to function.

3.Consider Architectural Alternatives

If CSP cannot be relaxed under any circumstance:

Evaluate performing liveness validation server-side.

Use REST APIs instead of the browser SDK (if feasible).

This avoids client-side dynamic code execution entirely.

4.Additional Security Hardening

If you must allow 'unsafe-eval' in a constrained context:

• Ensure Subresource Integrity (SRI) is implemented where applicable.
• Lock down script-src to trusted origins only.
• Avoid combining 'unsafe-eval' with permissive inline script policies.

Recommended Step

Since this involves security posture and SDK design:

Check the latest SDK release notes.

If no CSP-safe variant exists, raise a support request asking whether a non-eval build is planned for enterprise environments.

Given the security-sensitive nature of identity and liveness verification, your concern about enabling 'unsafe-eval' is valid and reasonable.

Please refer this

• Azure AI Face service
• Face API Pricing
• Shared responsibility for Face liveness detection

I hope this will be helpful to you. Please feel free to contact me if you have any further questions.

Thank you!