Using HTTPS in Your Development Environment

Why should you use HTTPS for development? How can you set it up? This article will explain (almost) everything.

The HTTPS protocol is mandatory for any website or web application. It guarantees trust and security, and its wide adoption is due to the effort of browser providers and other supporters. However, many developers still use HTTP in their development environment. Why should you switch to HTTPS if it's not a production environment? Let's discuss.

Why Use HTTPS During Local Development?

Hopefully, you use HTTPS in your production environment since security is a primary concern for your web application. But why should you enable HTTPS in your local development environment? You are comfortable with your http://localhost. What are the security concerns in your local environment?

Check out this blog post to learn more about how HTTPS works.

There are different reasons to enable HTTPS, even for your localhost. Let's take a look at some of them.

Environment parity

The first and perhaps most logical reason is that the development environment should be similar to the production environment. This is one of the main principles of modern software development and deployment. It's one of the tenets of the twelve-factor methodology: dev/prod parity. Having development and production environments configured similarly helps reduce the risk of experiencing issues in production that you cannot find in development.

For example, suppose you are using a JavaScript library from an HTTP-based CDN. Everything works as expected in your local development environment. However, in your HTTPS-based production environment, things may go differently. You have mixed content in your pages, i.e., your page is composed of content delivered through HTTPS and content delivered through HTTP. Browsers may refuse to load an HTTP-based resource from an HTTPS-based page. This is a security measure to prevent HTTPS downgrade attacks. It is just a simple example of an issue you can get only in your production environment. Other hard to detect problems could arise if you keep different protocols in the two environments.

Strong security policies

Enabling HTTPS in your production environment isn't enough to keep security for your application and the data it handles. I mentioned earlier the HTTPS downgrade risks your application may be exposed to. To enforce your application avoiding mixed content and blocking insecure requests, you should use Content Security Policy (CSP). This standard security layer helps mitigate certain types of attacks. In particular, it prevents possible unintentional protocol switches.

To learn more about Content Security Policy (CSP), check out this article explaining how to prevent protocol switches and this one about preventing XSS attacks.

If you use CSP to prevent your application from switching from HTTPS to HTTP, you need to use HTTPS in both production and development environments. The CSP directives wouldn't work in an HTTP-based environment. In other words, if you care about your application security in production, you can't help but use HTTPS even in your development environment.

Using specific browser features

If you want to use some advanced features supported by modern browsers, you need to use HTTPS in your local development environment. This applies to service workers, secure cookies, or prefixed cookies, for example.

Some browsers allow you to use plain HTTP by explicitly specifying localhost or 127.0.0.1 as the host name while testing a service worker. However, this violates the environment parity principle discussed earlier. In addition, it is strongly discouraged by browser manufacturers.

Custom hostname

Usually, you use localhost as the name for your local machine. This is a reserved name and is mapped to the 127.0.0.1 IP address. Browsers treat it in a special way, especially in terms of security.

However, there are situations where you may need to use a custom hostname, such as myapplication or myhost.dev or something else. For example, you can use a custom hostname to rely on meaningful names to distinguish multiple development environments. You can do it by editing your machine's hosts file.

Warning: changing the content of your hosts file may create access problems to certain Internet domains.

In this case, your browser won't consider it a secure site, but it will when you enable HTTPS.

Read more...