5. Considérations de sécurité
5. Considérations de sécurité
Les considérations de sécurité pour PATCH sont presque identiques aux considérations de sécurité pour PUT ([RFC2616], section 9.6). Celles-ci incluent l'autorisation des requêtes (éventuellement par le contrôle d'accès et/ou l'authentification) et la garantie que les données ne sont pas corrompues par des erreurs de transport ou par des écrasements accidentels. Tous les mécanismes utilisés pour PUT peuvent être utilisés pour PATCH également. Les considérations suivantes s'appliquent particulièrement à PATCH.
Un document qui est corrigé peut être plus susceptible d'être corrompu qu'un document qui est écrasé dans son intégralité, mais cette préoccupation peut être abordée par l'utilisation de mécanismes tels que les requêtes conditionnelles (conditional requests) utilisant des ETags et l'en-tête de requête If-Match comme décrit dans la section 2. Si une requête PATCH échoue, le client peut émettre une requête GET à la ressource pour voir dans quel état elle se trouve. Dans la plupart des cas, le client peut vérifier le contenu de la ressource pour voir si le PATCH a abouti à l'état attendu.
Parfois, un intermédiaire HTTP (intermediary) peut tenter de détecter les virus envoyés via HTTP en vérifiant le corps de la requête PUT/POST ou de la réponse GET. La méthode PATCH complique une telle surveillance car ni le document source ni le document de correctif ne peuvent être un virus, mais le résultat pourrait l'être. Cette considération de sécurité n'est pas matériellement différente de celles déjà introduites par les téléchargements par plage d'octets (byte-range downloads), le téléchargement de documents de correctif, le téléchargement de fichiers compressés, etc.
Les formats de documents de correctif individuels auront leurs propres considérations de sécurité spécifiques qui seront documentées avec ces formats. Les applications utilisant PATCH doivent prendre en compte toutes les considérations de sécurité associées aux formats spécifiques qu'elles prennent en charge. Cependant, certaines considérations générales s'appliquent à tous les formats de documents de correctif, notamment:
- Les documents de correctif peuvent contenir des instructions pour modifier des parties d'une ressource que le client n'est pas autorisé à modifier. Un tel PATCH devrait être rejeté par le serveur.
- Certains formats de documents de correctif peuvent avoir des dispositions pour les requêtes conditionnelles. Le serveur DOIT (MUST) s'assurer que de telles conditions sont évaluées en fonction de l'état de la ressource au moment de l'opération, et non de l'état au moment de la requête.
- Les serveurs DOIVENT (MUST) être prudents lors de la validation des ressources contenant du contenu non fiable (par exemple, des données fournies par l'utilisateur). De nombreuses opérations de validation nécessitent l'analyse de la ressource, et l'analyse de contenu non fiable présente des opportunités d'attaques par déni de service (denial-of-service attacks) et d'autres comportements malveillants.
- Les documents de correctif peuvent ne pas avoir de taille maximale définie dans le format du document de correctif. Les serveurs peuvent vouloir établir leur propre taille maximale pour les documents de correctif afin de se protéger contre les attaques utilisant des documents de correctif très volumineux, et rejeter les documents de correctif trop volumineux avec le code d'état 413 (Request Entity Too Large).
- Les concepteurs d'applications doivent considérer l'impact des opérations de correctif sur les ressources qui peuvent être distribuées sur plusieurs emplacements. Par exemple, un correctif peut réussir sur une copie d'une ressource mais échouer sur une autre, entraînant une divergence d'état des ressources (resource state divergence).