Penso che l'unica cosa da tenere a mente è che, mentre l'intestazione forza il browser a scaricare il file, questo non impedisce che l'asset venga incluso in una pagina effettiva se un utente malintenzionato trova un modo per iniettare esso. Ad esempio, se l'URL di download era simile al seguente:
http://example.com/download/{user_file_id}
E il server ha lasciato che i suoi riferimenti vengano iniettati direttamente in un'altra pagina:
<script src="http://example.com/download/{user_file_id}"></script>
Eseguirà comunque come javascript normale, indipendentemente dal content-disposition o da qualsiasi altra intestazione. Suppongo che non ci siano buone ragioni per cui l'applicazione inietta direttamente i file caricati come javascript, nel qual caso il rischio di compromettere il server sembra minimo.
Esiste tuttavia un minore aumento del rischio di compromissione per gli altri utenti sul server. Se un utente malintenzionato trova un modo per eseguire l'iniezione XSS sul sito Web, la possibilità di ospitare il proprio carico utile javascript sul server stesso consentirà inoltre di eludere qualsiasi protezione da qualsiasi impostazione di CSP . Di conseguenza, l'iniezione di XSS diventa più pericolosa.
In realtà anche se il rischio maggiore (da quello che ho capito sul sistema che hai descritto) è probabilmente un problema legale (nota: IANAL). Se qualcuno può caricare qualcosa sul server, immagino ci siano potenziali problemi legali di cui essere a conoscenza. Il server che descrivi potrebbe essere utilizzato efficacemente per distribuire qualsiasi informazione / file / contenuto desiderato da chiunque abbia accesso ad esso: specialmente se il servizio non richiede l'autenticazione. Cosa succede se qualcuno decide di usarlo per distribuire la pedopornografia? Questo è un esempio estremo, ma a volte queste cose sono sfortunatamente rilevanti, e ci sono molti esempi meno estremi che ancora causano problemi.