CORS ne bloque pas le hotlink, il ne filtre que le JS cross-origin. Un Worker avec check Referer pour le public, des presigned URLs pour le privé.
Des images servies depuis un bucket apparaissent sur des sites tiers qui consomment la bande passante. Le réflexe est d’activer CORS. C’est le mauvais outil pour ce problème.
CORS ne fait pas ce qu’on croit
CORS protège l’utilisateur contre du JavaScript cross-origin qui lirait une réponse. Il agit dans le navigateur, après coup, sur les requêtes pilotées par script. Une balise img qui charge une URL n’est pas concernée par CORS.
Le hotlink, c’est exactement ça : un img src vers votre bucket depuis un autre domaine. Aucun en-tête CORS ne l’arrête. Le fichier est servi, la facture monte.
Referer permissif pour le public, presigned pour le privé
Pour du contenu public, un Worker en frontal vérifie l’en-tête Referer. La règle reste permissive : on autorise ses propres domaines et le Referer absent, fréquent et légitime. On bloque les domaines tiers connus. C’est un filtre de confort, pas une serrure.
Pour du contenu privé, on ne se fie pas au Referer, qui est trivial à falsifier. On émet des presigned URLs : un lien signé, à durée de vie courte, valable pour un objet précis. Pas de signature, pas d’accès.
Le principe : adapter le contrôle au contenu. Referer pour décourager le hotlink public, signature pour verrouiller le privé. CORS ne joue dans aucun des deux cas.