Skip to content

Face SDK Security

This documentation provides guidelines to ensure the robustness and safety of your Face SDK implementation.

Securing Network Connections

For secure data transmission, use HTTPS connections:

Use HTTPS connections

Authentication of Requests

The Face SDK Web Service does not inherently support authentication and processes all incoming requests without discrimination. To mitigate the risk of unauthorized or malicious usage, it is strongly recommended not to expose the Web Service to public Internet access.

For enhanced security, you need to deploy the Web Service within a closed perimeter, like a Demilitarized Zone (DMZ), and configure a proxy server at the entrance point:

Authentication of requests and demilitarized zone

The simplest method to establish secure access is as follows:

1. Set up Basic authentication on the proxy server. This authentication mechanism requires clients to provide valid credentials to access the Web Service.

2. When sending a request to the Web Service, include the appropriate authentication header:

3. The incoming request is authenticated by the proxy server.

4. If the authentication process succeeds, the request is forwarded to the Web Service for processing.

5. If authentication fails, the request is rejected.

Content Security Policy for Web Components

Content Security Policy (CSP) helps prevent harmful content injection into web pages by controlling which scripts and resources can be loaded and executed.

Face SDK Web Components support CSP nonce. A nonce is a unique cryptographic token generated on the server side and included both in the CSP header and in the page content. The browser allows only scripts with the matching nonce to run.

How Content Security Policy Nonce works

In addition, Face SDK Web Components use WebAssembly to run Regula's C++ code compiled for browser execution. Because of this, strict CSP configurations must allow WebAssembly execution by using wasm-unsafe-eval or, where required for browser compatibility, unsafe-eval.

This requirement is expected and is related to WebAssembly execution in the browser. It does not mean that the component runs untrusted code or evaluates arbitrary customer-provided scripts.

For detailed Web Components security requirements, including CSP examples and package resource configuration, see:

Certificate Pinning

Certificate Pinning is a crucial security mechanism that bolsters server identity trust in mobile applications. By implementing сertificate pinning, applications can establish a secure and verified connection with a designated server, mitigating the risks associated with potential man-in-the-middle attacks.

Certificate Pinning on Mobile schema

Mutual TLS

Mutual TLS (mTLS) is an extension of the standard TLS protocol in which not only the server, but also the client device, proves its identity during connection establishment.

This helps protect the Face SDK Web Service from connections initiated by unauthorized devices. When mTLS is enabled, the client device must provide a certificate, which is then verified by the server before the connection is accepted.

As a result, only devices with trusted client certificates can establish a connection to the server.

To establish an mTLS connection, the feature must be configured on both the server and the client.

Mutual TLS scheme

Required Endpoints

To run Face SDK scenarios (for example, Liveness), the client-side component (Mobile SDK or Web Components) must be able to reach the Face SDK Web Service endpoints.

The exact set of endpoints depends on the enabled scenario and feature set.