Sanitizing Uploaded Files Before They Reach a Page

Upload buttons are everywhere in our platform. Owners add logos, members upload profile pictures, editors drop images into posts and imports bring in thousands of files at once. Every one of those files will eventually be shown to someone: an administrator, a member or a visitor to a public page.

That makes uploads one of the most important places to be careful. A file can be more than it appears, and the safest assumption is that any upload might be hostile until checked.

The file name tells you very little

A file called "logo.png" might be an image. It might also be something else renamed to look like one. So we never trust the name or the type the browser claims. We inspect the file's actual contents to determine its real type, then compare that against a list of types allowed for that field.

A profile picture field accepts images. A course download might accept documents. Nothing accepts executable programs. When a file does not match, it is rejected with a clear message rather than stored and hoped for.

Size limits by type

Each kind of file has its own size limit. Images, documents, audio and video have very different reasonable sizes, so a single limit for everything would be either too strict or too loose. Sensible limits protect storage, keep pages fast and stop a single upload from tying up the server.

SVG images get special care

SVG is a popular image format for logos and icons because it stays sharp at any size. Unlike a photo, though, an SVG file is text, written in a markup language that can include scripts and links. A malicious SVG could run code in a visitor's browser if it were displayed carelessly.

So every SVG that enters our media library is sanitized: scripts, event handlers and other risky elements are removed before the file is stored. What remains is the drawing itself.

Scanning when enabled

Our media library can scan uploads for known malware before they are kept permanently. When scanning is turned on, a file that fails the check is rejected and the attempt is recorded. Scanning is one layer among several, not a substitute for type checks and sanitizing.

Private files stay private

Not every upload belongs on a public page. Accounting attachments, exported reports and other sensitive documents are stored with private visibility, outside the public folder, and served only after checking who is asking. A field that holds private files declares it in our code, so a private document cannot be filed into the public media library by mistake.

Imports follow the same rules

Website imports download many files at once, often from sources we do not control. They go through the same checks as any other upload. An import that brings in thousands of images does not get a shortcut around type checks or sanitizing.

Rich text and pasted content

Files are not the only things people upload. Editors paste text from other websites, documents and emails into blog posts and pages, and pasted content can carry hidden markup, tracking images or scripts. Our rich-text editor keeps a defined set of formatting, such as headings, lists, quotes and links, and content we convert from formats like Markdown is processed with raw HTML removed and unsafe link types blocked. The same principle applies: keep what the author meant to share, drop anything that could act on a visitor's browser.

Output matters as much as input

Sanitizing what comes in is half the job. The other half is displaying files safely: setting the right content type when serving them, using image tags rather than embedding raw markup, and escaping file names and captions wherever they appear in a page. Defense works best in layers.

Part of keeping each account's files safe

These checks sit alongside the rest of our approach to files: each upload belongs to one account, duplicates are recognized by fingerprint and assets from imports are brought home. You can read about that in keeping each customer's files in their own space. Security that customers never have to think about is the goal across our Technology & Impact work.

Frequently asked questions

Why are SVG files risky?

SVG files are text-based and can contain scripts. If displayed without sanitizing, a malicious SVG could run code in a visitor's browser.

Can someone upload a program disguised as an image?

Uploads are checked by their actual contents, not their names, and executable files are never accepted, so a renamed program is rejected.

Are private documents ever stored in the public media library?

No. Fields that hold private files store them outside the public folder and serve them only after checking permissions.