Security Settings
  • 28 Nov 2022
  • 2 Minutes to read
  • Dark
    Light
  • PDF

Security Settings

  • Dark
    Light
  • 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.

NameDescription
Send HSTS headerIf HSTS should be enabled
Number of daysThe 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 preloadingIf preloading should be enabled. Custom actions are required, for more information: scotthelme.co.uk/hsts-preloading and hstspreload.org
Sub domainsIf 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.

NameDescription
Enforce the policyIf a browser should enforce the policy.
Report violationsIf a browser should report any violations of the policy.
Report urlThe url where the violations reports should be send to.
Upgrade insecure requestsIf 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 zoneInclude 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.

NameDescription
Restrict cross origin authenticationIf checked, this will enable the checks for allowed authentication sources.
List of websites that are allowed to authenticate against the zoneA list of websites that are still allowed to authenticate while others are prevented.

Was this article helpful?

What's Next