Stop trusting file extensions: validating uploads by content (with ffmpeg)

Usman Farooqi — Wed, 11 Nov 2026 17:24:49 +0000

A user of my free tool uploaded a recording named voice.m4a and got "This doesn't look like a real .m4a file." The file was fine. It was a WebM/Opus recording that had been saved with an .m4a extension. My upload check was wrong, not the user.

This is a short write-up of what I changed, and why file extensions are the wrong thing to trust.

The bug

My converter (Node + ffmpeg) checked the first bytes of an upload against the file's extension:

// before: decide by extension, then check one signature
case "m4a":
  return head.slice(4, 8).toString() === "ftyp";

Real files are renamed all the time: WebM saved as .m4a, an MP3 named .wav, a screen recording shared as .mp4. ffmpeg itself does not care about the extension and detects the format from the content, so my stricter check only rejected good files.

The fix: sniff the content, accept any known media container

export function isKnownMedia(head: Uint8Array): boolean {
  const ascii = (s: string, at = 0) => [...s].every((c, i) => head[at + i] === c.charCodeAt(0));
  if (head.length < 8) return false;
  // ISO base media (MP4, M4A, MOV, 3GP, HEIC): size + box type
  if (["ftyp", "moov", "mdat", "free", "skip", "wide"].some((t) => ascii(t, 4))) return true;
  if (ascii("ID3") || ascii("RIFF") || ascii("OggS") || ascii("fLaC")) return true;
  if (head[0] === 0x1a && head[1] === 0x45 && head[2] === 0xdf && head[3] === 0xa3) return true; // Matroska/WebM
  if (head[0] === 0xff && (head[1] & 0xe0) === 0xe0) return true; // MP3/ADTS frame sync
  return false;
}

Only binary signatures match. Plain text never does.

Why not just accept everything?

Because ffmpeg is more powerful than it looks. A text file can be an HLS playlist (#EXTM3U) or a concat script (ffconcat version 1.0) that points at other files or URLs. If you hand a user's text file to ffmpeg, it may read local files or fetch remote ones for them. Two cheap defences:

Reject text. The signature check above never matches a playlist, because it starts with printable characters.
Restrict protocols. Pass -protocol_whitelist file before -i, so even a crafted input cannot reach the network.

await run("ffmpeg", ["-y", "-hide_banner", "-loglevel", "error", "-protocol_whitelist", "file", "-i", input, "-vn", "-map", "0:a:0", out]);

Test with real files, not just unit tests

The unit tests were green and the bug still shipped, because I never fed it a real renamed file. I now generate a matrix of real files with ffmpeg (AAC, Opus, MP3 with an ID3 tag, FLAC, WAV, HEVC MOV, VP9 WebM, and each one with the "wrong" extension), upload them to the running service and check the output. It found two more gaps (a tool that rejected audio files in a video tool) within minutes.

Takeaways

Decide by content, not by name. Let the real decoder be the final judge.
Allow-list binary signatures; never let text reach tools that interpret text (ffmpeg, ImageMagick, LibreOffice).
Restrict what the tool may touch (-protocol_whitelist, no network, size caps, per-IP rate limits).
Keep original filenames only for display, and keep Unicode letters in them (I used /[^\p{L}\p{N}._\- ]+/gu), or users with Urdu or Arabic file names get underscores.

I use this in a free converter site with audio, video, PDF and image tools: saveanyreel.com. Bug reports with the file type that failed are very welcome.

Building a free video downloader and 50+ browser tools on Oracle's free tier

Usman Farooqi — Tue, 10 Nov 2026 18:37:32 +0000

I built SaveAnyReel, a free video downloader (Instagram, TikTok, YouTube, Facebook, Pinterest, Snapchat) with 50+ small tools next to it: PDF, image, audio and calculators. I wanted to run it at $0, so everything lives on Oracle's Always Free ARM VM. Here is how it is put together and what broke.

The stack

Next.js 16 (App Router) + React 19 + Tailwind v4 for the site and API routes.
Docker Compose on one Always Free ARM VM: Caddy (HTTPS), the Next.js app, a worker, Redis.
BullMQ + Redis for the job queues. The API validates a link and enqueues a job; the worker does the heavy lifting.
yt-dlp + ffmpeg in the worker. Videos are normalised to H.264 + AAC, because iPhones play VP9/AV1 MP4s as audio only.
LibreOffice, poppler, ghostscript, libheif in the worker for the document and HEIC converters.

Keep the server idle: do it in the browser

Most tools never touch the server:

PDF merge, split, rotate and JPG to PDF use pdf-lib.
Image resize, crop, compress and convert use the Canvas API.
QR codes use qrcode; OCR uses tesseract.js (language data is downloaded once, the image never leaves the device).

Only things that really need native tools (Word to PDF, HEIC, video to MP3) go through the queue, with size caps and a per-IP rate limit.

Things that bit me

1. YouTube blocks datacenter IPs. "Sign in to confirm you're not a bot" appeared for every client I tried. The fix that worked for me: a Cloudflare WARP SOCKS5 sidecar container, and only YouTube requests go through it.

2. Do not trust file extensions. My upload check only accepted a certain MP4 header for .m4a. A real user uploaded a WebM/Opus recording saved as .m4a and got "not a real file". I now sniff the content for known media signatures. Plain text (HLS playlists, concat scripts) is always rejected, and ffmpeg gets -protocol_whitelist file, so a crafted file cannot make it fetch URLs.

3. Cache what the API just learned. The app resolves a link, then the worker used to run yt-dlp's slow extraction again. Sharing the metadata through Redis for 10 minutes (plus fetching the video and audio streams in parallel) roughly halved job time: a short YouTube clip went from about 14 s to 6.5 s.

4. Hydration and randomness. A password generator that uses crypto.getRandomValues cannot render on the server. I used useSyncExternalStore with a false server snapshot, so the first client render matches the HTML and the password appears right after hydration.

5. SEO is half the product. Every tool has its own page with FAQ and HowTo schema, a canonical URL and a short guide. I submit URLs with IndexNow so Bing picks up changes quickly.

Honest limits

It only handles public content. Instagram sometimes revokes the logged-in session the extractor needs, so I treat it as flaky and surface clear errors instead of hiding them.

If you want to poke at it: saveanyreel.com. Feedback on any tool is welcome, especially bug reports with the file type that failed.

DEV Community: Usman Farooqi