Security #

Under dashboard’s Proxy detailed page, you will find a Security tab, which contains some security related settings.

User Agent for Origin #

For conventional CDNs, the User Agent used by visitors is directly forwarded to the origin server during CDN origin requests. However, WebP Cloud and traditional CDNs have some differences in this aspect.

Currently, WebP Cloud employs a fixed User-Agent string for origin requests: WebP Cloud Services/1.0. The user request process unfolds as follows:

A visitor initiates a request to
```
https://e52565b.webp.ee/some/cat.jpg
```
with the following headers:
- 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, requiring an origin fetch, WebP Cloud sends a GET request to the origin server at
```
https://blog.example.com/some/cat.jpg
```
with the following headers:
- User-Agent: WebP Cloud Services/1.0
Once WebP Cloud obtains the original image, it processes it accordingly and returns it to the visitor.

Here, this feature allows users to set their own User-Agent for origin requests. The default value is WebP Cloud Services/1.0, but users can customize it, for instance, as User-557f51ce-Custom. In this way, the User-Agent can function as a pre-shared key to ensure that the origin address can only be accessed by WebP Cloud, thus eliminating the issue of CDN penetration (bypass) due to guessing the origin address.

With a custom User-Agent set, the origin server can employ a configuration like the following to ensure that image requests are only allowed 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 configurations
    }
}

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 use a Bucket Policy to restrict access based on User-Agent. For example:

jsxCopy code{
    "Version": "2012-10-17",
    "Id": "OnlyAllowWebP",
    "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/*"
        }
    ]
}

Custom CORS header #

To reduce the possibility of images being directly embedded on external websites, we allow users to customize their CORS Header settings. This can be configured on the Dashboard, with the default value being *, indicating that all websites are permitted to use it. In the example above, if you wish for https://e52565b.webp.ee/some/cat.jpg to only be accessible from the blog domain https://blog.webp.se, you can set it as blog.webp.se. By making this setting, the Access-Control-Allow-Origin field in the response header will be configured to blog.webp.se. Consequently, for references from other websites, the image will be unable to be displayed directly (prompting a CORS error). This further diminishes the risk of hotlinking.

Custom Referer header limit #

The method described above for setting CORS Headers can effectively prevent frontend frameworks of other websites from referencing your images. However, there’s no way to prevent other websites from directly using the <img> tag to display images.

To address this, we provide an additional layer of restriction by limiting the “referer” field of websites. This further reduces the likelihood of image hotlinking.

The Referer request header contains the address of the current page that initiated the request, indicating that the current page was accessed through a link on the referring page. Servers typically use the Referer request header to identify the source of a request, which might be used for statistics, logging, and cache optimization.

For example, when a user accesses https://wordpress.webp.se/, the request header for accessing an image will include:

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

This request header informs the server which page is referencing the image. WebP Cloud’s recent feature allows users to set allowed “referer” values in the backend. The default value is *, which permits any referer. If you wish to restrict this, you can use a comma-separated list of domain names, such as wordpress.webp.se, nova.moe, dmesg.app, tuki.moe. If another domain attempts to embed the image directly using an <img> tag, WebP Cloud will respond with a 403 error to prevent the image from being displayed: