Face Client SDK violates strict CSP header

Mike Roberts 0 Reputation points

We're attempting to deploy the Azure AI Vision Face Client SDK (version 1.4.6) in an environment with a fairly strict content security policy (CSP), and seeing the following error caused by the execution of the Function constructor in "AzureAIVisionFace_SIMD.js", which is one of the asset files the SDK instructions suggest must be bundled with the application for the liveness detection to function:

"EvalError: Evaluating a string as JavaScript violates the following Content Security Policy directive because 'unsafe-eval' is not an allowed source of script..."

    at new Function (<anonymous>)

    at createJsInvoker (AzureAIVisionFace_SIMD.js:1:76013)

    ...

    at registerType (AzureAIVisionFace_SIMD.js:1:52084)

This causes an "unexpected" error to be returned from the SDK, and ultimately failure for the component to load. When adding "unsafe-eval" to the CSP everything is working correctly, but given the security focus of our platform and this library I'd be surprised if adding "unsafe-eval" to this policy would be your recommended approach.

Do you have any advice for mitigating this, or are you able to advise on if this is an implementation issue on our part?

  1. SRILAKSHMI C 19,110 Reputation points • Microsoft External Staff • Moderator

    Hi Mike Roberts,

    Did you get any chance to review the above response. Do let me know if you have any further queries.

    Thank you!

Sign in to comment

1 answer

  1. SRILAKSHMI C 19,110 Reputation points • Microsoft External Staff • Moderator

    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

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

    Thank you!

    0 comments No comments
    Sign in to comment
Sign in to answer

Your answer