Security

Security #

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

  • Custom Proxy User Agent can be used as preshared key to origin
  • Extra Origin Fetch Headers allows you to add more header when WebP Cloud fetch images from your origin, you can read more from our blog WebP Cloud now supports custom origin fetch headers
  • Proxy CORS Header and Proxy Allowed Referer can help reduce your images being directly embedded on external websites.

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 #

If you’re using the same domain for both text and images, for example: https://docs.webp.se/hello for text/html content and https://docs.webp.se/path/to/image.jpg for images, then you can write rules like following to deny direct access to images

Please be sure the make changes accordingly

(http.user_agent ne "User-557f51ce-Custom") and (http.host eq "docs.webp.se") 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"))

If you’re using a dedicated domain for images, for example https://docs.webp.se/hello for text/html content and https://images-r2.webp.se/path/to/images for images, you can simply write rules like following to deny direct access to the whole domain without the specific User Agent.

Please be sure the make changes accordingly

(http.user_agent ne "User-557f51ce-Custom") and (http.host eq "images-r2.webp.se")

AWS S3 #

You can use a Bucket Policy to restrict access based on User-Agent. For example:

{
    "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: