🔒️(backend) force SVG attachments to download to prevent stored XSS

[bunlongheng]

Summary

Uploaded SVG attachments are served inline with Content-Type: image/svg+xml, allowing stored XSS in the application origin.

image/svg+xml is missing from DOCUMENT_UNSAFE_MIME_TYPES, so an SVG passes the is_unsafe check and attachment_upload sets Content-Disposition: inline (the content_type.startswith("image/") branch). SVG documents can carry <script> and event handlers that execute when the file is opened directly.

Impact

• Media is served from the same origin as the app under /media/ (default MEDIA_URL = "/media/", MEDIA_BASE_URL = None).
• The strict CONTENT_SECURITY_POLICY only applies to Django responses; attachment files are served by the object storage backend via the nginx media-auth subrequest, so the Content-Type / Content-Disposition come from S3 object metadata and no CSP or nosniff header is applied to them.
• An authenticated user uploads a valid .svg (libmagic reports image/svg+xml, which matches the filename extension, so the existing extension-mismatch guard does not flag it). Any user who opens that attachment URL executes attacker-controlled JavaScript in the app origin, enabling session/cookie theft (CORS_ALLOW_CREDENTIALS = True). Documents with a public link reach make this reachable by any visitor.

Reproduction

1. Create a document and upload an attachment whose bytes are a well-formed SVG containing <script>alert(document.domain)</script>, named poc.svg.
2. The upload is stored with is_unsafe=false, Content-Type: image/svg+xml, Content-Disposition: inline.
3. Open the returned media URL directly in a browser. The script runs in the application origin.

Fix

Add image/svg+xml to DOCUMENT_UNSAFE_MIME_TYPES. Detected SVGs are then flagged is_unsafe=true, which makes attachment_upload set Content-Disposition: attachment (forced download) and append the -unsafe suffix, matching the existing handling for other active-content types. Raster image uploads (png, jpeg, ...) are unaffected and still served inline.

This mirrors the existing treatment of application/xhtml+xml, text/html, and script MIME types already in the list.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 1fca5819-3bd2-40ee-a19e-99fb73611466

📥 Commits

Reviewing files that changed from the base of the PR and between 44c51ff and be0c9d6.

📒 Files selected for processing (1)

• src/backend/impress/settings.py

---

Walkthrough

The unsafe document MIME-type configuration now includes image/svg+xml. SVG files are classified as unsafe document attachments.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Mergeability Score: ⚪ Minimal · up to be0c9

SVG attachments will be forced to download instead of rendering inline; no actionable merge-blocking risk remains at the current head after normal checks and review.

Suggested reviewers: lunika

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description directly explains the SVG stored XSS risk and the change that forces unsafe SVG attachments to download.
Title check	✅ Passed	The title clearly identifies the backend change and its purpose of forcing SVG attachments to download to prevent stored XSS.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[maboukerfa]

I've already come across this, but i think this claim is wrong:

Attachment files are served by the object storage backend via the nginx media-auth subrequest, so the Content-Type / Content-Disposition come from S3 object metadata, and no CSP or nosniff header is applied to them.

You can check the nginx config here: https://github.com/suitenumerique/docs/blob/main/docker/files/etc/nginx/conf.d/default.conf

location /media/ {
    ...
    proxy_pass .../impress-media-storage/;
    add_header Content-Security-Policy "default-src 'none'" always;
}

So all scripting falls back to 'none'. The XSS can't be triggered, and your POC isn't reproducible.