HUE security improvements

Published on 22 September 2016 in - 4 minutes read - Last modified on 06 March 2021 - Read in jp

Hello HUE admin,

Recently we have added many security options in HUE. These are turned on by default when possible.

This document describes some of the fixes and enables Hue administrators to enforce and manage secure HUE installation. Whenever a browser requests a page from a HUE web server, HUE responds with the content along with HTTP Response Headers. Some of these headers contain content meta data such as the content-encoding, cache-control, status error codes, etc. Along with these are also HTTP security headers that tell your browser how to behave when handling HUE's content. For example, by using the strict-transport-security you can force the browser to communicate solely over HTTPS.

Content-Security-Policy: header

The new Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header. (Read more here:


secure_content_security_policy="script-src 'self' 'unsafe-inline' 'unsafe-eval' \* \* \* data:;img-src 'self' \* \* http://\* \* \* data:;style-src 'self' 'unsafe-inline';connect-src 'self';child-src 'self' data:;object-src 'none'"

#In HUE 3.11 and higher it is enabled by default.

If you want to turn off content-security-policy header then use following value. (Beware use it on your own risk)



#(Beware use it on your own risk)

If you want to disable declaring what dynamic resources are allowed to load via a HTTP Header then you can use following value. (Use it on your own risk)


secure_content_security_policy="default-src 'self' 'unsafe-eval' 'unsafe-inline' data: *;"

#(Use it on your own risk)


]1 Example of image content blocked

Server: header

HUE now minimizes disclosure of web server information to minimize insight about web server it's version or other details. No change is needed from end user. Produces following HTTP response header :


These HTTP response headers are generated after above security fixes.



x-xss-protection:1; mode=block

Content-Security-Policy:script-src 'self' 'unsafe-inline' 'unsafe-eval' \* \* \* data:;img-src 'self' \* \* http://\* * data:;style-src 'self' 'unsafe-inline';connect-src 'self';child-src 'self' data:;object-src 'none'

Strict-Transport-Security:max-age=31536000; includeSubDomains


X-Content-Type-Options: header

Some browsers will try to guess the content types of the assets that they fetch, overriding the Content-Type header. To prevent the browser from guessing the content type, and force it to always use the type provided in the Content-Type header, you can pass the X-Content-Type-Options: nosniff header.



#In HUE 3.11 and higher it is enabled by default.

X-XSS-Protection: header

Some browsers have ability to block content that appears to be an XSS attack. They work by looking for Javascript content in the GET or POST parameters of a page. To enable the XSS filter in the browser, and force it to always block suspected XSS attacks, you can pass the X-XSS-Protection: 1; mode=block header.



#In HUE 3.11 and higher it is enabled by default.



Example of the new headers received with above options

Strict-Transport-Security: header

If your HUE site offers both HTTP and HTTPS connections, most users will end up with an unsecured connection by default. For best security, you should redirect all HTTP connections to HTTPS. For sites that should only be accessed over HTTPS, you can instruct newer browsers to refuse to connect to your domain name via an insecure connection (for a given period of time) by setting the “Strict-Transport-Security” header. This reduces your exposure to some SSL-stripping man-in-the-middle (MITM) attacks. In HUE it is now enabled by default to switch to https if https is enabled.

Delivers csrftoken and session cookies with secure bit set

HUE now delivers csrftoken and session cookies with secure bit set if possible. When a secure flag is used the cookie will only be sent over HTTPS.

Session cookie with secure bit while csrftoken is not

Supports Wildcard certificates

Hue now supports Wildcard certificates. It adds the missing functionality of validating wildcard certificates and certificates with SANs (subjectAlternativeName).

A single wildcard certificate for *, will secure all these domains:


Instead of getting separate certificates for sub domains, you can use a single certificate for all main domains and sub domains and save your money.

Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops), these domains would not be valid for the certificate:


Fixed Arbitrary host header acceptance

Fixed Arbitrary host header acceptance in Hue. Now one can set host/domain names that the Hue server can serve.




\# your own fqdn example: allowed_hosts="*"

\# or specific example: allowed_hosts=","

Fixed Denial-of-service possibility by filling session store

Django CVE-2015-5143</a>

Fixed The utils.html.strip_tags function in Django can cause a denial of service

Django CVE-2015-2316</a>

comments powered by Disqus

More recent stories

03 May 2023
Discover the power of Apache Ozone using the Hue File Browser
Read More
23 January 2023
Hue 4.11 and its new dialects and features are out!
Read More