From c4d280542ac62204ce52468eca7fac20ba9fa711 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?K=C3=A9vin=20Commaille?= Date: Fri, 23 Aug 2024 12:32:38 +0200 Subject: [PATCH] Explain why trusting use content type is fine MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Kévin Commaille --- content/client-server-api/modules/content_repo.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/content/client-server-api/modules/content_repo.md b/content/client-server-api/modules/content_repo.md index a48b325d..17715504 100644 --- a/content/client-server-api/modules/content_repo.md +++ b/content/client-server-api/modules/content_repo.md @@ -204,7 +204,12 @@ one of the following values when serving content with `Content-Disposition: inli * `audio/flac` * `audio/x-flac` -These types are unlikely to cause Cross-Site Scripting issues within clients. +These types are unlikely to cause Cross-Site Scripting issues when a `Content-Type` +header is provided, as clients will only try to render the data using that content +type. For example, if a HTML file is uploaded with a `Content-Type` of `image/png`, +clients will just assume that the image is corrupted, and won't render it as a +HTML page. Therefore, there is no risk in trusting the user-defined content type, +as long as the `Content-Disposition` is calculated based on that type. Clients SHOULD NOT rely on servers returning `inline` rather than `attachment` on `/download`. Server implementations might decide out of an abundance of