Security

HTTPS Redirect

By default, HTTP requests are automatically redirected to HTTPS using a 307 redirect. This ensures all traffic is encrypted.

Set HTTPS Redirect to false to allow HTTP traffic without redirecting. Use this only when you explicitly need to serve content over HTTP.

Enable HSTS

HTTP Strict Transport Security (HSTS) instructs browsers to only access your site over HTTPS, even if the user types http:// in the address bar.

By default, the CDN adds the HSTS header with max-age=31536000; includeSubDomains; preload, which tells browsers to enforce HTTPS for one year and apply it to all subdomains.

Set Enable HSTS to false to disable the HSTS header. Only disable this if you have specific reasons to allow HTTP access or if you're managing HSTS headers from your origin.

Bot verification

Bot verification validates that clients claiming to be search engine bots (like Googlebot or Bingbot) are actually from the legitimate source, not imposters trying to bypass security or scrape content.

The feature works by checking the User-Agent header against a list of known bot patterns, then performing reverse DNS lookup to verify the client's IP address belongs to the claimed bot's domain.

How it works

When bot verification is enabled for a path:

1. Regular users (not claiming to be bots): The CDN adds the header X-VCDN-bot-verify: ua-not-special to the backend request. The request is processed normally.
2. Verified bots (legitimate search engines): The CDN verifies the bot's identity via reverse DNS lookup and adds the header X-VCDN-bot-verify: verified to the backend request. The request is processed normally.
3. Fake bots (clients lying about being bots): The CDN returns a 400 Bad Request response immediately, without forwarding to the backend.

Configuration options

• Disabled: No bot verification (default)
• Enabled: Uses built-in rules for common search engine bots (Google, Bing, Yahoo)

Important: Using Vary for different responses

If you serve different content to verified bots versus regular users based on the X-VCDN-bot-verify header, you must add Vary: X-VCDN-bot-verify to your origin responses. This ensures the CDN caches separate versions of the content.

Without the Vary header, the CDN may serve a cached response meant for a bot to a regular user (or vice versa), causing incorrect content delivery.

Example backend response headers:

Vary: X-VCDN-bot-verify

Or if you already have other Vary headers:

Vary: Accept-Encoding, X-VCDN-bot-verify

Hotlink Protection

Hotlink protection prevents other websites from embedding your resources (images, videos, etc.) directly in their pages, which steals your bandwidth and potentially your content.

When enabled, the CDN checks the Referer header of incoming requests. If the referer's hostname doesn't match your site's hostname and isn't in the friends list, the request is denied with a 403 status.

Requests without a Referer header are allowed through.

Hotlink Friends

The Hotlink Friends list specifies additional hostnames that are allowed to embed your resources, in addition to your own hostname.

This is useful when you have content on multiple domains, partner sites, or CDN domains that should be allowed to reference your resources.

You can specify multiple hostnames as a space-separated or comma-separated list.

ASN Filter

ASN (Autonomous System Number) filtering allows you to block or allow traffic based on the client's network origin, either by country code or by ASN.

Filter types:

• Country deny list: Block traffic from specific countries (two-letter country codes)
• Country allow list: Only allow traffic from specific countries, block all others
• ASN deny list: Block traffic from specific ASNs (network operators)
• ASN allow list: Only allow traffic from specific ASNs, block all others

When a request is denied, you can choose the response status code:

• 403: Forbidden (default)
• 404: Not Found
• 429: Too Many Requests

The main use case for ASN filtering is to block traffic from regions where you don't operate.

Rate Limiting

Rate limiting limits the number of requests a client can make over a period of time. This is implemented through a token bucket algorithm with configurable rate and bucket size. The algorithm can be explained by imagining a bucket that fills with "tokens" at a fixed rate. Each incoming request consumes one token before proceeding.

• If tokens are available: A token is consumed and the request is processed immediately.
• If the bucket is empty: The request is rejected with a 429 Too Many Requests status code.

Requests which trigger requests to the origin servers (cache misses and uncacheable objects), are rate limited separately from the overall client requests. This means that there are two rates and two credit limits to configure.

• Client Request Rate & Backend Request Rate: Controls how quickly the token buckets fill up with new requests. This is a positive float defining a rate of tokens per second.
• Client Request Credit Limit & Backend Request Credit Limit: Controls the size of your bucket by letting you choose a duration for how long you can "bank" unused tokens.
• Example: So a Request Rate of 2 and a Credit Limit of 1m will give you a bucket of size 120 that refills at a rate of 2 tokens per second. This will allow a maximum of 2 requests per second under prolonged sustained load, or for bursts of up to 120 requests at once.