Skip to main content

Embedded Analytics - Security Matters


For security purpose, it is recommended to use HTTPS when embedding Holistics in your side.

Secret Key

The key we issue you in step 2 is to sign your payload with HMAC 256 signature mechanism. This signature is for us to check the payload's integrity and prevent people from tampering and modifying your payload during the request.


Why JSON Web Token (JWT)?

Our Embedded feature is designed for use cases where our clients want to embed a dashboard into their own application, where when each of their customers log in they will see different data, i.e a restaurant ordering SaaS system will use Holistics Embedded to provide analytics to their individual restaurant customers, where each restaurant only sees data related to their own restaurant.

Since cross-customer data security is important, there is a need for the extra work required to ensure encryption is properly set up.

In short, the additional coding effort is there to ensure:

  • Multi-tenancy data permission: Making sure each of your customers will see data related to themselves only.
  • The URL will expire at some point in the future, preventing anyone having access to the URL to pull the data.

Token Expiration

You must specify a time to expire your issued JWT. The recommended expired time is 24 hours after you issue the token. The reason behind this is to deal with the situation when someone steals the JWT of your customer (not difficult to do so) and issue it elsewhere. The stolen token will be expired in a short time so damage is minimized.

Sensitive Data

Note that the JWT only allows us to check the integrity of the received payload. No cryptography is involved in JWT, and your payload's information is not securely concealed from others. Please do not include any sensitive data inside the payload.

Enforcing Data Access Control the right way

Although it seems that both Permission Settings and Controls Settings have the ability to restrict user's access to data, in reality they serve two different purposes.

Here is the general rule of thumb to help you decide which one to use:

  • Permission Settings should be used if you want to enforce data access restriction on your embedded analytics viewers so that they can only view a subset of your data.


    Permission Settings should always be used for security best practice.

  • Controls Settings is a convenient method to set up default new values for your embedded dashboard. It helps you override existing dashboard filters' default values, as well as hide some filters to make your customer-facing dashboards cleaner.


    Although we do not provide the UI for the embedded viewers to modify this settings' values, it is still possible for users to tamper with these values on their ends.

The differences between the two settings are summarized below.

Permission SettingsControls Settings
PurposeData Access Control                                    Override filter values or hide filters for aesthetics purposes
Data Restriction LevelDataset level (Strict)UI only (Can be tampered)

Let's demonstrate their key differences by inspecting a dashboard with multiple country values as shown in the example below. If you set the Permission Setting for country_name to Vietnam, your country filter will only show the value Vietnam. It will return no value if you try to change the filter value to another value other than Vietnam.

By contrast, if you pick Controls Settings to restrict access, clever users can tamper with the country_name and are able to access unauthorized data from other countries.

Filter vs Permission

Let us know what you think about this document :)