I Spent 3 Months Researching Image-Based Attacks
zero-trust-web.vercel.app4 points by Raviteja_ 4 days ago
4 points by Raviteja_ 4 days ago
I Built a Security API Solo - Here's How I Turned 3 Months of Research Into a Product From security rabbit hole to live API: A solo dev's journey.
It started with a phone call at 2 AM. A friend's SaaS got hacked. The attack vector was embarrassingly simple: a user's profile picture. Somehow, a JPEG file managed to compromise their entire backend. After helping him triage the incident, I couldn't stop thinking about it. How did an image - something we all accept as harmless - become an attack vector? I went down a 3-month rabbit hole. And when I came out the other side, I had built something I think other developers actually need.
---
The Problem Nobody Talks About Every app that accepts user uploads has a hidden vulnerability. The industry "solution" is metadata stripping - running tools like ExifTool or ImageMagick to remove GPS coordinates, camera info, and timestamps. But here's what I learned: Threats don't live in metadata. They hide in: Polyglot files - A single file that's valid as both an image AND executable code Steganography - Hidden data encoded in pixel values (invisible to the human eye) Image bombs - A 50KB file that expands to 50GB when decoded (crashes your server)
None of these survive traditional "sanitization." I knew there had to be a better way.
---
Finding the Solution (That Enterprise Companies Charge $15k/Year For) After weeks of research, I stumbled onto a concept the military and enterprise use: Content Disarm and Reconstruction (CDR). The idea is simple but powerful: Don't try to detect threats. Instead, extract only the safe content (pixels) and rebuild the file from scratch. The output is a mathematically new image that can't possibly contain hidden threats - because it was just created from raw pixel data. The problem? Every CDR solution I found was either: Hidden behind "Contact Sales" forms Enterprise-priced ($10k-$50k/year) Built on risky dependencies (ImageMagick has a scary CVE history)
I saw an opportunity.
---
Building as a Solo Dev The Technical Bet: Rust + WebAssembly I needed to process hostile binary data without risking my server. JavaScript wouldn't cut it. Python was too slow. So I made a bet: Rust compiled to WebAssembly. Why? Memory safety - Rust prevents the buffer overflows that plague C/C++ image libraries WASM sandbox - Code runs in an isolated environment with strict memory limits Edge deployment - Cloudflare Workers run WASM at the edge, meaning sub-100ms latency globally
It was a steep learning curve (Rust is not for the faint of heart), but the result was exactly what I needed: a bulletproof image processor that could handle hostile inputs.
The Pricing Strategy I went with a generous free tier (100 requests/month) because: Trust is earned - Let developers test before paying Word of mouth - Free users become advocates Upgrade path is clear - When they hit limits, paid tiers are obvious
What I Learned 1. Niche Down Hard "Image sanitization" is a niche within a niche within a niche. That's the point. I'm not competing with general image APIs. I'm solving one specific problem for developers who actually understand the threat model. 2. Documentation Is Marketing My most effective "marketing" has been technical blog posts explaining the problem. Developers don't want to be sold to - they want to learn. Every article I write (like this one) is answering a question developers are already asking. 3. Build for the Long Term This isn't a growth hack or a quick flip. I'm building infrastructure that developers will depend on for years. That means: boring reliability > flashy features.
---
Try It The API is live: Zero Trust API on RapidAPI Send any image → get back a sterile PNG with zero metadata, zero hidden payloads. curl -X POST "https://zero-trust-api.p.rapidapi.com/sanitize" \ -H "X-RapidAPI-Key: YOUR_KEY" \ -H "Content-Type: image/jpeg" \ --data-binary "@image.jpg" \ --output clean.png
1. Worth proof-reading LLM copy. For instance:
- This says none of these attacks survive traditional sanitization.
You probably mean the opposite.
- You claim rebuilding from raw pixels, while calling steganography a threat.
Of course, steganography is in the raw pixel values you say you keep. And it's neither the same kind of threat (it is not a hostile input), nor does “CDR” do anything about it.
. . .
2. If you want this to take off, move a click up the value chain. Enterprises that care, don't want your API because they won't hire anyone who can do anything with it.
Instead, and you can have this for free:
a) Implement a plugin for Outlook that sanitizes email image embed, and extensions for browsers. It should run locally. Ship that for free.
b) At enterprise licensing pricing, implement a proxy server plugin that works with the top enterprise proxies to sanitize images while passing them through, caching them for subsequent requests, etc., all the things that make this a single drop in control for the entire proxied enterprise footprint.
c) Get a patent for $10k - $15k, costs more to be hard to workaround.
d) Write your contract so hostile image data belongs to you, license that attack data to the big infosec detection firms, likely also putting you in play for acquisition.
. . .
3. This site and this post doesn't read like Show HN. It reads like one cool trick SEO sales copy. The same day old account doesn't help.
Reconsider if authenticity matters.