Le lien CDN qui ne voulait pas mourir

L’échec de confidentialité le plus embarrassant n’est parfois pas une intrusion. C’est une URL.

Un utilisateur supprime une image depuis votre application. Le tableau de bord ne l’affiche plus. La ligne en base est supprimée, ou marquée comme supprimée, ou porte le petit drapeau de tombe que votre ORM préfère. Tout le monde se sent bien pendant environ quatre secondes.

Puis quelqu’un ouvre l’ancien lien CDN et l’image se charge encore.

Cela arrive parce que la suppression du produit et la suppression des assets sont deux tâches différentes. L’interface peut retirer l’objet de la vue de l’utilisateur, tandis qu’un bucket de stockage, un cache de bord CDN, un service de vignettes, un dossier de reprise de file d’attente, ou un chemin de sauvegarde conserve encore une copie. Du point de vue de l’utilisateur, la suppression signifiait « ne plus avoir ça ». Du point de vue du système, la suppression signifiait « ne plus rendre la page normale ».

Les produits d’images IA sont particulièrement vulnérables, car les sorties générées sont souvent servies comme des fichiers. Elles peuvent être mises en cache pour les performances. Elles peuvent avoir des vignettes. Elles peuvent être stockées sous des chemins prévisibles ou qui durent longtemps. Elles peuvent être copiées dans des outils de modération, d’analytics ou de support. Un lien direct peut survivre à l’interface comme un petit souvenir maudit.

La solution commence par le langage. Ne promettez pas une suppression si la promesse ne couvre que la vue de l’application. Dites ce qui se passe réellement, puis faites en sorte que l’implémentation suive. Si la suppression invalide les caches CDN, supprime les fichiers sources, retire les dérivés et expire les URL signées, c’est parfait. Si les sauvegardes conservent les données pendant une période fixe, dites-le aussi.

Techniquement, la voie la plus sûre consiste à éviter les URL publiques permanentes pour des sorties privées. Utilisez des URL signées avec de courtes expirations. Gardez les clés d’objets imprévisibles. Suivez les dérivés. Construisez des chemins de suppression qui incluent la source, la sortie, la vignette, le cache et les résidus de file d’attente. Testez la suppression comme le ferait un utilisateur : copiez l’URL avant de supprimer, supprimez l’image, puis essayez à nouveau l’URL.

Ce n’est pas une ingénierie glamour. Personne ne va mettre « l’invalidation de cache respecte vraiment les promesses de confidentialité » sur une bannière de lancement, même si, honnêtement, je respecterais la confiance. Mais c’est de ce genre de détails que naît la confiance.

Quand un utilisateur supprime une image générée par IA, le produit ne devrait pas le forcer à jouer au whack-a-mole avec des restes d’infrastructure. Le lien doit mourir avec la promesse.

Pour aller plus loin : Pourquoi « Delete My Uploads » doit être vérifiable, Pourquoi aucune galerie hébergée n’est une fonctionnalité produit, et Le stockage de données Unexposed.