Security
Basic Access Authentication
Enable HTTP Basic Authentication to protect your instance with a username and password prompt for all incoming traffic.
Set or update credentials: Provide a username and password to enable Basic Auth or to change existing credentials.
Disable authentication: Remove the credentials to turn off authentication. This immediately opens the instance to unrestricted access.
Basic Auth does not restrict access from IPs on the whitelist. Requests from whitelisted IP addresses bypass authentication.
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.
Use this feature carefully to avoid unintentionally blocking legitimate traffic.
The Allow or Block Headers feature lets you control traffic to your Alokai@Edge instance by evaluating specific HTTP request headers. It helps secure your store by filtering requests based on header values — blocking unwanted traffic or strictly allowing only trusted requests.
You can define header rules in two modes:
Block Headers
- Blocks requests if a specified header contains the given string (case-insensitive, partial match).
- Useful for broadly blocking bots, scrapers, or requests from certain regions or providers.
Allow Headers
- Only allows requests where a specified header exactly matches the provided string (case-insensitive).
- All other requests are blocked.
- Use for allow list specific clients, TLS fingerprints, or networks (e.g., for whitelisting your third party proxy like CloudFlare, Akamai).
Only one mode can be active at a time. Enabling Allow Headers disables Block Headers, and vice versa.
Logic
| Header | Logic |
|---|---|
| Block Headers | Any request matching any of your block rules is immediately denied (HTTP 403). |
| Allow Headers | A request must satisfy all Allow Header rules to be permitted. Any mismatch results in blocking. |
Using Pre-defined headers
Beyond standard HTTP headers, you can leverage advanced request filtering using pre-defined headers that Alokai@Edge automatically adds:
| Header type | Description |
|---|---|
| X-Client-Region | Two-letter country code (ISO 3166-1 alpha-2) of the client’s country. Block or allow traffic by geography. |
| X-Client-Ja3 / X-Client-Ja4 | TLS client fingerprints (JA3 / JA4) that uniquely identify a client’s SSL/TLS handshake. Useful for spotting bots, automated tools, or unusual clients. |
| X-Client-ASN | Identifies the network operator or infrastructure provider ASN (Autonomous System Number). Useful to control access from specific ISPs or data centers. |
This enables you to build geo, network, or fingerprint-based allow/block lists — for example, blocking all traffic from suspicious ASNs or allowing only requests from specific TLS profiles.
Best practices
- Use Block Headers for broader security (e.g. blocking known bad user agents, countries, or networks).
- Use Allow Headers for stricter control, allowing only well-defined clients or environments.
- Always review rules to avoid unintentionally blocking legitimate customers.