Password protecting static sites

Static site hosting on the rise

Static websites have recent years gained popularity again and many new static site hosting providers have popped up. Advantages of static sites and some primary reasons to go static are that sites are less exposed to malicious attaks, and easily and cheaply can be distributed through a content delivery network (CDN) to increase speed and stability. Distributing dynamic content and databases through a CDN is costly and considerably increases complexity. While there are many advantages of static sites compared to dynamic sites, a common problem is how to password protect parts of or a whole static website.

Is it possible to password protect a static site?

The short answer is no. It is not possible due to the nature of static sites. Because static websites consist of files downloaded and processed by the visitor’s browser, it is impossible to manage user access verification that needs to be handled server-side.

The longer and more complex answer is yes, it is possible, but there is no straight forward generic solution, and all options come with several disadvantages. Below I have outlined three approaches for password protecting static sites, client-side scripting, serverless computing, and mixing a static site with a dynamic site.

Client-side scripting

It is possible to do some password protection using client-side scripting. The major advantage is that this approach works natively with all static hosting services.

Below I will briefly describe ‘SaticCrypto’, ‘PageCRypt’ and “Password protection for static pages,” three JavaScript-based forms of basic password protection easy to implement. I have picked these three because they provide different types of protection.

A major disadvantage is that it is not possible to have users sign up and receive independent accounts. All the solutions are also subject to brute-force attacks. Long passwords will minimize the chances of a successful brute-force attack.

Pure client-side solutions are not suitable for protecting sensitive data such as user or payment data and the like. Only use these solutions to protect data, you prefer not to be public, but when it causes no significant harm if the data becomes public.

StatiCrypto

StatiCrypto can be used to password protect an HTML document. The concept is simple and provides strong encryption using AES-256. StaticCrypt encrypts a text string embedded into an HTML file. This text string can consist of any text, including HTML, JavaScript, and CSS. To unencrypt the embedded text, the user needs to type in a password. You cannot use this solution to protect files for download or images. This solution does not scale well and works for a single static HTML page. The user experience is not optimal. If you leave the page and return using the back button or similar, you will have to type in the password again to see the page content.

To use StatiCrypto, go to https://robinmoisson.github.io/staticrypt/ and paste your text and/or HTML/JavaScript/CSS you want to encrypt. The site will then generate an HTML file embedded with your encrypted content and a web page that prompts for a password. StatiCrypto is also available as a command line interface. Go to this GitHub repository for more information about this option or if you want to get the source code.

PageCrypt

An alternative JavaScript based option is PageCrypt that works according to the same concept as StatiCrypt. A demo, using the password ‘hunter2’, is available at: https://www.maxlaumeister.com/pagecrypt/demopage/

“Password protection for static pages”

This script creates a SHA1 hash of a string used as the password. This hash is the name of the directory on your server containing the protected files. E.g., the password “test” generates the hash “a94a8fe5ccb19ba61c4c0873d391e987982fbbd3.” When a user types in the password at example.com/MyLoginPage/ they will be redirected to example.com/MyLoginPage/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3/

Essentially this approach should more appropriately be labeled as security through obscurity. The content you want to protect is not encrypted and is accessible by anyone knowing the URL. This is an easy to implement script if you need to hide pages, but do not mind if the directory eventually gets picked up by a search engine bot or if the content is accessible by anyone becoming aware of the directory URL. Obviously, this approach is not suitable for protecting sensitive data.

You can find the source files, documentation, and an implementation guide at this GitHub repository.

You can try a demo, using the password ‘secret’, at: https://matteobrusa.github.io/Password-protection-for-static-pages/

Serverless computing

Well, there is no such thing as serverless computing, anything on the Internet requires a server. Rather serverless computing means that the developer does not need to manage the infrastructure, but can focus on writing code. Several providers offer serverless computing services available on a global infrastructure. Most static hosting services allow static sites to be mixed with dynamic functions such as authentication.

Cloudflare Workers is one example of serverless computing service allowing the developer to write code that will be available on Cloudflares global network. Code for using a Cloudflare Worker to manage basic WWW-Authenticate is available from this GitHub repository. This code can be copied into a worker and the only modification needed is a customised username and password.

Cloudflare Workers require that the domain is using the Cloudflare DNS and proxy service. Cloudflare workers functions can both be combined with static hosting on Cloudflare Pages or most other providers. The first 100,000 requests to Cloudflare Workers each day are free.

Static website hosting providers such as Netlify and Surge offers the opportunity to password-protect static sites. This approach provides real password protection. They serve your static site from a CDN but use a complex CDN setup that also allows some server-side processing behind the scenes.

Using a static site host that supports real authentication through design is, for most use-cases, the most simple, secure, scalable, and smooth solution. This approach does have some drawbacks. Such solutions are typically only available as part of a paid plan or at an extra monthly fee, and you will become dependent on the specific host’s infrastructure. The last drawback can complicate things if you, at some point, decides to switch to a different host.

Hostman offers a free static site hosting package with a free simple password protection feature. The package is intended for development and low traffic sites. The only requirement is that you add a credit card after a trial period. As long as you only use the free packages and features your card will not be charged. The limitations are that you can only create one username/password, and you can only protect the entire site at the root domain and not just a subdirectory.

Mixing a static site with a dynamic site

Technically, this approach does not password protect a static site. If you need to protect a part of your static website and the solutions above, do not fulfil your security needs or use-case, one solution is to host the protected part of your site in a dynamic environment. For example, you can run your public static site at www.example.com, and the protected part of the site at users.example.com using a classic dynamic host processing authentication server-side. If you run your static site using average shared hosting, you will be able to run static sites and dynamic sites side by side. You can also run the static part of the site through a CDN.

An advantage is that website developers have a ton of choices between free and paid off the shelf software for managing password protected web pages. A disadvantage is that running two separate sites will gear up complexity. Typical dynamic environments are served from a specific server. This approach means that a lot of the features of serving a static site through a CDN are lost.

Two common approaches are 1: using a content management system (CMS), and 2: using the basic access authentication function available in most common web server software, e.g., Apache and Lighttpd.

Summary

Choosing the solution that fits you the best, depends on your specific use-case, the host you are using, and your budget. Using client-side scripts for simple protection is easy to set up and also work with most hosts. This approach only provides simple, limited and somewhat pseudo protection. Using a static hosting environment supporting password protection is simple and scalable, but is only supported by a few providers at a monthly fee. Using a severless computing environment can provide strong security, but it is more complex to setup, and not supported by all hosts. Mixing a static site with a dynamic site can be an easy, fast, and cheap solution because of the existing body of free and paid software. If your protected site has a lot of visitors you might have to scale up server resources and miss some of the advantages of true static hosting.