WebP Cloud currently supports setting the User-Agent for fetching resources from the origin server on image CDNs, configuring CORS headers, and implementing Referer restrictions.

In our previous articles, we compared several image CDNs with similar functionalities and found that apart from those that directly transfer NS records to CDN service providers (Cloudflare being a typical example), most of them provide you with a new address based on the original image address from your source site. WebP Cloud is no exception in this regard.

Specifically, let’s say your image address is:

https://blog.example.com/some/cat.jpg

Generally, you would receive a new address similar to the following:

# WebP Cloud
https://e52565b.webp.ee/some/cat.jpg

# Vercel
https://cdn-image.example.com/_next/image?url=https://blog.example.com/some/cat.jpg?w=640&q=75

# Other CDN
https://cdn.example.com/some/cat.jpg

To “integrate” with a CDN, you only need to replace the corresponding image address with the new one.

Doing this itself isn’t really a problem. Using a new address can reduce integration costs while ensuring the source address remains available. However, there are risks of hotlinking and CDN bypass in this approach. Let’s consider the following scenarios:

1. CDNs may have certain rules configured, such as adding watermarks (which WebP Cloud supports) to prevent direct downloading of the original images.
2. The source site might be hosted on a service like AWS S3 with expensive egress traffic costs. Using a CDN mainly aims to cache content and reduce egress traffic expenses.
3. Other websites, like https://some-content-farm.com, could directly use img tags to display images from your CDN address, generating additional CDN requests and incurring traffic costs.

Let’s examine these scenarios one by one:

• Suppose our image https://e52565b.webp.ee/some/cat.jpg is displayed on the https://blog.example.com page. A visitor who wants to download the corresponding original image (perhaps because the images on the blog have watermarks to prevent direct usage) can easily guess that the original image’s address is https://blog.example.com/some/cat.jpg. In this case, the unwatermarked original image is stolen, indicating a potential case of CDN bypass.
• The same holds for the latter two scenarios. In fact, Vercel even places the original image address in the URL parameters, making it easy for visitors to obtain the original image.

In general, bypassing a CDN might lead to extra traffic costs originating from the source site. However, if you are using a CDN and have set up watermarks specifically to prevent image misuse, then there are potential risks involved.

For these aforementioned issues, our recently launched new features attempt to address them from three dimensions.

Origin User Agent

For regular CDNs, when visitors use a User Agent, it’s directly sent to the source server during CDN origin fetches. However, WebP Cloud and traditional CDNs have some differences in this regard.

Currently, WebP Cloud uses a fixed string as the origin User Agent: WebP Cloud Services/1.0. The user request process is as follows:

• A visitor initiates a request for

  https://e52565b.webp.ee/some/cat.jpg
  

  The request headers are as follows:

  • User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

• Assuming the corresponding image is not cached on WebP Cloud, and it needs to be fetched from the origin, WebP Cloud sends a GET request to the source site

  https://blog.example.com/some/cat.jpg
  

  The request headers are as follows:

  • User-Agent: WebP Cloud Services/1.0

• Once WebP Cloud obtains the original image, it processes it accordingly and returns it to the visitor.

With our new feature, users can set a custom User-Agent for origin fetches. The default value is currently WebP Cloud Services/1.0. For example, users can set it to: User-557f51ce-Custom. This way, the User Agent serves as a pre-shared key format to ensure that only WebP Cloud can access the source site address. This effectively prevents the source site address from being guessed and potentially bypassing the CDN.

After configuring a custom User Agent, the source site can implement similar configurations to ensure that image requests are allowed only from WebP Cloud:

Nginx

server {
    listen 80;
    server_name blog.example.com;

    location ~ \\.(jpg|jpeg|png|gif)$ {
        if ($http_user_agent !~ "User-557f51ce-Custom") {
            return 403;
        }
    }
    location / {
        # Other configs
    }
}

Cloudflare

(http.user_agent ne "User-557f51ce-Custom") and ((http.request.uri.path contains "jpg") or (http.request.uri.path contains "png") or (http.request.uri.path contains "jpeg") or (http.request.uri.path contains "gif"))

AWS S3

You can restrict access based on User-Agent by writing a Bucket Policy, for example:

{
    "Version": "2012-10-17",
    "Id": "OnlyAllowWebPCloud",
    "Statement": [
        {
            "Sid": "AllowSpecificUserAgent",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::blog-webp-se/*",
            "Condition": {
                "StringEquals": {
                    "aws:UserAgent": "User-557f51ce-Custom"
                }
            }
        },
        {
            "Sid": "DenyOthers",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::blog-webp-se/*"
        }
    ]
}

CORS Header

To minimize the occurrence of images being directly referenced by external websites, we allow users to set their own CORS Headers. This can be configured in the Dashboard, and the default value is *, which permits all websites to use the images. In the example above, if you want https://e52565b.webp.ee/some/cat.jpg to be used exclusively by your blog domain https://blog.webp.se, you can set it to blog.webp.se. Once this setting is in place, the Access-Control-Allow-Origin field in the returned headers will be set to blog.webp.se. This prevents images from being directly and properly displayed (causing CORS errors) on other websites, further reducing the risk of hotlinking.

Allowed Referer

• Please note that “referer” is actually a misspelling of “referrer.” For more detailed information, refer to the HTTP referer on Wikipedia.

The method of setting CORS Headers described earlier is effective in preventing front-end frameworks of other websites from referencing your images. However, if other websites directly use the <img> tag to display images, this approach might not be sufficient.

To address this, we offer an additional layer of protection by restricting the referer field of websites, further reducing the likelihood of image hotlinking.

• The Referer request header contains the address of the referring webpage that initiated the current request. It indicates that the current page was accessed via a link on the referring page. Servers often use the Referer request header to identify the source of requests, which may be used for various purposes such as statistical analysis, logging, and cache optimization.

For example, when a user accesses https://wordpress.webp.se/, their browser includes the following in the request headers when loading images on the page:

Referer: https://wordpress.webp.se/

This header informs the server which page is referencing the image. Our recent feature update allows users to set allowed referer values in the background. The default value is *, which permits any referer. If you wish to restrict this, you can use a comma-separated list of domain names, like wordpress.webp.se,nova.moe,dmesg.app,tuki.moe. In case other domain names attempt to directly embed the images using the <img> tag, WebP Cloud will return a 403 error, preventing the image from displaying.

Of course, preventing image hotlinking involves several measures, and the above are just some of the small contributions that WebP Cloud makes to protect source site security and prevent image theft.

As with our other added features, WebP Cloud believes that all users should have equal usage rights. Whether you are a paying or free user, you can freely utilize these three features.