DCDN Referer whitelist and blacklist for hotlink protection - Edge Security Acceleration

A Referer blacklist or whitelist controls access to your resources based on the Referer header of HTTP requests. This feature prevents hotlinking and unauthorized resource use. Once configured, DCDN evaluate the Referer header to grant or deny access.

Important

By default, the Referer blacklist/whitelist feature for Alibaba Cloud DCDN is disabled, allowing any website to access your resources.
Referer blacklists and whitelists are one way to prevent hotlinking. For more methods, see Best practices for preventing hotlinking.
When you add a domain name like aliyundoc.com to a Referer list, DCDN apply the rule to both the domain itself and all its subdomains (such as *.aliyundoc.com).

Use cases

A Referer blacklist or whitelist primarily protects your website resources from being directly linked or used by other websites. Common use cases include:

Copyright protection: For websites with copyrighted content, you can use a Referer whitelist to restrict access to authorized websites only.
Hotlinking prevention: A whitelist ensures that your resources can be accessed only from specific websites, preventing other sites from consuming your bandwidth by directly linking to your content.
Enhanced website security: By allowing only specific websites to access your resources, you can prevent malicious hotlinking, unauthorized access, and theft of sensitive information.
Traffic source control: You can restrict traffic from specific websites to control traffic sources and improve the stability and security of your website.

How it works

A Point of Presence (POP) checks the Referer header of each request. If the Referer is not on the whitelist or if it is on the blacklist, the POP denies the request. This saves bandwidth and reduces load on the origin server. DCDN use the following rules to process Referer requests:

If the Referer in a request matches an entry in the blacklist or does not match any entry in the whitelist, DCDN deny the request.
If the Referer in a request matches an entry in the whitelist, DCDN allow the request.

Procedure

Log on to the DCDN console.
In the left-side navigation pane, click Domain Names.
On the Domain Names page, find the target domain name and click Configure.
In the left-side navigation tree of the domain name, click Access Control.
On the Hotlink Protection tab, turn on Hotlink Protection.

Select Blacklist or Whitelist based on your needs.

Configure Referer-based hotlink protection

Parameter		Description
Type		Blacklist Requests from blacklisted domains are denied. Whitelist Only requests from whitelisted domains can access your resources. Note The blacklist and whitelist are mutually exclusive.
Rules		Enter one domain name per line. No leading spaces. Asterisks () work as wildcards. For example, `.developer.aliyundoc.com` matches `image.developer.aliyundoc.com` and `video.developer.aliyundoc.com`. Note Maximum rule size: 60 KB.
Redirect URL		Blocked requests receive an HTTP 302 redirect to this URL. The URL must start with `http://` or `https://`, for example, `http://www.example.com`.
Advanced Settings	Allow resource URL access from browsers	Disabled by default. When enabled, requests with an empty Referer header can access resources regardless of whether you configure a whitelist or blacklist. An empty Referer occurs when: No Referer header is present. The Referer header value is empty.
	Exact Match	Not selected by default. If you select this check box, subdomains cannot be matched. For example, adding `example.com` matches only `example.com` — subdomains are excluded.
	Ignore Scheme	When disabled, the Referer value must include an `http://` or `https://` scheme. When enabled, the Referer value is matched without requiring an `http://` or `https://` scheme.

Click OK.

Matching logic

The following table shows how DCDN matches the Referer header against your list. Requests that match a blacklist entry or fail to match any whitelist entry are rejected by DCDN with HTTP 403.

Configured domain name	Referer header value in a request	Matched	Description
www.example.com *.example.com	http://www.example.com/img.jpg	Yes	Referer domain matches a list entry.
	http://www.example.com:80/img.jpg	Yes	Referer domain matches a list entry.
	www.example.com	No	No HTTP/HTTPS scheme in the Referer value.
	http://aaa.example.com	Yes	Wildcard *.example.com matches subdomains at any depth.
	http://aaa.bbb.example.com	Yes	Wildcard *.example.com matches subdomains at any depth.
	http://example.com	No	*.example.com matches subdomains but not the root domain.
	http://www.example.net	No rules matched	Domain not in list; default allow rule applies.

FAQ

Missing Referer scheme

In most cases, the Referer header in a user request includes an HTTP or HTTPS scheme. However, in certain situations, the Referer may not include a scheme.

A common scenario is when a user navigates from a non-secure website (which uses HTTP) to a secure website (which uses HTTPS). Browsers may modify or remove the Referer header based on security policies, such as the Referrer-Policy, to protect user data. In this case, the Referer header might contain only the domain, without the scheme.

In addition, some browsers or proxy servers may automatically remove the Referer header in specific situations, such as when private browsing mode is used or a website is accessed through an anonymous proxy.

Therefore, you must account for requests that lack a scheme in the Referer header.

Handling empty Referer

An empty Referer occurs when the Referer header is missing from an HTTP request or its value is empty. The Referer header in a request usually contains a complete URI that includes the scheme (such as http or https), a hostname, and possibly a path and query string. An empty referer can occur in the following scenarios:

Direct access: When a user enters a URL directly into the browser's address bar, uses a bookmark, or opens a link in a new blank tab, no referring page exists. Therefore, the Referer header is empty.
User privacy: A user or software used by the user, such as a browser extension or a privacy mode, may intentionally remove the Referer header to protect privacy.
Security protocol: When a user navigates from an HTTPS page to an HTTP page, the browser usually does not send the Referer header to prevent the leakage of sensitive information.
Client-side policy: Some websites or applications may control whether the Referer header is sent for security reasons by setting a <meta> tag or an HTTP header such as Referrer-Policy.
Cross-origin request: Some cross-origin requests may not include the Referer header due to browser security policies.

How you handle requests with an empty Referer depends on your specific use case and security requirements. The following are some recommendations:

Default policy: If your service does not rely on Referer information to make decisions, you can allow requests with an empty Referer.
Allow access: For specific URLs or origins, you can select the Allow resource URL access from browsers option. This allows access even if the Referer is empty. In this case, and DCDN POPs grant access to the resource.