In our world of “content is king” when it comes to video content, most users do not care where they watch and consume content but instead are concerned about finding their preferred videos on a particular website.

As a result, in order to enhance brand influence, increase user stickiness, and cultivate the habit of users paying to watch, various video websites have increased their investment in original content to provide differentiated services. These video websites spare no effort to acquire costly exclusive copyrights to attract users with high-quality IP and generate positive word-of-mouth. With this significant investment in content, preventing the unauthorized use of exclusive videos and avoiding copyright infringement has become an urgent issue.

As a leader in the CDN industry, CDNetworks has always been committed to ensuring the service quality of video websites and protecting their legitimate interests.

To help video websites solve the problem of video hotlinking, CDNetworks has launched a series of basic anti-hotlinking functions, including IP blacklists and whitelists (including regional access permissions), Referer anti-hotlinking, User-Agent anti-hotlinking, and Cookie anti-hotlinking. By identifying hotlinking requests through relevant rules and refusing to provide services, video copyrights are protected, effectively helping video platforms save bandwidth and server maintenance costs.

Anti-hotlinking Technology	IP Black and White List Anti-hotlinking	Referrer Anti-hotlinking	User-Agent Anti-hotlinking	Cookie Anti-hotlinking
Application scenario	Allow or deny user requests from specified IPs	Allow or deny user requests from specified websites	Allow or deny user requests from specified browsers or clients	Allow or deny user requests with specified cookies
Advantages:	Simple implementation method	Simple implementation method	Simple implementation method	Simple implementation method
Disadvantages:	Limited application scenarios	Tags are easily imitated, providing average anti-hotlinking effectiveness	Tags are easily imitated, providing average anti-hotlinking effectiveness	Tags are easily imitated, providing average anti-hotlinking effectiveness

Overview of CDNetworks’ Anti-Hotlinking Functionality

IP Whitelist/Blacklists

IP addresses are unique in a communication network. In situations where NAT (Network Address Translation) is not considered, a client’s IP address generally remains constant throughout the request process. When a client initiates a request to a CDN PoP, the PoP can obtain the client’s IP address. Thus, IP addresses can be leveraged for access control. When a request is received, the CDN PoP verifies the client’s IP address and either grants or denies access according to predefined rules.

Applicable Scenarios for IP Whitelist/Blacklists

The black and white list is suitable for the following scenarios:

• When abnormal access behavior is detected from certain IP addresses, such as hotlinking or certain attacks, these IP addresses can be added to the blacklist. Consequently, access attempts from these IP addresses to CDN PoPs will be directly denied.
• When access to accelerated content is restricted based on IP addresses, such as only allowing access to employees within a company and denying access to individuals outside the company, the fixed exit IP addresses of the company can be added to the whitelist. Consequently, access attempts from IP addresses other than those on the whitelist will be directly denied.
• When access to accelerated content is restricted based on geographic regions, such as allowing viewing or downloading only for users in the New York area and denying access to users from other regions, the region access permission feature can be used.

Implementation

The black and white list supports the following methods:

• Supports access control for one or multiple IP addresses (blacklist or whitelist).
• Supports access control for IP address ranges (typically using IP + subnet mask, such as 192.168.1.0/24).
• Supports regional access permissions, such as allowing or denying access to specific resources for users from certain regions (based on the users’ exit IP location).

Referrer Anti-hotlinking

When a client sends a request to a web server, it typically carries a Referer header, indicating to the web server which page the request originated from. Therefore, access control can be performed based on this header. When a CDN edge server receives a client request, it checks the information in the Referer field of the HTTP request header, and then allows or denies user requests that comply with specific rules.

Applicable Scenarios

Referrer anti-hotlinking is suitable for scenarios where accelerated content is only allowed to be accessed from specific pages, such as when users are only allowed to access resources by clicking on links from specific pages.

Implementation

When using the Referrer anti-hotlinking feature, it is necessary to specify how to handle empty references (referring to cases where the Referer header is not carried in the HTTP request header, typically occurring when a URL is directly entered into the browser address bar, or when a URL is accessed through non-browser means). By default, empty references are prohibited.

User-Agent Anti-hotlinking

When a client sends a request to a web server, it typically carries a User-Agent header, indicating to the web server which client initiated the request. Therefore, access control can be performed based on this header. When a CDN PoP receives a client request, it checks the information in the User-Agent field of the HTTP request header, and then allows or denies user requests that comply with specific rules.

Applicable Scenarios

User-Agent anti-hotlinking is suitable for the following scenarios:

• When accelerated content is only allowed to be accessed by specific browsers, such as only allowing Internet Explorer to access and denying access from Chrome, User-Agent anti-hotlinking can be used.
• When accelerated domains are only allowed to be accessed by specific clients, such as having a dedicated client that carries specific User-Agent information when sending requests, User-Agent anti-hotlinking can be used.

Implementation

Common User-Agent information for several popular browsers is as follows:

Browsers	User-Agent Information
IE11	Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
IE10	Mozilla/5.0 (compatible; MSlE 10.0: Windows NT 6.1; WOW64; Trident/6.0)
IE9.0	Mozilla/5.0 (compatible; MSlE 9.0; Windows NT 6.1; Trident/5.0: MATP; BOIE9:ZHCN)
IE8.0	Mozilla/4.0 (compatible; MSlE 8.0; Windows NT 6.1; Trident/4.0: SLCC2; .NET CLR 2.0.50727; NET CLR 3.5.30729: NET CLR 3.0.30729; MATP; Media Center PC 6.0; .NET4.0C; Tablet PC 2.0; BOIE9:ZHCN)
Chrome	Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36(KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Firefox	Mozilla/50 (Windows NT 6.1; WOW64: rv:21.0) Gecko/20100101 Firefox/21.0
Safari	AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Opera	Mozilla/5.0 (compatible; MSlE 9.0; Windows NT 6.0) Opera 12.14

Cookie Anti-hotlinking

Cookies are data stored on a user’s local terminal by certain websites to identify user identity and perform session tracking. The original cookie is carried to the server when a user revisits the same website. Therefore, access control can be performed based on this header. When a CDN PoP receives a client request, it checks the information in the Cookie field of the HTTP request header, allowing or denying user requests that comply with specific rules.

Applicable Scenarios

Cookie anti-hotlinking is suitable for scenarios where accelerated content is only allowed to be accessed by requests carrying specified cookies.

Implementation

When using cookie anti-hotlinking, it is important to note:

• Support configuring access only for requests carrying specified cookies, by identifying keywords carried in the cookie to determine if the user is allowed access.
• Since users do not carry cookie information on their first visit, allowing access with empty cookies is necessary.

CDNetworks’ Approach to Implementing Access Control

1. The user initiates a video request to the CDN PoP.
2. The CDN PoP checks whether the user information (such as IP, Referer, User-Agent, Cookie, etc.) meets the configured requirements. If not, it rejects the request. If the requirements are met and the content is cached locally, it responds directly. If the content is not cached locally, it fetches the corresponding resource from the origin server.
3. The video origin server responds to the CDN PoP’s request.
4. The CDN PoP responds to the client’s request and caches the resource locally.