A marketplace hosts seller-generated content including descriptions, images and shop pages. Which common web risks are amplified, and what controls apply?

Why seller-generated content amplifies risk

The platform is deliberately hosting content authored by untrusted parties and displaying it to other users. Every input-handling weakness becomes a vector, and the volume of content makes manual review impossible.

The amplified risks

1. Cross-site scripting through rich content. Sellers want formatting, so the platform allows some HTML. Every allowance is an opportunity. The controls that work:

• Allowlist-based sanitisation on the server, never blocklist-based. Blocklists are defeated by encoding, nesting and parser differences.
• A strict content security policy that prevents inline script execution even if sanitisation is bypassed. This is the defence in depth that converts a sanitisation bug from a full compromise into a cosmetic defect, and it is the single highest-value control here.
• Serving user content from a separate origin, so a bypass cannot access the main application's cookies or storage.

2. Insecure direct object references. Marketplace URLs contain identifiers for orders, messages, listings and shops. Any endpoint that fails to verify ownership exposes another seller's data. The control is authorization at the data access layer rather than in each handler, so a new endpoint cannot forget.

3. Server-side request forgery through image URLs. If sellers can supply an image URL that the platform fetches, that fetch originates from inside the platform's network. Controls: fetch through an egress proxy with an allowlist, block internal address ranges including redirects to them, and validate the response type.

4. File upload handling. Images that are not images, files with misleading types, decompression bombs, and content that exploits the image processing library — which is a common source of remote code execution. Process untrusted media in an isolated, resource-limited sandbox.

5. Content injection into non-HTML contexts — a shop name appearing in an email, a CSV export (formula injection), a PDF, or a log file. Each context needs its own escaping, and this is the most commonly missed category because the review focuses on the web page.

The architectural control that matters most

Treat all seller content as untrusted at every point of use, and make the safe path the default: a templating layer that escapes by default, sanitisation in one shared library rather than per feature, and a content security policy that limits the damage when something gets through.

Per-feature security decisions in a platform with hundreds of features will be wrong somewhere; platform-level defaults are what make the aggregate defensible.