Restricting Access by Referrer

Applies To:

HTTP LargeThis platform has been optimized to cache and deliver static content (e.g., HTML, CSS, JavaScript, ISO, multimedia, and software downloads, etc.) over HTTP or HTTPS.

HTTP SmallLegacy. If you are currently serving traffic over this platform, then you may continue to do so. However, we recommend that you serve your traffic over our more robust HTTP Large platform.

ADNThe Application Delivery Network platform has been optimized to deliver dynamic content (e.g., login credentials, account information, etc.) over HTTP or HTTPS. Typically, user-specific and database-driven content are served over this platform.

TBAThe Token-Based Authentication feature enforces authentication prior to content delivery. Authentication takes place via an encoded token value that must be included in the request URL. This token value is then decrypted on an edge server. The requested content will only be delivered when the user meets the requirement(s) defined in the token.

Requests may be allowed or blocked based on referrer. A referrer identifies the URL for the web page from which the link was followed. The two parameters that leverage referrer information are identified below.

Parameter	Description
ec_ref_allow	Only requests that match the specified referrer will be allowed.
ec_ref_deny	Only requests that match the specified referrer will be denied.

Key information:

The referrer value defined in the parameter should not include the protocol portion of the URL (e.g., http://).
If a referrer's URL path begins with the specified value, then this token requirement will be satisfied. This allows the flexibility to validate a hostname and/or a particular path on that hostname.
Validate multiple referrers within a single parameter by separating each one with a comma.
Although a typical configuration should not include both parameters, it is possible for a token to contain both of these parameters. In such a case, the ec_ref_allow parameter takes precedence over the ec_ref_deny parameter.

When specifying multiple referrers, make sure that you do not add a space along with the comma delimiter. Referrers that are preceded by a space will be ignored.

Wildcard Matching for Subdomains (HTTP-Based Platforms)

This capability is only supported on the HTTP Large, HTTP Small, and the ADN platforms.

A single asterisk (*) may be used as a wildcard at the beginning of the assigned parameter value. Parameters configured in this way will match zero or more characters for the subdomain portion of the URL (e.g., secure in secure.domain.com). A wildcard will not match forward slashes (/), nor can it be used to match characters in other portions of the URL.

Handling Missing or Blank Referrers

Some browsers can be configured to not send referrer information. By default, the ec_ref_allow parameter will block these requests, since they do not match the specified criteria. Likewise, the default behavior of ec_ref_deny is to allow these requests. If you would like to change the default way in which blank or missing referrers are handled, then you should assign either a "Missing" or a blank value to the desired parameter.

All of the following sample values will grant access for requests with blank or missing referrers.

ec_ref_allow=www.server1.com/Folder1/movie1,data.server1.com,MISSING
ec_ref_allow=www.server1.com/Folder1/movie1,data.server1.com,
ec_ref_deny= www.server1.com/Folder1/movie1,data.server1.com

The trailing comma in the second example allows blank or missing referrers.

All of the following sample values will deny access for requests with blank or missing referrers.

ec_ref_allow=www.server1.com/Folder1/movie1,data.server1.com
ec_ref_deny= www.server1.com/Folder1/movie1,data.server1.com,MISSING
ec_ref_deny= www.server1.com/Folder1/movie1,data.server1.com,

Referrer Examples

We will now use a sample URL to demonstrate how access will be granted or denied based on tokens that take advantage of the ec_ref_allow parameter. The following scenario assumes that the token used to request access has the following requirement:

ec_ref_allow=www.server1.com/Folder1/movie1,data.server1.com,*.server2.com

This parameter only supports wildcards on the HTTP Large, HTTP Small, or the ADN platforms.

The following table describes how sample requests with the specified referrer will be handled for this scenario.

Sample Referrer	Authorized?
http:// www.server1.com/Folder1/movie1.htm	Allowed
http:// www.server1.com/Folder1/movie1.html	Allowed
http:// www.server1.com/Folder1/movie1/index.htm	Allowed
https:// data.server1.com/Folder2/movie123.html	Allowed
https://secure.server2.com/index.html	Allowed
https://en.secure.server2.com/index.html	Allowed
[Blank or not provided]	Denied
http://www.server1.com/	Denied
http:// secure.server1.com/Folder1/movie1.htm	Denied
http://server2.com/index.html	Denied
http://domain.com/secure.server2.com/index.html	Denied

The ec_ref_deny parameter works in the same way. The following scenario assumes that the token used to request access has the following requirement:

ec_ref_deny=www.server1.com/Folder1/movie1,data.server1.com,*.server2.com

The following table describes how sample requests with the specified referrer will be handled for this scenario.

Sample Referrer	Authorized?
[Blank or not provided]	Allowed
http://domain.com/secure.server2.com/index.html	Allowed
http:// www.server1.com/Folder1/movie1.html	Denied
http:// www.server1.com/Folder1/movie1/index.htm	Denied
https:// data.server1.com/Folder2/movie123.html	Denied
https://secure.server2.com/index.html	Denied
https://en.secure.server2.com/index.html	Denied