CSP and Smart UI Security Recommendations

Content Security Policies

When embedding the Smart UI into your applications, below are the CSP policies that need to be taken into account, in case you use CSP restrictions.

FrankieOne Content Security Policy

<meta http-equiv="Content-Security-Policy" content="
  default-src 'self' *.frankiefinancial.io;
  style-src 'self' fonts.googleapis.com;
  font-src 'self' fonts.gstatic.com;
  script-src 'self' maps.googleapis.com;
  report-uri *.ingest.sentry.io *.clarity.ms;
  img-src 'self' assets.frankiefinancial.io sync.onfido.com data:;
  connect-src blob: *.onfido.com wss://*.onfido.com;
" />

Onfido CSP

When using the smart UI with the idScanVerification option turned on, you'll also need to take into account Onfido's Content security policies which can be found in their documentation:
https://documentation.onfido.com/sdk/sdk-csp-guide/#content-security-policy

Hotjar CSP

If the disableThirdPartyAnalytics option is not set to true, then you also need to add policies for Hotjar, as specified in their documentation:
https://help.hotjar.com/hc/en-us/articles/115011640307-Content-Security-Policies

Verify the page where Smart UI is installed using referrer headers

A "referrer" field can also be included in the body of the request to /auth/v2/machine-sessions, where the value is a pattern to be used to verify the URL of the page where Smart UI is installed. The referrer sent by the browser must match the referrer URL pattern for the Smart UI to be successfully authenticated.

For increased security, any website using the Smart UI should generate a token configured with referrer pattern and should send the referrer header.

For the Smart UI only, this is just a recommendation, but in case you wish to enable idScanVerification and use Onfido, they require referrer header to be available.

The referrer is based on the Google Chrome match pattern URLs. URLs can also contain wild card characters. For more information, read Chrome Developer Match patterns.

Permitted referrer patterns are as follows:

An example of a valid referrer is

https://*.example.com/example_page/*

While it is not required, this option is highly recommended, as it secures the short-lived token from being used by unknown sources and guarantees that other malicious websites cannot re-use the JWT in case it gets lost.

The only valid case not to use a referrer is in development environments, or in case the frontend application is configured not to send Referrer (sic) Headers. More about this can be read here.

Body

{
    "referrer": "https://the-company.com" || "*://the-company.com/*"
}