.png){kind=logo}
Security Settings
- 28 Nov 2022
- 2 Minutes to read
- Print
- DarkLight
- PDF
Security Settings
- Updated on 28 Nov 2022
- 2 Minutes to read
- Print
- DarkLight
- PDF
Article Summary
The security settings allow you to tune the webserver security. Changing any of these settings could impact the usage of the portal.
HTTP Strict Transport Security (HSTS)
A webserver can send a so called HSTS header to a browser to indicate that the browser should only contact the webserver over a secure channel. This will help prevent man-in-the-middle attacks.. The options for preloading and sub domains are there in case the parent domain want to apply to a HSTS preload list like hstspreload.org.
| Name | Description |
|---|---|
| Send HSTS header | If HSTS should be enabled |
| Number of days | The number of days the browser should remember this setting. If HSTS is not desired anymore after it has been activated, a value of zero should be provided to tell the browser to forget any HSTS policy that have been associated with this zone I the past |
| Enable preloading | If preloading should be enabled. Custom actions are required, for more information: scotthelme.co.uk/hsts-preloading and hstspreload.org |
| Sub domains | If the policy should apply to sub domains |
You can have trouble reaching a zone if a zone certificate expires and HTST is enabled, please refer to your browser documentation how to remove the HSTS state in the browser for the zone domain.
Content Security Policy (CSP)
Browsers nowadays allow for a vast amount of different content to be displayed on a page. Ranging from external JavaScript to even web assembly. With a CSP policy the browser is told what should be allowed and what not. By restricting the kind of content a page can host, the amount of attack vectors can be greatly reduced.
There are four modes the CSP policy can operate in:
- Disabled: no CSP is send to the browser and the browser will not restrict the content based on CSP.
- Enforced, no reporting: The browser will restrict the content and will not report any content that has been blocked.
- Enforced and reporting: The browser will restrict the content and will report any content that has been blocked.
- Reporting, no enforcing: The browser will not restrict the content but will report any content that violate the policy.
For the reporting to work, a report url should be specified that can receive the browser’s reports and display them in a useful way. An example of a free service that provides this is report-uri.com
With CSP, we can also prevent other websites to embed the Liquit Workspace. You can specify trusted websites who can embed Liquit Workspace.
| Name | Description |
|---|---|
| Enforce the policy | If a browser should enforce the policy. |
| Report violations | If a browser should report any violations of the policy. |
| Report url | The url where the violations reports should be send to. |
| Upgrade insecure requests | If the policy should include directives to upgrade insecure requests (HTTP) en enforce that all the resources should be accessed over HTTPS. |
| List of websites that are allowed to embed the zone | Include directives in the policy to allow the specified websites to embed Liquit via an iFrame. |
Cross-Origin Resource Sharing
With CORS you can limit the number of sources that can access the Liquit REST API. It's recommended to restrict who can authenticate against Liquit. Only allow trusted sources, for example Microsoft Teams if you wish to use the Liquit Teams Application.
| Name | Description |
|---|---|
| Restrict cross origin authentication | If checked, this will enable the checks for allowed authentication sources. |
| List of websites that are allowed to authenticate against the zone | A list of websites that are still allowed to authenticate while others are prevented. |
Was this article helpful?