User

Hotlink Protection

Block other websites from embedding your images and files. Saves bandwidth and prevents content theft.

Last updated 1775692800
  • Disabling Hotlink Protection
  • Limitations
  • Troubleshooting
  • Hotlinking (or "inline linking") is when another website embeds an image or file from your server using its full URL — without copying the file to their own server. The visitor's browser still downloads the file from you, so you pay the bandwidth cost while another site benefits from your content.

    Hotlink protection blocks these requests automatically. When enabled, your server inspects the Referer header on each request for protected file types and only serves the file if the request comes from your own domain (or another domain on your whitelist).

    How It Works

    Every browser request for an image or file includes a Referer header indicating which page is requesting it. Hotlink protection compares that header against an allowed list:

    • Request from your own domain → file served normally.
    • Request from a whitelisted external domain → file served normally.
    • Direct access (visitor types the URL or saves the image) → served if "Allow direct access" is enabled (default).
    • Request from any other domain → blocked with a 403 Forbidden response, or redirected to a URL of your choice.

    The protection is implemented at the web server level — both Nginx and Apache (when .htaccess mode is enabled) honour the rules.

    Enabling Hotlink Protection

    1. Open the Security → Hotlink Protection page in the sidebar.
    2. Find the domain you want to protect.
    3. Tick Enable hotlink protection for this domain.
    4. Configure the options below.
    5. Click Save.

    Options

    Allowed external domains

    A list of additional hostnames that are allowed to embed your files. Your own domain (example.com and www.example.com) is always allowed automatically — you do not need to add it.

    Enter one hostname per line. Examples:

    cdn.example.com
    partner-site.com
    mail.google.com
    

    If you have no external sites embedding your files, leave this empty.

    Protected file extensions

    The list of file extensions to enforce hotlink protection on. Only files matching one of these extensions are checked — everything else is served normally.

    Default: jpg, jpeg, png, gif, webp, svg

    You can extend this to include videos (mp4, webm), audio (mp3), documents (pdf), or archives (zip) if you want to block hotlinking on those file types too.

    Allow direct access

    When enabled (default), requests with no Referer header are allowed. This covers:

    • Visitors typing the image URL directly into their browser
    • Saving an image (right-click → Save As)
    • Bookmarking an image
    • Some search engines and social media link previews

    If you disable this option, only requests with a valid Referer header from a whitelisted domain will be served. This is more restrictive — and may break image previews on social media or search results.

    Recommendation: Leave "Allow direct access" enabled unless you have a specific reason to block it.

    Redirect blocked requests to

    By default, blocked requests return HTTP 403 Forbidden — the embedded image becomes a broken link on the offending site.

    You can instead enter a URL to redirect blocked requests. A common trick is to redirect to a "stolen image" warning image hosted on your own domain — so when someone hotlinks your photo, the image they embed gets replaced with a notice telling visitors to come to the original site.

    Example:

    https://example.com/stolen.png
    

    Disabling Hotlink Protection

    Untick Enable hotlink protection for this domain and click Save. The protection rules are removed from both the Nginx include file and the .htaccess file (if you're using .htaccess mode).

    Limitations

    Spoofed Referer headers. Sophisticated scrapers can fake the Referer header to bypass protection. Hotlink protection blocks the vast majority of casual hotlinking but is not bulletproof against determined attackers. For high-value content, consider using signed URLs or token-based authentication at the application level.

    Search engine image indexing. If your blocked extensions include jpg and png, Google Image Search and other image search engines may have trouble indexing your images. Most search bots send a Referer header from google.com, but if you find your images disappearing from search results, add google.com, googleusercontent.com, and any other relevant search engines to your whitelist.

    Caching CDNs. If you use Cloudflare or another CDN, the Referer check happens at the CDN level for cached files — your server's hotlink rules only apply to uncached requests. Configure hotlink rules in your CDN settings as well.

    Troubleshooting

    My own images are returning 403. Make sure your domain is correctly entered. The protection automatically allows your own domain and www. subdomain, but if you serve images from a different subdomain (e.g. cdn.example.com), add it to the allowed external domains list.

    My images broke after enabling protection. The most common cause is that the page loading the image is being served from a different domain than expected (e.g. you're testing on staging.example.com but only example.com is allowed). Add the testing domain to the whitelist.

    Direct image access is being blocked. Make sure Allow direct access is ticked. With this disabled, opening an image URL directly in a browser will return 403 because there is no Referer header.

    Images embedded in emails are blocked. Email clients usually do not send Referer headers when loading images. Keep Allow direct access enabled to allow them.