Protecting Demo Websites through Gateway URLs

This is a technical article for web developers.

Are you working on a “stealth” web based project that you wish to demo to a potential client or investor, yet do not wish to leave it wide open to the public? There are several ways to do it, the simplest of which is to password protect it. This, however, requires you to give out the password and sharing a password has its own security implications. It also makes user experience worse.

An alternative solution is to block access from all IP addresses except a whitelisted few. When you wish to demo a project to someone, find out his public IP address and whitelist it for the intended duration of the demo. To make this process automatic you can expose a generic landing page to the public. When someone visits it, your web server will see his public IP address and whitelist it if it meets certain criteria.

This generic scheme needs further elaboration, and here is my recommended approach. When you wish to share your demo with a potential client, generate a randomized link, register it as a gateway URL at your web server and send it to him. When he clicks it, your web server will (a) identify him and whitelist his IP, and (b) expire the gateway URL record. Thus, there are two whitelists: one for gateway URLs and the other for IP addresses.

Each of the whitelists has an independent expiration policy. For instance, if you expect the potential client to view your demo within a week, set the expiration time in the gateway whitelist for 1 week. If your website is a Single Page App (SPA) that upfront loads all resources, set your IP address whitelist for 1 minute.

Most likely your SPA makes API requests back to your server. However, you do not need to restrict this access using an IP address whitelist. Authorized access to the API may be determined based on a Cookie or on an authentication token that is loaded into the SPA during the initial 1 minute window. Similarly, if your website does not load all resources upfront, the initial page can be equipped with a Cookie the presence of which will allow to load additional resources.

If your web project has a link sharing feature or member invite links, you can automatically add such links to the gateway URL whitelist. If it is intended that your potential client needs to view the demo more than once, have him create his own username and password during the first time he uses the demo, or have him login using Single-Sign-On (SSO). Then, on the subsequent attempt to view it, ask him to login and have the web server whitelist his IP upon authentication.

The outlined technique can work not only for demos while the product is in stealth mode, but also for completed products in order to decrease the attack surface.

You can identify gateway URLs using different schemes: redirects, HTTP Referrer header, query parameters, fragment indicator or an embedded authentication token. Each of these schemes is outlined:

• Redirects: Web server performs a 301 redirect from a randomized gateway URL to an internal page with a normal URL.
• HTTP Referrer: Web server serves a landing page for randomized URLs, and inspects the referrer header on all loaded resources, whitelisting IP address on the first occurrence of a recognized gateway URL in the Referrer header.
• URL query parameters: Instead of generating randomized path, serve the page on the same URL path, but put the randomization in the URL query parameter.
• URL fragment indicator: (This is the suffix of the URL following the “#” sign.)
• Embedded authentication token: Embed authentication token inside the body of an HTML page. When it is loaded, arrange it to send the authentication token to the server by any means, such as via a Cookie.

The disadvantage of the redirection method is that the randomized URL must be hosted on your web server. In all other cases, you can host the gateway page on a third party server. This can be advantageous if you do not wish to advertise the domain name of you web server in links that you send out.

You can also share a gateway HTML page on an online drive like Dropbox. When the recipient downloads and opens it, it will whitelist him. A randomized name of a file which the web server will see in the Referrer header, or a randomized authentication token inside the HTML content, can be used to identify the gateway page.

If you decide to rely on the referrer method, be sure to set the correct Referrer-Policy on the landing page. It can either be set by the web server, or by embedding a meta header in the HTML source.

<meta name="referrer" content="no-referrer-when-downgrade">

Also, do not get mixed up between the two spellings “referrer” and “referer”. The HTTP header in which your web server will see the referrer is spelled with a single “r,” but in all other cases, it is spelled with a double “r.” In node.js you can get it with:

req.headers.referer

There are several further variations. If you just want the user to load all resources, then you do not need an IP address whitelist. Simply set gateway whitelist expiration to 1 minute after it was first observed.

Alternatively, replace the IP whitelist with a Cookie whitelist. Upon observing a gateway URL, either whitelist the cookie provided by the client, or generate one on the server and send it back to the browser. It will return on the following requests. The advantage of using cookies is that it gives you a finer filter than an IP address.

If you decide to use cookies but your landing page is not on the same domain as the resources which you load, make sure to set appropriate options in Set-Cookie header in order for the browser to allow third-party cookies when loading the resources. The settings you want are SameSite=none and Secure. Also, do not set the crossoriginattribute to "anonymous” when loading resources. Either omit it or set it to use-credentials.

If your demo involves several devices then the IP filter is better. Set the expiration of the IP whitelist to a longer time (e.g. 30 minutes) in order to allow your potential client to review the demo thoroughly.

You may also add an “I am not a robot” check to you gateway page, thereby delaying expiration of the gateway URL until user proves that he is human. This would protect from automated web scrapers who may access the gateway URL before the intended person.

Published websites can use this technique for internal administrative sections whenever those must be accessed from public locations.

In summary, automatically whitelisting IP addresses gives you security and privacy benefits and protects your intellectual property while still allowing you sharing links to your websites as conveniently as if they have been already published.