Creo que lo único que debe tener en cuenta es que, si bien el encabezado obliga al navegador a descargar el archivo, esto no impide que el activo se incluya dentro de una página real si un usuario malintencionado encuentra una forma de inyectar eso. Por ejemplo, si la URL de descarga fue algo como esto:
http://example.com/download/{user_file_id}
Y el servidor permite que las referencias a él se inyecten directamente en otra página:
<script src="http://example.com/download/{user_file_id}"></script>
Todavía se ejecutaría como un javascript normal, independientemente del content-disposition o de cualquier otro encabezado. Supongo que no hay una buena razón para que la aplicación inyecte directamente los archivos cargados como javascript, en cuyo caso el riesgo de que comprometa al servidor parece mínimo.
Sin embargo, existe un menor riesgo de compromiso con otros usuarios en el servidor. Si un usuario malintencionado encuentra una forma de realizar una inyección XSS en el sitio web, la capacidad de alojar su carga útil de javascript en el servidor, además, les permitirá eludir cualquier protección de cualquier configuración de CSP . Como resultado, la inyección XSS se vuelve más peligrosa.
En realidad, aunque el mayor riesgo (por lo que entiendo del sistema que describió) es probablemente por cuestiones legales (nota: IANAL). Si alguien puede cargar cualquier cosa en el servidor, me imagino que existen posibles preocupaciones legales que debe conocer. El servidor que usted describe podría usarse efectivamente para distribuir cualquier información / archivos / contenido que desee cualquier persona que tenga acceso a él: especialmente si el servicio no requiere autenticación. ¿Qué sucede si alguien decide usarlo para distribuir pornografía infantil? Ese es un ejemplo extremo, pero a veces tales cosas desafortunadamente son relevantes, y hay muchos ejemplos menos extremos que todavía causan problemas.