File Processing Pipeline Testing

Purpose

"Can I upload a .php?" is one question about one stage. Real breakage happens BETWEEN stages: the validator accepts what the parser executes, the transformation library trusts what the upload validator rejected, the storage layer exposes what the application hides. Model the whole pipeline, then test every stage boundary and every trust handoff.

The Pipeline Model

upload -> validate -> store -> transform -> scan -> preview -> import -> process -> serve/download

Map which stages exist for YOUR target (not all do): is there a preview generator, a thumbnailer, a virus-scan step, an import parser, a download/share endpoint? Each arrow is a trust handoff where one stage assumptions about the file may no longer hold.

Stage-by-Stage Testing

Upload / validation boundary

• Filename: path segments, traversal (../../), reserved names, unicode lookalikes, very long names, null bytes, case variants (.PNG, .pHp), double extensions (report.pdf.php), trailing dot/space (file.php., file.php )
• Extension vs MIME vs magic bytes disagreement: declare image/jpeg, send PHP bytes with .jpg extension; note WHICH check each endpoint trusts
• Polyglots: GIF/JPEG containing embedded code, PDFs with JS, SVG with embedded scripts (SVG is XML: scripts and XXE live inside), HTML-in-image (served with wrong content-type becomes stored XSS)
• Content-Type the server assigns at STORE time vs at SERVE time (mismatch is the exploitable condition)

Storage

• Where does the file land: same-origin path (execution risk), CDN/object storage, separate storage domain?
• Is the stored object accessible directly (guessable URL, sequential name) BEFORE the app links it?
• Storage-level ACL: can the raw object be fetched unauthenticated once the URL is known?
• Overwrite: does uploading with the same name/fingerprint overwrite another user object (hash-collision namespaces)?