Securing a Property Against Hotlinking and Abuse Without Breaking Partners
A SaaS company serves customer-uploaded documents and images through a CDN property. Bandwidth costs are rising because third-party sites embed their image URLs (hotlinking). The company also has B2B partners who legitimately embed assets on partner domains and need stable URLs. Security wants to block hotlinking. The property currently has no referer checks, no token authentication, and a 7-day TTL on images. Assets are public (no login required to view). A previous attempt to enable strict referer allow-listing broke several partners and caused a support spike. Traffic is 60% partner/embedded, 40% direct.
1. Evaluate referer-based hotlink protection for this scenario and explain why the previous attempt failed.
Read the worked answer
Referer checks are brittle here. Referers can be stripped by privacy settings, proxies, and some apps, producing false positives. Strict allow-listing broke partners because their domains weren't enumerated, and some partner traffic arrives with missing or unexpected referers. With 60% of traffic embedded, a strict allow-list has a large blast radius.
Referer checks also don't stop determined abusers, who can spoof the header or use a proxy. So the previous attempt traded real partner breakage for weak protection. The failure was a design mismatch: a blunt control applied to a mostly-legitimate embedded traffic base.
2. Propose a layered approach that reduces hotlinking while preserving partner embeds.
Read the worked answer
Layer controls by risk and reversibility:
- Signed URLs / token authentication for assets that don't need to be public, with short expiries. For truly public assets, use token auth scoped to partner-issued tokens so partner embeds carry valid tokens.
- Referer allow-listing in monitor-only mode first: log would-be blocks, build the partner domain list from real traffic, then enforce gradually. Keep a permissive fallback for missing referers.
- Rate limiting and bot detection at the edge to catch scraping/abuse patterns rather than legitimate embeds.
- Separate properties/CP codes for public vs. partner assets so policies and billing are clean.
- Alerting on bandwidth anomalies by referer and geography.
Rationale: signed tokens give cryptographic control where needed; monitor-then-enforce referer rules avoid the prior breakage; rate limiting addresses abuse that header checks miss. The 60/40 split argues for protecting partner traffic explicitly rather than blocking broadly.
3. How would you validate the change before full rollout?
Read the worked answer
Run a canary on a slice of traffic with referer rules in log-only mode, compare blocked-candidate volume against the known partner list, and reconcile with support tickets. Use staged enforcement (e.g., 5% → 25% → 100%) with rollback ready. Track bandwidth by referer, 403 rates, and partner-reported breakage. Only enforce where monitor data shows low false-positive risk, and keep an exception list for partners. This turns a prior blunt rollout into a measured, reversible change.