How to use Amazon CloudFront, AWS WAF, and referer checking to help stop hotlinking.
In September 2025, AWS WAF Classic will be deprecated and put out of service (EOL). In order to help avoid hotlinking, this update explains how to use the most recent version of AWS WAF (WAFv2). The screenshots have been updated to take into account the modifications made to the AWS Management Console for AWS WAF.
Hotlinking, sometimes referred to as inline linking, is a type of content leeching in which links to resources that were first mentioned in the HTML of a principal website are embedded on an unapproved third-party website. Since the third-party website does not have to pay for the content’s hosting, your website may be billed for the content that other websites utilize. Slow loading times, lost income, and perhaps legal problems are further consequences.
AWS WAF can now be used to assist stop hotlinking. With its close integration with Amazon CloudFront, a content delivery network (CDN), AWS WAF is a web application firewall that can assist shield your web apps from common online exploits that could impair application availability, jeopardies security, and use excessive amounts of resources.
Solution overview
Hotlinking can be dealt with in a number of ways. For example, you can use the Apache module mod_rewrite to validate the Referer header at your web server. Then, you can either redirect the visitor back to the main page of your site or return a 403 Forbidden error to the visitor’s browser.
Validating the Referer header at the web server is less useful if you’re using a content delivery network (CDN) like CloudFront to speed up the delivery of material on your website. Additional requests for that content must be validated by the CDN itself because they are unlikely to reach the origin web server, even if your web server validates the headers of the original request (in this case, the referer). This is because the CDN stores a copy of your content at the edge of its network of servers.
Figure 1: Request-response flow illustrating cache-hit and cache-miss occurrences
The following is the procedure depicted in Figure 1:
- At a CloudFront edge point (2), a user client (1) sends a request.
- A cached copy of the requested file is attempted to be returned by the edge location. If the cache responds to this request, it’s referred to as a cache hit.
- When there is a cache miss and the content is either invalid or not in the edge (for instance, if it is outdated), the request for a fresh copy of the object is sent to the origin (3), which may be an Amazon Simple Storage Service (Amazon S3) bucket.
- The origin is unable to apply validation logic to the user’s request in the event of a cache hit since the edge server can fill the request without contacting the origin.
Solution implementation two approaches
Two methods for configuring AWS WAF to assist stop hotlinking are provided in this post:
- Using a different subdomain: To ensure that you only need to validate the Referer header, static files (such images or styling elements) that need to be protected are transferred to a different subdomain, like static.example.com.
- Using the same domain: Static files are found on the same domain under a directory. The extension of this example to check for an empty Referer header is part of this solution.
The strategy you choose will rely on the structure of your website and the degree of security you wish to apply. While the second method includes an extra check for an empty Referer header, the first method allows you to set up a Referer header check to ensure that requests for the pictures only originate from an allowlisted sub-domain. While banning unaffiliated third-party sites from integrating the picture links on their websites, the second method builds on the first and gives users some leeway in sharing direct links to the image.
Terms
Key terms used in this post are listed below:
- A web access control list (web ACL) linked to a certain CloudFront distribution makes up an AWS WAF setup.
- One or more rules make up each web ACL, and each rule may have one or more match conditions.
- One or more filters make up match conditions, which check the request’s headers or URI to see if they meet specific criteria.
- Case-sensitivity: The names of HTTP headers are not affected by case. The same HTTP header is referenced by referer and referer. However, the data in HTTP headers are case-sensitive.
Requirements
An AWS WAF web ACL cannot be configured until a CloudFront distribution has been set up. See Configure distributions for details on configuring a CloudFront distribution using an S3 bucket as an origin.
You can also read AWS SageMaker Lakehouse With Amazon S3 Tables Integration
Approach 1: A separate subdomain
The AWS WAF rule set created in this example has a single rule with a single match condition and a single filter. The Referer header is examined by the match condition to make sure a specific value is present. Traffic is permitted if the request satisfies the requirements outlined in the rule. If not, the traffic is blocked by the AWS WAF rule.
For this example, you will prohibit hotlinking for any file that does not have a referrer that ends in example.com because all of the static files are on a different subdomain (static.example.com) that can only be viewed from the website example.com.
Approach 2: All content under the same domain, with filtering by path
The second method filters by a specified URL path and permits a blank Referer header. You will accomplish this by creating an AWS WAF web ACL with several rules and extra match criteria, which are made up of several filters. The match condition examines the Referer header, just like in the first method, but you will validate the header twice. Initially, you verify if the request has the expected header. If not, you go to the second validation, which looks for a URL-style Referer header.
In some circumstances, users may want to share the picture link directly with others. In these cases, accessing the image directly in the browser can be helpful in avoiding a bad user experience. Compared to the first method, which required that requests for the photos come from the sub-domain, this method is an improvement.
In order for AWS WAF to protect distinct folders under a single domain name, you will additionally need to verify the path that was used in the request (in this case, /wp-content).
In conclusion
You can keep an eye on and manage HTTP(S) requests that are sent to your secured web application resources with AWS WAF, a web application firewall. You learnt how to safeguard the material on your website housed in an Amazon S3 bucket by using the AWS WAF custom rule builder functionality to stop content hotlinking.
By preventing unauthorised third-party websites from linking back to static assets on your website, you can prevent higher bandwidth costs, poor user experiences, and decreased performance due to resource leeching. This post outlines two methods for implementing a strong referrer check solution. You can further limit the AWS WAF rules to only apply to specific image file extensions (like.jpg or.png) by adhering to the least privilege principle.
Although referer checking helps stop unaffiliated websites from using your site’s bandwidth and backlinking to its graphics, more advanced exploits can deliberately build a request to get around the referer check. Inconsistencies in correctly interpreting the referer header value can also be caused by other web request mechanisms, such as browser plugins, server-to-server queries that forge referer header data, or privacy-based web browsers. Recognise these discrepancies and think about utilising extra private content security measures like token authentication and signed URLs.
There is no way for web browsers to determine whether a Referer header has been altered. Referer checking should be used in conjunction with AWS WAF application protection rules, Bot Control, Fraud Control, and Distributed Denial of Service (DDOS) protection as part of a larger online application security strategy.
