35. Téléchargements et Content-Disposition

Comprendre le mécanisme

Content-Disposition peut indiquer qu’une représentation doit être proposée en pièce jointe et fournir un nom de téléchargement. Ce nom est une métadonnée de présentation, pas une autorisation ni un chemin serveur sûr. Les variantes de paramètres permettent de traiter des noms selon un encodage défini ; une construction manuelle à partir d’une entrée libre peut introduire une syntaxe incorrecte. Utilisez l’API du framework prévue pour cet en-tête.

Raisonner et vérifier

Le serveur doit résoudre un identifiant de document vers une ressource autorisée, sans laisser l’appelant choisir arbitrairement un chemin du système de fichiers. Contrôlez les permissions à chaque téléchargement sensible et définissez cache et durée de disponibilité. Un lien signé est un contrat à part entière : sa portée, son expiration et sa diffusion doivent être explicites, sans confondre signature du lien et identité de toute personne qui le possède.

Présentation

Content-Disposition décrit la présentation du fichier. La permission doit être vérifiée séparément. Content-Disposition: attachment suggère un téléchargement au client. Cette instruction ne vérifie ni propriétaire ni confidentialité ; un document interdit reste une fuite même si le navigateur propose de l’enregistrer.

Résolution maîtrisée

Un identifiant métier peut être résolu en chemin contrôlé. Le serveur doit limiter les ressources distribuées. Recevez un identifiant métier puis résolvez côté serveur un chemin autorisé. N’exposez pas un paramètre de chemin libre qui donnerait au client la possibilité de choisir un fichier système.

Nom de fichier

Les noms de fichiers doivent passer par une API adaptée. La construction doit empêcher les caractères et syntaxes indésirables. Utilisez une API de construction de disposition pour gérer caractères et encodage. Un nom provenant du client doit être contrôlé et ne doit pas être concaténé dans une ligne HTTP brute.

Avant lecture

Le propriétaire de l’objet doit être vérifié avant lecture. Une ressource existante peut être privée. Vérifiez l’acteur et le sujet avant d’ouvrir ou streamer le document. Une erreur tardive peut arriver après émission partielle de données, même si le statut final semble refuser l’accès.

URL opaque

Une URL opaque reste sensible selon son contrat. L’opacité ne prouve pas la permission. Une URL non devinable peut être une capacité au porteur selon son contrat. Protégez durée, diffusion et logs ; l’opacité ne remplace pas automatiquement une autorisation quand celle-ci est exigée.

Type explicite

Le type servi doit correspondre au contrat. Le serveur doit connaître la représentation distribuée. Servez le format prévu avec un Content-Type correct et les protections d’interprétation adaptées. Une extension de téléchargement ne doit pas être l’unique source de vérité sur la représentation reçue.

Cache

Les réponses privées demandent une politique de cache. La présentation ne définit pas seule le stockage. Un document personnel exige une stratégie de stockage et de partage cohérente. Vérifiez navigateur, CDN et routes alternatives ; attachment n’empêche pas à lui seul la conservation d’une copie.

Erreurs minimisées

Les erreurs doivent éviter de révéler des chemins internes. Le diagnostic public doit rester minimisé. Un fichier absent ne doit pas exposer son chemin interne complet ou les répertoires du serveur. Retournez une catégorie publique stable et gardez le diagnostic privé nécessaire à l’exploitation.

Budgets

Le téléchargement doit respecter des budgets de ressources. Les limites de service restent nécessaires. Bornez taille, durée et concurrence de téléchargement selon la capacité. Un streaming peut réduire la mémoire sans rendre gratuits bande passante, descripteurs et occupation de connexion.

Document tiers

Un test doit tenter la lecture d’un document tiers. La frontière d’autorisation exige un cas négatif. Créez deux comptes et demandez avec B le document de A. Vérifiez refus et absence d’octets confidentiels, puis un cas propriétaire qui reçoit exactement le document prévu.

Atelier guidé : lire, expliquer et vérifier le code

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="lab-report.pdf"

Contexte : document d’un autre compte, aucune autorisation vérifiée.

Le document appartient à un autre compte et aucun contrôle n’est exécuté. Les headers PDF et attachment ne corrigent pas cette absence. Placez l’autorisation avant la lecture des octets puis vérifiez le refus avec un identifiant valide d’un tiers et une réponse sans contenu partiel.

Répéter le mode de présentation ne change pas les droits. Le renommage ne crée pas d’autorisation. Les champs de présentation ne valident pas l’accès à l’objet. Le nom ne donne pas la permission.

Travail pratique : Créez deux documents fictifs appartenant à deux acteurs et testez leur téléchargement par identifiant. Ajoutez un nom de fichier Unicode.

Critères de correction : Vérifiez les permissions avant ouverture du fichier, générez l’en-tête avec l’API prévue et testez le nom présenté. Refusez les identifiants inconnus ou interdits sans exposer de chemin interne ni de trace.