TLS
TLS 1.0/1.1 have been a security risk for some time now. They do not support modern cryptographic algorithms and are susceptible to certain types of attack. We’ve spoken in past briefings about TLS support in web servers and moving to adopt TLS 1.2.
Firefox will be disabling TLS 1.0/1.1 in March 2020. Chrome will do the same in v81 (early in 2020) and will begin displaying warnings beforehand in v72, which was released this month.
Review the versions of TLS supported by your web servers and ensure that they support at least v1.2. Consider disabling support for older versions – there is no issue with this if you do not need to support IE 10 or below.
“Not secure”
As you may have noticed, web browsers have started labelling websites that load without https as “Not secure” in the address bar. This is the latest incentive for website owners to install a security certificate (as we’ve mentioned before, free ones are available from https://letsencrypt.org), even if they’re not handling any form submissions.
As of August 2018, over half of the Alexa top 1 million sites were redirecting to https, up from 38% in February that year.
Https is an easy win and should be default for new websites and applications. Some hosts and cloud providers offer auto-renewing LetsEncrypt certificates to make things even easier. If you’re not planning on using a certificate, make sure you have a good reason.
Website browser Feature Policy
The W3C have published a new draft HTTP header specification Feature Policy, which allows developers to selectively enable and disable the use of various browser features and APIs with their site.
Examples of what you can do with Feature Policy:
• change the default behaviour of autoplay on mobile and third-party videos
• restrict a site from using sensitive APIs like camera or microphone
• allow iframes to use the fullscreen API
• block the use of outdated APIs like synchronous XHR and document.write()
• ensure images are sized properly and not too big for the viewport
Along with the more obvious benefits of being able to control these features, there is also peace of mind that if malicious code were to run on the site, it would not be able to access any unexpected APIs. In addition, you might find some application hosts or marketplaces requiring that your application not use certain browser APIs, which you could easily enforce and evidence through these policies.
Feature Policy is a draft specification and currently only supported in Chromium-based browsers, but it’s a sure thing that others will follow soon. You can find out more at https://developers.google.com/web/updates/2018/06/feature-policy.
Be aware of this new option and if your application would benefit from this level of control then make use of it. It’s very low effort to build in, especially as you should already be adding Content Security Policy headers. However, until browser support improves, you’ll need to include some more laborious fall-back control too.