HTTP has an addition called "Strict Transport Security" (commonly abbreviated HSTS) that is intended to mitigate man-in-the-middle attacks by having the browser know that a site should never be accessed without TLS¹.
It would be beneficial if Web Access could use this feature to increase the security for users.
The main blocker for this is that enabling it affects every service with the same host name². That means if Web Access is running on port 300 and enables this, then browsers will refuse to communicate without TLS with another web server running on e.g. port 80 on the same machine.
As such, we cannot add this unconditionally. It must be a configuration option that is enabled, only when the side effects are acceptable.
¹ Supposedly also never with a certificate exception
² The recommendation is also to enable it for all subdomains, exacerbating the problem
Also note that HSTS has a major design flaw; it only works if the browser has visited the site before. Otherwise, it has no knowledge that HSTS is enabled and a man-in-the-middle attack is still possible.
Browsers are trying to mitigate this issue by preloading a list of HSTS enabled hosts. However, this requires manual registration for each domain.
The registration is done here: https://hstspreload.org/
An interesting reference is the settings that VMware Horizon provides for things like this:
NICE DCV solves this by having a very general setting of extra HTTP headers:
This doesn't seem very user-friendly, though, as it requires the users to have detailed technical knowledge about these things. I also wonder how fragile this is if the user adds a header that breaks functionality in the web services.