Troubleshooting guide · images · Published 2026-08-15 · 4 min read
Stop other sites hotlinking your images
Stop hotlinking: see how it wastes origin bandwidth, block at the server or CDN edge with referrer rules, and handle false positives.
- ·What hotlinking does
- ·Block at the edge
- ·Blocks that backfire
What hotlinking does
Hotlinking is when another site embeds your image directly by URL: <img src="https://yoursite.com/media/photo.jpg">. From the visitor's point of view the image appears fine. From your side, every one of that site's page views makes a request to your origin (or your CDN edge) for a file you did not ask to serve.
The effect on the origin is bandwidth you never budgeted for. A small test that goes viral, or a scraper that reuses products, can multiply your image egress several times over in a day. The file is not modified, but the traffic is yours to pay for and serve. If the same image is also linked from a trusted page, the distinction is only the Referer header.
Block at the edge
The cleanest place to stop hotlinking is the CDN, because it also serves most of the traffic. Two typical approaches:
- CDN hotlink protection (for example Cloudflare's built-in "hotlink protection" toggle). The toggle allows empty Referer, so direct visits and link previews still work, and it only blocks requests whose non-blank Referer does not match your site. Blocking empty Referer requires a configured access rule, not the toggle.
- WAF/access rules matching the
Refererheader for the media path, returning a 403. The 403 reference covers the status semantics.
On a plain server (Apache or nginx) the classic is a rewrite/deny rule that checks the Referer, but the CDN layer doing it is preferred: it stops the request before hitting the origin and still lets your own pages through.
A concrete example: reverse the rule's reflex. Decide first what you want to allow, not block: your own domains, plus direct navigations and link previews that send no Referer. Then reject everything else for the media path.
Allowlist correctly
An effective rule needs the correct allowlist:
- Your own domains (the site's canonical and any staging).
- Empty or missing referer, if you want direct visits and share previews to work.
- Occasionally a known partner site you want to permit.
Make the rule match on the path of the images directory, not the whole origin, to avoid blocking API traffic that legitimately reads the domain.
Blocks against backfire
Time-limited or overly eager blocks break legitimate visitors:
- Users opening the image in a new tab (a direct navigation) can still get a 403 if the referer is empty and you blocked that case.
- Some email clients and previews use an empty referer for security.
- Test the block from a different browser and a private window before enabling it in production, because your own cached session may mask it.
The main alternative to a block is to change what a hotlinked image shows: add a watermark into the upload pipeline so copies carry your brand, and accept the exposure as free distribution. That trades bandwidth costs for reach, and it is sometimes the better call when the images are marketing material. The CDN guide also covers serving unique hashed filenames, which defeats direct-path guessing for assets you do not want reusable.
Ordered fix steps
- Confirm the leak: check CDN analytics or server logs for image paths with unusual referer patterns by domain.
- Choose a block: CDN hotlink protection or a
Refereraccess rule scoped to the media path. - Allowlist your own domains plus empty referer if they should work.
- Test in a private window and from another domain; confirm your own site still renders images.
- Watch for new false-positive reports in the review period after.
Hotlinking is mostly solved by edge config, not by renaming files, and the http 403 reference plus CDN guide keep the block correct.