Vue Storefront is now Alokai! Learn More
Security

Security

From the Instance on the Side Navigation, choose Settings -> Security.

The Security page allows you to configure the security aspects of your instance such as Basic Auth or IP Whitelist.

Basic Access Authentication

To secure unauthorized access to the instance, you can enable a login and password prompt for incoming traffic. To do this, select Add, then enter the requested login and password. From now on, Basic Auth will be enabled, and relevant information will be visible on the tab.

To change the username and password, select Edit, then make your changes and choose Update to save.

If you want to disable Basic Auth, select Edit, then choose Remove data on the modal and confirm the action. The information about Basic Auth being enabled should change in the section.

Important! Basic Auth will not be required for IP addresses in the Whitelist.

IP Whitelist

The IP Whitelist allows you to restrict access to the instance to only defined IP addresses. After configuring it, only the IP addresses listed here will be able to view and use the deployed instance.

Enabling and disabling the IP Whitelist is independent of the added IP addresses, which you can add earlier and then activate using the switch within the section.

Similarly, you can edit and remove added IP addresses without disabling the IP Whitelist functionality.

Important! If you have Basic Auth and IP Whitelist enabled simultaneously:

  • For addresses on the IP Whitelist, Basic Auth is not required
  • For addresses outside the IP Whitelist, Basic Auth will be required

Allow or Block Headers

The Allow or Block Headers feature is available for instances deployed to Alokai@Edge.

You can enhance your instance security by allowing or blocking requests based on specific HTTP request headers. This feature lets you define rules that either deny or permit access if incoming requests contain certain headers or header values.

You can add multiple rules, edit existing ones, or remove them as needed. This provides granular control over which requests are allowed based on their headers.

Use this feature carefully to avoid unintentionally blocking legitimate traffic.

How does it work?

This function allows you to define a custom header name and value for inspection. On the WAF (Web Application Firewall, part of Alokai@Edge), the function checks if the specified header contains the string provided in the value parameter.

How it works:

  • Specify the header name (e.g., "user-agent") and the value to search for within that header.
  • The function inspects incoming requests and checks if the specified header's value contains the provided string.
  • If the condition is met, the corresponding WAF logic is triggered, the request is blocked, and an HTTP 403 Forbidden status code is returned.

Only one of the Block Header or Allow Header features can be enabled at a time. Enabling Allow Header will automatically disable Block Header, and vice versa.

Difference between Allow and Block Headers

When configuring header-based rules, there is a key difference in how allow and block headers are evaluated:

  • Block Headers: The value of the specified header is checked using a regular expression to determine if it contains the string defined by the user. If the header value contains the specified string (case-insensitive), the request is blocked. This approach allows for partial matches and flexible blocking.
  • Allow Headers: The value of the specified header must be exactly equal to the string defined by the user (case-insensitive) for the request to be allowed. Only requests with an exact match will be permitted, making this a stricter condition than blocking.

This distinction enables more flexible blocking (by matching any occurrence of a string) and stricter allowing (by requiring an exact match).

Pre-defined headers

In addition to custom headers, you can use several pre-defined headers for advanced request filtering:

  • X-Client-Region – Two-letter ISO 3166-1 alpha-2 country code representing the client's country.
  • X-Client-Ja3 – The JA3 fingerprint of the TLS client, which uniquely identifies the SSL/TLS configuration of the connecting client. Useful for detecting automated tools or bots.
  • X-Client-Ja4 – The JA4 fingerprint of the TLS client, providing an updated and more robust method for identifying client connections.
  • X-Client-ASN – The Autonomous System Number (ASN) of the client's IP address. This header identifies the network or organization (such as an ISP or cloud provider) that owns the IP address making the request. It is useful for allowing or blocking traffic from specific network operators or infrastructure providers.

These headers allow you to block requests based on geographic location or unique TLS client fingerprints, enhancing your ability to control and secure access to your instance.

Block Header Examples

To check if the user-agent header contains the string curl, set the header name to user-agent and the header value to curl. The function will match any request where the user-agent header includes curl in its value. The match is case-insensitive, so both curl and CURL in the user-agent header will be detected by the rule.

For example, the following request:

curl -I -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 403

will be blocked. The user-agent header for the curl application is curl/7.54, which contains the string curl specified in the rule.

If you change the curl user agent, as in the example below:

curl -I -H "User-Agent: other" -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 200

the request will not be blocked.

If you configure more than one header to block, requests will be blocked if any of the headers match. For example, if you specify the headers/values x-client-region/US and user-agent/chrome, any request containing either header will be blocked, as shown below:

curl -I -H "x-client-region: us" -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 403

curl -I -H "user-agent: chrome" -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 403

Allow Header Examples

To allow only requests where the user-agent header value is exactly equal to the string curl/7.54, set the header name to user-agent and the header value to curl/7.54. Only requests with curl/7.54 as the user-agent header will be allowed; all others will be blocked. The match is case-insensitive.

For example, the following request:

curl -I -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 200

will be allowed, since the user-agent header for curl is curl/7.54.

If you change the curl user agent, as in the example below:

curl -I -H "User-Agent: notcurl" -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 403

the request will be blocked.

If you configure more than one header to allow, requests will be allowed if all of the headers match. For example, if you specify the headers/values x-client-region/US and user-agent/chrome, only request containing all necessary headers will be allowed, as shown below:

curl -I -H "x-client-region: us" -H "user-agent: chrome" -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 200

If a request contains only one header it will be blocked, as shown below:

curl -I -H "x-client-region: us" -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 403

or

curl -I -H "user-agent: chrome" -X GET https://your-site-europe-west1-gcp-storefrontcloud-io.i.alokai.dev/
HTTP/2 403