In my last post, we looked at how to get files off a user’s device and onto your server using Multer. But simply catching a file is only half the battle.
Once that file lands on your filesystem, you have to answer three critical architectural questions:
Where should this file live long-term?
How does a browser actually fetch and display it?
How do we prevent a malicious user from uploading a script that takes over our entire server?
Handling file storage incorrectly can make your server incredibly slow, delete your users' data during a routine deployment, or leave you wide open to severe security exploits. Let’s break down how to design a safe, reliable file-handling system in Express.js.
Where Uploaded Files Live: Local vs. External
By default, when you configure Multer, it saves files to a local directory on your server. Your project directory structure probably looks something like this:
my-express-app/
├── node_modules/
├── public/
│ └── images/
├── uploads/ <-- User uploads are written here
│ ├── profile-pics/
│ └── invoices/
├── server.js
└── package.json
Writing directly to the /uploads folder is called local storage. It is fast, costs nothing extra, and requires zero external network configuration. For local development or hobby projects, it’s perfect.
However, in professional production environments, local storage is a massive anti-pattern. Here is why:
Ephemeral Filesystems: Modern hosting platforms (like Render, Heroku, or AWS Elastic Beanstalk) and container tools (like Docker) use ephemeral disks. Every time you deploy new code, or your server automatically restarts, the local disk is wiped clean. If your users' profile pictures are stored locally, they vanish.
Horizontal Scaling: If your application becomes popular and you run it on three servers instead of one, a user who uploads an avatar to Server A won't be able to see it if their next request is routed to Server B.
This is why production apps use external cloud storage (like AWS S3, Google Cloud Storage, or Cloudinary). In this model, your Express server acts as a middleman: it catches the upload, immediately pipes it to a secure, persistent external cloud bucket, and then forgets about it.
We will stick to local storage for our coding example, but remember: the local disk is for testing; the cloud is for production.
Serving Static Files in Express
Once a file is saved locally, how does a client fetch it?
An image, PDF, or CSS sheet is a static file. Unlike a dynamic JSON response, a static file doesn't need to be processed or generated by your JavaScript code. The server just needs to read the raw bytes off the disk and stream them directly to the client's browser.
If you tried to write a custom endpoint for every single file, your server would crawl to a halt. Instead, Express provides a built-in middleware called express.static() to handle this efficiently.
const express = require('express');
const path = require('path');
const app = express();
// Protect against directory-switching bugs by using absolute paths
const uploadsDirectory = path.join(__dirname, 'uploads');
// Serve the 'uploads' folder on the '/uploads' URL path
app.use('/uploads', express.static(uploadsDirectory));
This line tells Express: "If a request path begins with /uploads, stop evaluating normal routes. Instead, look inside the physical uploads/ folder on our hard drive. If you find a file that matches the rest of the URL, serve it. If you don't, return a 404."
Accessing Uploaded Files via URL
With the static middleware in place, there is a direct mathematical mapping between your folder structure and the URL the client uses.
If you have a file stored on your server at: /my-express-app/uploads/profile-pics/avatar-123.jpg
A client can load this image in their browser or render it in an HTML <img /> tag using this URL: http://localhost:3000/uploads/profile-pics/avatar-123.jpg
Express automatically strips the /uploads prefix from the URL, looks inside your physical /uploads folder, traverses into profile-pics/, finds avatar-123.jpg, and streams it back to the browser with the correct headers.
Security Considerations: Keeping Your Server Safe
Allowing users to write files to your server is one of the most dangerous things you can do in web development. If you aren't careful, a malicious actor can easily compromise your system.
Here are three non-negotiable security practices you must implement for any file upload system:
1. Strictly Limit File Sizes
If you do not set a limit, an attacker can write a simple script to upload a massive 10GB dummy file to your server. Doing this a few times will completely fill your server's storage disk, causing your database and operating system to crash (a classic Denial of Service attack).
2. Validate File Types (MIME types)
Never trust the file extension. Anyone can rename a malicious executable script (malware.exe or shell.sh) to photo.jpg and bypass basic checks. You must check the actual file format (the MIME type).
3. Sanitize and Randomize Filenames
If a user uploads a file named ../../../etc/passwd, and your server writes that path literally to the disk, the file system might interpret the ../ commands and overwrite critical system configuration files. This is called a directory traversal attack. Always generate a random, unique filename on your server rather than using file.originalname.
Putting Security into Code
We can implement all of these security rules directly inside our Multer configuration:
const express = require('express');
const multer = require('multer');
const path = require('path');
const storage = multer.diskStorage({
destination: 'uploads/',
filename: (req, file, cb) => {
// Rule 3: Ignore original names, generate a random hash/timestamp
const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1E9);
const ext = path.extname(file.originalname);
cb(null, 'file-' + uniqueSuffix + ext);
}
});
const upload = multer({
storage: storage,
// Rule 1: Set file size limit to 5MB (measured in bytes)
limits: { fileSize: 5 * 1024 * 1024 },
// Rule 2: Validate the MIME type
fileFilter: (req, file, cb) => {
const allowedTypes = ['image/jpeg', 'image/png', 'image/webp'];
if (allowedTypes.includes(file.mimetype)) {
cb(null, true); // Accept the file
} else {
cb(new Error('Invalid file type. Only JPEG, PNG, and WebP are allowed.'), false); // Reject
}
}
});
// Route handler
const app = express();
app.post('/upload', upload.single('photo'), (req, res) => {
res.json({ message: "File uploaded safely!", file: req.file });
});
// Error handling middleware to catch file-filter and size errors cleanly
app.use((err, req, res, next) => {
if (err instanceof multer.MulterError) {
return res.status(400).json({ error: `Upload error: ${err.message}` });
} else if (err) {
return res.status(400).json({ error: err.message });
}
next();
});
The Takeaway
Handling file uploads successfully is about balance. You want to make it incredibly easy for legitimate clients to view and share their static files via simple, predictable URLs. But you must also treat every incoming binary chunk as a potential security threat.
By combining express.static with strict size boundaries, MIME type checks, and randomized file naming conventions, you can build a file pipeline that is highly performant and incredibly secure. Protect your server, and the web will run smoothly.
