Static websites have recent years gained popularity again. 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 website consists of files downloaded and processed by the visitor’s browser, it is impossible to manage users 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.
A major disadvantage is that it is not possible to have users sign up and receive independent accounts. Both 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.
“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 the users type 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. 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 any 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/
Static site hosting environment
Static website hosting providers such as Netlify and FastIO 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, decide to switch to a different host.
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 fulfill 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. Serving a dynamic environment through a CDN is complex and expensive.
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 works with hosts only supporting static sites. 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. 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.