Security is important. That's why we always want to be sure we are using SSL (https) when connecting to a web application. But, did you know that even when we are connecting to a web application securely, there is still a tiny sliver of vulnerability left?
This is because even if a website or application enforces https connections, it is still possible to make an http request first. The user may type in http directly, or click on an insecure link. Additionally, if the user only puts in the domain name (as is common), then http will be the default.
Usually, this request will be redirected when the server receives the request, the browser will remember this, and all will be good... but during that one moment, the communication between the browser and the server is vulnerable. But, when the browser cache is cleared or the user has a fresh install, this gap is opened again.
There are ways to mitigate this - most popularly by adding the redirect at the CDN layer before the request even hits the server. A CDN redirect is very easy, very common, and honestly it is more than enough to cover this gap in all but the most extreme and unlikely instances. But what if there was a way to close this gap completely? What if you could force the redirect before the request left the browser? That would make it impossible to send a server request from the browser without a secure connection at all.
You may not have been aware of this option, but it is possible, and Appsmith has implemented it. This is a brief story about how Appsmith was added to the Chrome HTTP Strict Transport Security list.
What is HTTP Strict Transport Security?
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites and their users from certain types of attacks, particularly those related to insecure communication over the HTTP protocol. HSTS aims to ensure that web browsers always use a secure connection (HTTPS) to communicate with a website, even if the user enters an HTTP URL or clicks on a link that uses HTTP.
Protip: If you own a site that you would like to see included in the preloaded HSTS list you can submit it at https://hstspreload.org.
Here's how HSTS works:
- Initial Visit: When a browser visits a website for the first time and the website's server supports HSTS, the server includes an HSTS header in the response. This header informs the browser that it should only access the website over HTTPS for a specific period of time.
- Subsequent Visits: During subsequent visits, the browser remembers the HSTS policy for the website. This means that even if the user enters an HTTP URL or clicks on an HTTP link, the browser will automatically convert the request to HTTPS before sending it to the server.
- Expiration: The HSTS policy includes a "max-age" directive that specifies how long the browser should remember the policy. Once the max-age time expires, the browser will no longer enforce the HSTS policy for that website.
Why should we care about HSTS?
HSTS provides several security benefits:
- Mitigates Man-in-the-Middle Attacks: HSTS helps prevent attackers from intercepting traffic and downgrading secure HTTPS connections to insecure HTTP connections. Without HSTS, an attacker might be able to intercept the initial connection and force the browser to communicate over HTTP.
- Enhances User Privacy: HSTS ensures that user interactions with a website are always encrypted, helping to protect sensitive information from being intercepted.
- Prevents Cookie Theft: HSTS prevents attackers from stealing cookies (session data) by forcing all requests to be sent over HTTPS.
- Minimizes Vulnerabilities: By enforcing HTTPS, HSTS reduces the risk of attacks that exploit insecure communication, such as session hijacking and data interception.
HSTS can be implemented by web developers and server administrators by adding the appropriate HTTP header to server responses. The header contains the "Strict-Transport-Security" field with the HSTS policy parameters, including the max-age directive.
Appsmith has been added to the preload list
Appsmith web infra, the website, Appsmith prod, Appsmith release, the community portal, etc., etc., anything that's opened on **.appsmith.com, can now only ever run on HTTPS.
Wasn't that always true? Indeed it was. But when a user opens http://appsmith.com, the browser makes an HTTP request to the server, and the server responds with a redirect, telling the browser to go to https://appsmith.com. The communication between the user, and our server is only secure when the URL has https://, not when it has http://.
So, that one initial request is still unsafe. Adding to the preload list solves for that.
HSTS is supported in Google Chrome, Firefox, Safari, Opera, Edge and IE (view compatibility matrix).
How? The domain appsmith.com will now be hard-coded into participating browsers, into a list called an "HSTS Preload List". Now, when opening http://appsmith.com, the browser checks if appsmith.com is present in this hard-coded list, and if yes, it won't even make a single HTTP request. It'll immediately switch to HTTPS, and no communication between browser and server is ever unsafe. This applies to any and all subdomains of appsmith.com, like www.appsmith.com, app.appsmith.com, community.appsmith.com, etc.
It's worth noting that once a domain is added to the browser's HSTS preload list, it can be challenging to remove, so careful consideration is needed before making this decision.
What does this mean for you?
At a basic level, you don't need to worry about any of this. Your life will continue along as before. However, we've closed yet another tiny vector in our ever-increasing commitment to security. We worry about these things so you don't have to!
As an Appsmith user, you can continue to build and deploy your apps on the cloud version with even more confidence. As a self-hosted user, you can look at ensuring your organization has https requirements at the CDN or network level, and potentially can add your domains to the HSTS preload list as well!
Of course, you could argue that this is really an extreme and unnecessary step to take in the name of security, and you may be right. However, that won't stop us from doing our best to implement every reasonable security measure we can.
