Content Protection and Anti-Hotlinking
Content protection primarily resolves the hotlinking* problem, making it impossible (or significantly more difficult) to use your content on someone else’s site. At the same time, it is crucial for us to preserve the maximum of your traffic. That’s why Video CDN protection works in a non-linear logic — access to video can be allowed when there are reasons to believe that the user came from a native site, even if, according to the protection rules, the request should be blocked. See the descriptions below for details.
*hotlinking — using someone else’s content on the site or other platform without any rights to do so, for instance, by embedding in the site’s HTML code tags <img>
, <video>
or similar referring to another site’s assets in order to save money on hosting and profit on other people’s content.
All of the below protection methods can be utilized in any combination, but many of them require the use of the URL signature (parameter /key=../
).
Recommended value for the referrers list:
/referrer=!.wrong.domain,any/
.
Referrer is a header in the browser’s HTTP request to the server with information about the requested page. Depending on the request, the CDN also analyzes the Origin header (containing only the domain).
For privacy reasons, these headers are often not transmitted at all, and there are ways to turn off their transmission in the site’s HTML code and hide malicious use of your resources by someone else’s site. Therefore, checking the headers will only detect hotlinking in a small percentage of cases but can confirm the absence of hotlinking if the browser returns the native domain.
It is important to take into account that different browsers may return different URLs (e.g. the URL of the page being shown, the URL of the source of the JS code playing the video, etc.). Therefore, all domains that host resources that play video should be added to the list of acceptable referrers.
It is easiest if all such resources are hosted on subdomains of the main domain - then it is enough to add only the main domain with the indication to allow and its subdomains (i.e. *.example.org) - for the parameter /referer=../
it will be the domain with a dot before the name: /referer=none,blocked,.example.org/
.
The more severely limited the lifetime of a link, the more often an attacker bot will have to go for fresh URLs. At the same time, the chances increase that the lifetime of the link may not be long enough to view the entire video.
One of the best comprehensive options to protect against unwanted downloads is to bind the link to the browser IP and set a list of allowed referrers.
Keep in mind that a significant percentage of traffic (about 15%) comes from ISPs that use different IPs to access different domains, and a request may come to the site from one IP and to the CDN from another. Video CDN first receives the request to the redirector and then to the stream server. All these IPs may be different and different from the IP from which the request to the site was made.
Therefore, in order to keep the maximum amount of traffic, CDN does not block the request with invalid IP if there is reason to believe that the request came from the native site - a non-empty valid referrer is returned.
Limits the number of different IPs that can access a particular URL instead of binding to a specific IP (or range).
The actual number of IPs allowed may be higher due to the difficulty of synchronizing the counter between servers.
This method allows different IP addresses to use the same URL (which is relevant for traffic from dynamic IPs) but protects against mass hotlinking. The Force HTTPS option will also protect against primitive bots that do not support HTTPS.
To use cookie checking, you need to delegate your subdomain to our NSs so we can use them in redirects to streaming servers and provide tech support with a certificate to *.cdn.example.com so that redirects to streaming servers like https://ip123456.cdn.example.com/ will work.
Since only the top-level domain itself (and its js-scripts) has access to the subdomain cookie, when playing a video, the native domain can set the SecureCookie value in the URL signature string, while the foreign domain cannot and, therefore, will not pass the corresponding check. This method will save more traffic from dynamic IP.
There are some difficulties involved with this method application — different browsers approach passing the cookies to third-party subdomains differently. If you use a default domain like ipXXXX.ahcdn.com, a cookie will not be passed in HTTP-request to stream-server; if you use a CDN-domain subdomain (i.e. if you redirect to subdomains like ipXXXX.vcdn.example.org) — browser may still decide not to pass a cookie to stream-node.
This global setting allows you to restrict content access from certain countries. The list of countries to block is set in the account settings or domain settings. Note that the country definition may not be precise, and legitimate requests may be blocked as a result.
This setting limits the intensity of HTTP requests for one URL in a global or subdomain setting. Due to a non-trivial implementation, this check is only performed on redirector servers, not on stream servers.
Limiting the request intensity allows blocking bots that constantly access redirectors; e.g., these could be content grabbers or proxies that bypass other protection methods.
This method allows to encrypt the URL or a part of it. It can be used to hide the override settings or other means of protection. It is also useful for SEO optimization.
The method can be used to track content leaks and for similar tasks by tagging the downloaded file with a unique identifier for each user. We recommend using the method in conjunction with URL encryption.
In the per-URL parameters section, you will find a list of all supported URL parameters and recommendations on how to use them, as well as the necessary scripts and examples.
Since bots can emulate users’ activity on the site and get valid links to pass CDN security checks, you need to secure bot identification on your website, not only within the CDN.
For instance, set the web server access-log check-up for the number of requests from a single IP.