Hotlinking is when another site embeds an tag pointing straight at a file on your server instead of hosting their own copy. Every visitor to their page downloads the image from your account, so you pay the bandwidth and they get the content. The fix is cPanel's Hotlink Protection tool: it blocks image requests that don't come from your own domain, so browsers loading your images from someone else's page get a broken image or a redirect instead of a free ride.
Set it up in a few minutes:
- Open cPanel from your hosting service.
- Find Hotlink Protection under Security.
- Add your own domain (and any subdomains you use) to the list of allowed sites.
- List the file extensions to protect: typically
jpg,jpeg,png,gif,webp,svg. Leave out extensions you're not worried about. - Optionally set a redirect URL, so blocked requests show a specific image (a logo, a "please don't hotlink" graphic) instead of a broken icon.
- Click Enable.
How it actually blocks requests
Hotlink Protection works off the HTTP Referer header, the field a browser sends identifying what page requested the resource. When a request for one of your protected file types arrives with a Referer that isn't your domain (or is empty), the server refuses to serve the real file. It either returns the redirect image you configured or a plain error, depending on your settings.
This means it only catches browser-driven hotlinking. Requests that omit the Referer header entirely, like some scrapers, bots, or direct curl requests, get treated as "no referrer" and are handled by whatever you set for that case. Most legitimate browser traffic sends a referrer, so this covers the common case: someone's forum post, blog, or marketplace listing embedding your product photo directly.
The bandwidth math
Hotlinking costs you twice: it uses your storage's read bandwidth, and it does it for traffic that gives you nothing back, no page views, no visitors, no conversions. A single popular image linked from a high-traffic forum or a Pinterest-style aggregator can generate meaningful, unbudgeted egress over a month. If you've noticed disproportionate bandwidth usage relative to your own traffic, checking your access logs for repeated image requests with foreign Referer values is the fastest way to confirm hotlinking is the cause before you go looking anywhere else.
What it doesn't stop
Hotlink Protection blocks direct file access based on referrer, not copying. It won't stop someone from downloading your image and re-uploading it to their own server, that's a copyright issue, not a bandwidth one. It also won't help with a fully separate concern like restricting who can browse a folder at all; for that, see password-protecting a directory, which puts a login prompt in front of a path rather than filtering by referrer.
If your site spans multiple domains you control, addon domains, aliases, or subdomains, add all of them to the allowed list. Otherwise your own alias or staging subdomain (see addon domains, aliases, and subdomains) will get blocked from loading images off the primary domain, which is a common self-inflicted bug right after enabling protection.
If you're also serving images via app or API
If images are served through a Node.js app rather than directly from static files, referrer-based blocking at the web server level won't apply the same way, you'd need to check the Referer header in your application code instead.
When to contact support
If you've enabled Hotlink Protection and traffic still looks off, or you're not sure whether a bandwidth spike is hotlinking versus something else like a bot crawl, open a ticket from the portal under Support → New ticket. A real person can pull your logs and help you tell the difference.