DEV Community: Raviteja Nekkalapu

I built a open source free stock analysis tool with 55+ data dimensions

Raviteja Nekkalapu — Sat, 07 Mar 2026 18:49:13 +0000

The Problem

I invest in stocks on the side. My workflow looked like this:

Open Screener.in for fundamentals
Open TradingView for technicals
Ask Perplexity for a quick summary
Manually check insider trading on SEC EDGAR
Look up institutional holders somewhere else

Five tools.
None of them talked to each other.
And I was still missing actual valuation models, moat analysis, and any kind of fact-checking on the AI summaries.

Bloomberg does all of this in one place. It also costs $24,000 per year.

So I built one tool that does it for free.

What It Does

You enter a stock ticker. Eight seconds later, you get a report with:

Nipun Score - A proprietary A+ to F letter grade based on a weighted composite of technicals (25%), fundamentals (25%), sentiment (20%), risk (15%), and insider activity (15%)
Three valuation models - DCF, Benjamin Graham Number, Peter Lynch Fair Value
Scenario analysis - Bull, Base, and Bear price targets with probability estimates
Competitive moat - Wide, Narrow, or None with moat sources (brand, network effects, switching costs, etc.)
SWOT analysis - AI-generated strengths, weaknesses, opportunities, threats
Insider trading - Recent executive buys and sells with dollar amounts
Institutional ownership - Top 10 holders with position changes
...and about 20 more sections

The Architecture

The backend is a serverless worker that runs a 4-phase pipeline:

Phase 1 - Data Collection (~2-3s)
10+ parallel API calls to Finnhub (financials, peers, insider trades, earnings), SEC EDGAR (10-K, 10-Q filings), Reddit RSS (sentiment), and Yahoo RSS (news).

Phase 2 - Compute (~5ms)
Zero API calls.
Pure math.
This phase calculates Altman Z-Score, Piotroski F-Score, DCF valuation, Graham Number, momentum scoring, risk-reward ratios, and dividend safety. All deterministic.

Phase 3 - AI Synthesis (~3-5s)
Two parallel calls to Google Gemini.
One generates the main analysis.
The other generates premium insights (scenario analysis, moat, SWOT, investment thesis). I built a 5-model cascade: 2.5 Pro → 2.0 Flash → 1.5 Pro → Flash → Lite. If one model rate-limits, it falls through to the next automatically.

Phase 4 - Second Opinions (~1-2s)
Cerebras generates a contrarian take.
Cohere runs a fact audit, classifying every AI-generated claim as grounded, speculative, or unverifiable. Both are non-fatal — if they fail, the report still ships.

Security

This was important to me. The tool uses a BYOK (Bring Your Own Keys) model:

API keys encrypted client-side with AES-256-GCM
Key derivation: PBKDF2 with SHA-256, 100K iterations
16-byte random salt, 12-byte random IV
Keys sent via X-Nipun-Keys header, never in request body
Worker processes keys in memory, never persists them
Everything uses the Web Crypto API — zero npm dependencies for crypto

The Interesting Technical Decisions

1. Mock data fallback on every API call

Every single external call is wrapped in try/catch with a fallback to mock data. This means:

The app literally cannot crash from a bad API response
Demo mode works using the same fallback path
You can run the full UI without any API keys

2. Cascading AI models

Instead of relying on one model, I chain five. Rate limits, outages, and model-specific failures are handled transparently. The user never sees an error.

3. Contrarian AI

Most AI tools agree with themselves. I deliberately ask a second model to disagree with the first. This gives you both sides of the argument instead of just confirmation bias.

How to Try It

npx nipun-ai

Or check the live demo at nipun-ai.pages.dev (uses mock data, no keys needed).

GitHub: github.com/myProjectsRavi/Nipun-AI

MIT licensed.
All APIs have free tiers.
Feedback welcome.

I built an AI security Firewall and made it open source because production apps were leaking SSNs to OpenAI

Raviteja Nekkalapu — Thu, 26 Feb 2026 19:33:31 +0000

About a year ago I started keeping a list.
Every production AI integration I saw that shipped with zero input validation, zero output scanning, zero audit trail.
The list got long fast.

The pattern was always the same - OpenAI SDK, one API call per user message,
return the result.
Clean, fast to build, completely unprotected.

So I spent almost an year building Sentinel Protocol and today I'm open-sourcing it.

What it is

A local security proxy for LLM API calls. It sits between your application and
any LLM provider - OpenAI, Anthropic, Google Gemini, Ollama, DeepSeek, Groq, etc and runs 81 security engines on every request.

Zero cloud calls for security decisions. Everything runs on your machine. The
audit trail is a plain JSONL file that stays local.

Getting started

npx --yes --package sentinel-protocol sentinel bootstrap --profile paranoid --mode enforce --dashboard

Proxy starts at http://127.0.0.1:8787. Dashboard at http://127.0.0.1:8788.

Change one line in your SDK:

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: 'http://127.0.0.1:8787/v1',
  defaultHeaders: { 'x-sentinel-target': 'openai' }
});

Everything else stays identical. Your app code doesn't change.

The PII problem

The PII engine handles 40+ pattern types with severity-tiered actions:

Severity	Examples	Action
Critical	SSN, Credit Card, Passport	Block (403) — never reaches model
High	API Keys, AWS credentials, tax ID	Block (403)
Medium	Email, phone, physical address	Silently redact → placeholder
Low	IP addresses	Log and pass

When you block an SSN:

json
{
  "error": "PII_DETECTED",
  "reason": "pii_detected",
  "pii_types": ["ssn_us"],
  "correlation_id": "52360b2d-4b92-4b30-9ace-32fae427c323"
}

The PII never left your machine. The audit log has the timestamp, type, correlation ID, and duration. Your users' data stayed local.

The two-way PII vault goes further. It tokenizes PII before the request leaves (the model sees a reference token, not the real value), then detokenizes the token in the model's response. End-to-end - the actual value is never transmitted.

Injection detection

Three layers, running simultaneously per request:

LFRL classifier: Custom rule language (RULE...WHEN...THEN) plus a learned scoring function. Calibrated confidence 0.0–1.0. Configurable block threshold (default: 0.85). Every rule is inspectable - no black box.

Prompt rebuff: Canary token detection + perplexity scoring. Catches adversarial text that's lexically valid but statistically anomalous.

Semantic scanner: ONNX local embeddings (all-MiniLM-L6-v2) computing cosine similarity against a threat signature corpus. Catches semantically similar injections that don't match known lexical patterns.

The injection-merge layer combines all three signals with configurable weights into a single decision.

Agentic and MCP security

For teams building with tool-using agents and MCP:

MCP poisoning: A malicious MCP server can return a crafted tool result and redirect the agent's next action. Sentinel's MCP poisoning detector analyzes tool call results for hijacking signals before they influence the agent.

Shadow MCP: Detects unauthorized MCP servers impersonating legitimate ones.

MCP certificate pinning: TLS cert validation against expected fingerprints for known MCP servers.

Swarm protocol: HMAC-authenticated inter-agent messaging. Agents can't impersonate each other in multi-agent setups.

Loop breaker: Detects and terminates infinite agent recursion before the budget burns.

Intent drift: Tracks whether an agent's behavior over a session is diverging from its constitutional goal.

Egress scanning: Most security tooling stops at the input. Sentinel scans what comes back out:

Hallucination tripwire: Catches fabricated URLs, nonexistent package imports, numeric contradictions within the same response, and improbable citation patterns. Deterministic. Works directly on output text without needing the input context.

Stego exfil detector: Zero-width characters and invisible Unicode code points are a real exfiltration vector. Tools can embed hidden data in what appears to be clean natural language text. Sentinel scans for it.

Streaming (SSE) redaction: In real time, as SSE chunks arrive. Not after the stream ends but during. The transform buffers partial sentences, scans, and either forwards or redacts before the chunk reaches your client.

Output classifier: Four categories - toxicity, code execution, hallucination signals, unauthorized disclosure. Each with configurable warn/block thresholds and context-window dampening to keep the FP rate reasonable.

Compliance and governance: Every blocked event gets OWASP LLM Top 10 category mapping and MITRE ATLAS technique attribution automatically. The compliance engine generates SOC2, GDPR, HIPAA, and EU AI Act Article 12 evidence reports on demand.

The forensic debugger lets you replay any blocked request against a changed config. That's useful when you're tuning thresholds: make a change, replay the historical block, see whether the updated config would have still caught it.

Formal verification: TLA+ spec for the security decision pipeline, Alloy spec for policy consistency. These are in the repo. You can run them.

The numbers

52,069 lines of source code
81 security engines
139 test suites, 567 tests, 0 failures
306 linted files, 0 warnings
9 total runtime dependencies
<5ms proxy overhead at p95
0 npm audit vulnerabilities
OWASP LLM Top 10: 10/10 categories covered

What I got wrong
Egress is harder than ingress. Scanning natural language output has an inherently higher FP rate than scanning structured input patterns. I had to build context windowing and n-gram scoring specifically to make the output classifier useful at the default thresholds.*

Streaming was harder than I expected. Getting real-time SSE redaction right required three rewrites. The partial sentence buffering across chunks is subtle.

MCP should have been there from day one. I added most of the agentic security late. Tool-using agents and MCP integrations are the fastest-growing attack surface.

No install — try it now

npx --yes --package sentinel-protocol sentinel bootstrap --profile paranoid --mode enforce --dashboard

Global install

npm install -g sentinel-protocol
sentinel bootstrap --profile paranoid --mode enforce --dashboard

Embed in your app

npm install sentinel-protocol

GitHub: https://github.com/myProjectsRavi/sentinel-protocol

MIT.
No telemetry.
No accounts.

Built by a developer who got tired of the answer being "trust the model."

The Incognito Mode Lie

Raviteja Nekkalapu — Thu, 05 Feb 2026 16:10:47 +0000

You just did something dangerous.

You opened ChatGPT.
You pasted your medical lab report to understand the results.

And you felt productive.
Efficient.
Smart.

But here's what you didn't know:

That text is never going to die.

The "Incognito" Delusion
Most people think privacy is a browser setting.
Open a private window.
Clear your cookies.
You're invisible.

Laughable.

Incognito mode hides your history from your browser.
Not from the websites you visit.
Not from your ISP.
And certainly not from the AI models you're feeding your life story to.

When you paste that PDF into Claude or ChatGPT, you're not using a calculator. You're not using a tool. You're feeding a living, learning, remembering system.

AI doesn't just answer you. AI learns from you.

The "Forever Memory" Problem
Every major AI company has stated, on record, that they use conversations to improve their models.

OpenAI's terms explicitly state that free tier ChatGPT conversations can be used for training.
Google's Gemini? Same story.
Claude by Anthropic? They claim to be more private, but their terms still allow for "safety research."

What does "training" actually mean?

It means your rent agreement with your name, your landlord's name, your address, your monthly rent becomes a statistical weight in GPT-5. Your medical report with your cholesterol levels, your blood pressure, your doctor's diagnosis becomes a pattern that helps the model understand "human health."

You are not a user. You are the curriculum.

The Telecom Cold War
Here's something most people haven't connected yet.

In 2025, three massive telecom partnerships were announced in India:

Jio + Google Gemini: Free Gemini Pro for 18 months to all Jio 5G users (worth ₹35,100)
Airtel + Perplexity AI: Free Perplexity Pro for 12 months to 360+ million Airtel subscribers
OpenAI + India: Free ChatGPT Go for all Indian users for one year

Why would these trillion-dollar companies give away their best products for free?

Because you are not the customer. You are the product.

Oracle's co-founder Larry Ellison said it plainly:

"For these models to reach their peak value, you need to train them not just on publicly available data, but make privately owned data available for those models as well."

Read that again. Slowly.

Privately owned data.

That's your resume.
Your tax documents.
Your relationship advice queries.
Your medical questions.
Your children's school applications.

Every telecom partnership is an investment. The free access is the bait. Your data is the return.

The "Quick Hack" Trap
Most people try to protect themselves manually.

"I'll just delete my name before pasting."

But you forgot your address.
You forgot the transaction ID.
You forgot the unique case number that links back to your identity. You forgot the metadata embedded in the file itself.

Manual redaction is a game of whack-a-mole against a hydra. For every piece you catch, three more slip through.

And even if you catch everything visible, there's the invisible: patterns. Writing style. Vocabulary. Typing speed (yes, some models track this). All of it creates a fingerprint.

The Math Solution
You can't trust privacy policies. They change. Companies get acquired. Servers get hacked. Employees go rogue.

But you CAN trust math.

If you send a document with no names in it, it cannot leak names. If you send an SSN that is mathematically valid but not yours, it cannot be traced to you.

This is the principle behind Risk Mirror.

We don't ask you to trust OpenAI. We don't ask you to trust Google. We ask you to trust entropy.

Redaction Mode: We strip every identifiable element before it leaves your browser. Names become [NAME]. Dates become [DATE]. The document becomes a skeleton that the AI can analyze without learning who you are.

Twin Mode: For when you need the AI to truly understand the document, we don't delete, we replace. Your name becomes "Sarah Chen." Your medical condition becomes a different (but structurally similar) ailment. The AI analyzes the form perfectly, but the facts are fiction.

You have a choice.

You can keep pasting your life into AI chatbots, hoping they play nice.

Or you can sanitize first. Two clicks. Two seconds. And suddenly, you're a ghost.

The AI still helps you. The AI still answers your questions. But the AI never learns who asked them.

Be productive. Be safe. Be invisible.

The Text Suite is $0 right now.

No card required.
No logs kept.

Grab it before I have to close the free tier - Risk Mirror

Why 'Localhost' is a Myth: Your Clipboard is a Public API

Raviteja Nekkalapu — Wed, 04 Feb 2026 17:20:57 +0000

The Invisible Leak
We treat Localhost like a fortress. "It's just on my machine. It's safe."

But how did the data get there? You copied it.

The Clipboard Reality:

Browser Extensions: That "Coupon Finder" extension has permission to read your clipboard. It just read your AWS key.
OS History: Windows and Mac now keep "Clipboard History" (Win+V). That password you copied 5 hours ago is still there, in plaintext, readable by any process running as User.
AI Tools: You use a "ChatGPT Desktop App" or a "Writing Assistant." It monitors your clipboard to "help" you.

The "Sanitize First" Habit (The New Hygiene)
In security, we wash our hands. You need to wash your clipboard.

The Protocol: Before you copy anything sensitive (API keys, DB strings, customer emails) into a shared environment or an AI tool, Sanitize it.

Risk Mirror isn't just an API. We have a simple web interface.

Paste the dirty text.
Click "Sanitize".
Copy the clean text.

It adds 2 seconds to your workflow. It removes 100% of the attack surface from your clipboard history.

Stop treating your clipboard like a vault. It's a billboard.

Bookmark the Sanitizer - Risk Mirror

The Developer's Guide to 'Safe Share'

Raviteja Nekkalapu — Wed, 04 Feb 2026 17:15:34 +0000

The "Share" Paralysis
You have a critical bug in Prod. The server is on fire. You need help. You want to paste the error.log into Slack, or GitHub Issues, or send it to a consultant.

But you pause.
Does this log have a user's IP?
Does it have a Session Token?
Does it have an AWS key in the environment dump?

So you spend 15 minutes manually ** Ctrl+F**ing for sensitive strings. And you miss one. And 5 minutes later, your AWS bill hits $10,000 because a bot scraped your key from that GitHub gist.

The "Ctrl+Z" for Privacy
We built the Document Scanner capability in Risk Mirror to end this paralysis. It's an O(n) regex engine that lives in the browser (or API).

The "Safe Share" Protocol:

Local Scan: Drag your .log file into Risk Mirror.
Pattern Match: We identify 150+ secrets (AWS keys, Slack tokens, emails, IPs, MAC addresses).
Redact or Replace:

Choose Redact ([REDACTED]) to show where the data was.
Choose Twin to replace the IP 192.168.1.5 with 10.0.0.9. The network topology looks the same, but the target is gone.

Download & Send: You now have a clean file.

It takes < 1 second.

It saves your career.

Don't trust your eyes.

Trust the pattern matcher.

Try for free - Risk Mirror

Redact PII Before Sending Data to LLMs: A Developer's Guide

Raviteja Nekkalapu — Mon, 29 Dec 2025 06:02:45 +0000

Why every AI integration needs PII redaction and how to implement it in 60 seconds

The AI Privacy Problem Nobody Talks About

You're building a ChatGPT wrapper or any other AI wrapper. Users submit questions.

Those questions contain:

Emails
Phone numbers
Social security numbers (yes, really)
Credit card numbers (users paste them)
Home addresses

All of it goes directly to OpenAI's servers.

Question: Does your privacy policy say "We share user data with third parties"?

Probably not. But you just did.

The Lawsuit Waiting to Happen

GDPR fines in 2024: €2.1 billion

Average data breach lawsuit settlement: $3.8 million

SEC now requires disclosure of AI related data handling.

It's not paranoia. It's risk management.

The Simple Fix

Redact PII before sending to the LLM.

User Input: "My SSN is 123-45-6789 and email is john@company.com"
     ↓
PII Firewall Edge
     ↓
Clean Input: "My SSN is [SSN] and email is [EMAIL]"
     ↓
Send to ChatGPT

ChatGPT never sees the actual PII. Your liability drops to near zero.

Implementation (60 seconds)

Step 1: Get API Key

Step 2: Call Before LLM

async function sanitizeForLLM(userInput) {
  const response = await fetch(
    'https://pii-firewall-edge.p.rapidapi.com/v1/redact/fast',
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'X-RapidAPI-Key': process.env.RAPIDAPI_KEY
      },
      body: JSON.stringify({ text: userInput })
    }
  );

  const { redacted } = await response.json();
  return redacted;
}

// Usage
const cleanInput = await sanitizeForLLM(userMessage);
const aiResponse = await openai.chat.completions.create({
  messages: [{ role: 'user', content: cleanInput }]
});

Step 3: There is no Step 3

Seriously. That's it.

What Gets Detected

Category	Types	Examples
Contact Info	Email, Phone	john@test.com, 555-1234
Government IDs	SSN, Passport	123-45-6789, AB1234567
Financial	Credit Card, IBAN	4111-1111-1111-1111
Healthcare	NPI, Medicare	1234567890
Developer	API Keys	sk_live_xxx, ghp_xxx

Total: 152 PII types across 50+ countries.

Why Not Build It Yourself?

I tried. Here's what happened:

Week 1: Basic regex for SSN and email. "This is easy!"

Week 2: User submits Indian Aadhaar number. Regex fails. We used dictionary lookups and proximity patterns, not just regex

Week 3: Added 15 more patterns. Performance tanked.

Week 4: Discovered Luhn checksum. Realized I was matching fake credit cards.

Month 2: Still finding edge cases (international phone formats, API keys, crypto addresses...)

Month 8: Finally production-ready. 2,000+ lines of code. 30+ checksum validators.

You can spend 8+ months on this and then few more months in implementing enterprise grade security and then optimizing algorithms for performance

Or use PII Firewall Edge API and ship today.

Performance

Endpoint	Latency	Use Case
`/fast`	2-5ms	Logs, real-time
`/deep`	5-15ms	Context-heavy data (Addresses, Names)

The Zero-AI Advantage

"Privacy" APIs that use ML models to detect PII:

Your Data → Their AI Server → Model Training → ???

PII Firewall Edge:

Your Data → Cloudflare Edge → Regex + Checksums → Deleted

No AI. No logs. No training. No liability.
We run on stateless Cloudflare Workers. No database is connected to the processing pipeline. The code is ephemeral.

Pricing Reality

Provider	Monthly Cost
AWS Comprehend	$250+
Google DLP	$200+
Private AI	$500+
PII Firewall Edge	$5

Same security. 97% less cost.

Get Started

Free: 500 requests/month
Pro: $5/month (5,000 requests/month)

curl -X POST "https://pii-firewall-edge.p.rapidapi.com/v1/redact/fast" \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -d '{"text": "test@example.com 123-45-6789"}'

Try it for free - PII Firewall Edge
SDK Docs - PII Firewall Edge - SDKs

Building AI features? Don't leak user data. Start protecting your users today.

[Boost]

Raviteja Nekkalapu — Sun, 21 Dec 2025 09:59:04 +0000

I Discovered Why "Stripping Metadata" From Images is Security Theater 🎭 - DEV Community

TL;DR: I spent 3 months researching image-based attacks after a security incident. What I found was...

dev.to

I Discovered Why "Stripping Metadata" From Images is Security Theater 🎭

Raviteja Nekkalapu — Sat, 20 Dec 2025 15:09:17 +0000

TL;DR: I spent 3 months researching image-based attacks after a security incident. What I found was alarming: standard "metadata stripping" does almost nothing against modern threats. The only mathematical guarantee of safety is completely destroying and rebuilding the image from scratch.

The Incident That Started Everything

Last year, a friend's startup got hacked. The attack vector? A user's profile picture.

Not a PDF. Not an executable. A simple JPEG uploaded through their avatar picker.

The file passed every standard check:

✅ File extension: .jpg
✅ MIME type: image/jpeg
✅ Magic bytes: Valid (FF D8 FF...)
✅ Antivirus: Clean
✅ Metadata stripped with ExifTool

They were still compromised.

I spent the next three months going down the rabbit hole of polyglots and steganography. What I found changed how I handle user uploads forever.

🚨 The 3 Image Attacks That Bypass "Sanitization"

1. Polyglot Files — The Shape-Shifters

A polyglot is a file that is valid in multiple formats simultaneously.

One common attack is a Phar-JPEG Polyglot:

[Valid JPEG Header] + [Valid PHP Payload] + [Valid JPEG Footer]

To your image upload filter? It looks like a perfectly valid image. To a backend process triggering a filesystem function (like a phar:// wrapper exploit or LFI vulnerability)? It executes as code.

The Reality: Standard sanitizers usually just check headers or strip EXIF tags. They often leave the file structure intact, meaning the malicious payload survives the "cleaning" process.

2. Steganography — Invisible Data Smuggling

We often think of steganography as spy-movie stuff, but it's becoming a standard tool for APTs (Advanced Persistent Threats).

Attackers hide encrypted command-and-control (C2) payloads inside the Least Significant Bits (LSB) or specific DCT coefficients of the image.

# Simplified Concept:
# Original pixel:  RGB(100, 150, 200)
# Malicious pixel: RGB(101, 150, 201)  ← Human eye sees no difference

The Danger: Your server acts as a "dead drop." The malware isn't running on your server, but your server is hosting the encrypted payload for other infected machines to download. Antivirus scanners rarely catch this because it looks like random visual noise (entropy).

3. Image Bombs — The Memory Killer

Also called "decompression bombs." A 50KB PNG file can be crafted to expand into 50GB of raw pixel data when decoded.

If your backend blindly decodes this to process a thumbnail:

1. Upload 50KB file (bypasses size limit)
2. Decoder attempts to allocate 50GB RAM
3. OOM Killer crashes your service

Stripping metadata often triggers this because the stripper has to parse the file first.

💡 The "Aha" Moment: Trust Nothing. Rebuild Everything.

After researching this, I realized the industry standard ("Sanitization") is fundamentally flawed.

Traditional security asks: "Is this file safe?"

This is the wrong question.

The right question is:

"How can we guarantee this file is sterile?"

The answer is Content Disarm and Reconstruction (CDR).

Instead of looking for "bad" things to remove, you extract the one thing you know is "good"—the pixels—and throw everything else away.

The Logic:

Decode the image to a raw buffer (RGBA).
Destroy the original container (headers, metadata, hidden scripts, polyglot payloads).
Re-encode the pixels into a brand new, sterile PNG container.

If the original file had a PHP script hidden in the footer? Gone.

If it had GPS data? Gone.

If it was a malformed buffer overflow attack? Neutralized during decode.

🛡️ Building a Public Solution

I wanted to implement this "Reconstruction" pattern for my own projects, but I hit a wall.

Existing enterprise CDR tools were gated behind "Contact Sales" forms and $15k/year contracts. Open-source tools like ImageMagick have a scary history of CVEs (like ImageTragick), making them risky to run on your own backend.

So, I decided to engineer a dedicated microservice for it.

I built Zero Trust API using Rust and WebAssembly.

Why Rust/WASM?

I needed memory safety. Handling untrusted binary data in C/C++ is a recipe for disaster. By running the decoding logic in a sandboxed WASM environment with strict memory limits, we can process hostile images without risking the host server.

The Architecture:

Input:   Any image (JPG, PNG, WEBP, GIF)
           │
           ▼
Process: Decodes to raw pixels → Destroys container → Rebuilds as sterile PNG
           │
           ▼
Output:  A mathematically generated new file

For the Community

I built this primarily to solve my own headache, but I've opened it up as a public API.

I hate "Contact Sales" buttons, so I made a free tier that's generous enough for most indie projects and dev testing.

If you are handling user-uploaded avatars, KYC docs, or product photos, I highly recommend looking into CDR (whether you use my tool or build your own implementation).

Stop "cleaning" files. Start rebuilding them.

Links for the curious:

📖 API Docs & Demo: Zero Trust App
� RapidAPI (Get a key): Zero Trust API

📚 Related Articles in This Series

Hands-On: See Image Metadata Removal in Action

Raviteja Nekkalapu — Sat, 20 Dec 2025 15:03:56 +0000

A practical verification guide using free tools to compare before and after

Introduction

You've heard about metadata risks and image rebuilding. But how do you prove it actually works?

This guide teaches you to:

Inspect image metadata using free tools
See exactly what data your photos contain
Verify that processing actually removes everything

No coding required. Just free online tools and 10 minutes.

Part 1: Understanding What's Hidden in Your Images

1.1 The Invisible Data

Every photo you take contains hidden metadata:

┌─────────────────────────────────────────────────────────────┐
│                   What's Inside Your JPEG                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  📍 GPS COORDINATES                                         │
│  ├── Latitude: 37.7749° N                                   │
│  ├── Longitude: 122.4194° W                                 │
│  └── Altitude: 16 meters                                    │
│                                                             │
│  📱 DEVICE INFORMATION                                      │
│  ├── Make: Apple                                            │
│  ├── Model: iPhone 14 Pro                                   │
│  ├── Software: iOS 17.1                                     │
│  └── Serial Number: DNXXXXXXXX                              │
│                                                             │
│  📅 TIMESTAMPS                                              │
│  ├── Date Taken: 2024-03-15 14:32:07                        │
│  ├── Date Modified: 2024-03-15 14:32:07                     │
│  └── Time Zone: PST (UTC-8)                                 │
│                                                             │
│  📷 CAMERA SETTINGS                                         │
│  ├── Aperture: f/1.8                                        │
│  ├── Shutter Speed: 1/125                                   │
│  ├── ISO: 100                                               │
│  ├── Focal Length: 24mm                                     │
│  └── Flash: Off                                             │
│                                                             │
│  🖼️ EMBEDDED THUMBNAIL (Full separate image!)               │
│                                                             │
│  💬 COMMENTS (Can contain ANYTHING)                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

All of this is invisible when you view the photo normally. But anyone with basic tools can extract it.

Part 2: Free Online Tools to Inspect Metadata

Option 1: Jeffrey's EXIF Viewer (Recommended)

Website: exif.regex.info/exif.cgi

How to use:

Go to the website
Upload your image OR paste an image URL
Click "View Image Data"
See complete metadata analysis

What you see:

┌─────────────────────────────────────────────────────────────┐
│  Jeffrey's Exif Viewer - Results                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  EXIF                                                       │
│  ├── Camera: iPhone 14 Pro (Apple)                          │
│  ├── Date: 2024:03:15 14:32:07                              │
│  ├── Resolution: 4032 × 3024                                │
│  └── ... 47 more fields                                     │
│                                                             │
│  GPS                                                        │
│  ├── Latitude: 37° 46' 29.64" N                             │
│  ├── Longitude: 122° 25' 9.84" W                            │
│  └── 📍 [Map Link]                                          │
│                                                             │
│  IPTC                                                       │
│  └── (empty)                                                │
│                                                             │
│  XMP                                                        │
│  ├── Creator Tool: Photos 8.0                               │
│  └── ... 12 more fields                                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Option 2: ExifMeta.com

Website: exifmeta.com

Features:

Drag-and-drop upload
Clean visual interface
Shows GPS on a map
Highlights privacy-sensitive fields

Option 3: Online EXIF Viewer (Jimpl)

Website: jimpl.com/exif

Features:

Very simple interface
Shows embedded thumbnails
Highlights common metadata fields

Option 4: Browser DevTools (for URLs)

If you have an image URL, many browsers can show basic metadata:

Right-click image → "Open image in new tab"
Right-click → "Inspect"
Look at the Network tab for headers

(This only works for basic data, not EXIF)

Part 3: Step-by-Step Verification

Let's verify that image rebuilding actually removes metadata.

Step 1: Find a Test Image

Use a photo from your phone or camera. Phone photos are ideal because they contain:

GPS coordinates
Device information
Timestamps
Camera settings

Where to get test images:

Your phone's photo library
Photos you've taken recently
Any JPEG from a digital camera

⚠️ Don't use screenshots - they typically have minimal metadata.

Step 2: Check BEFORE Metadata

Using Jeffrey's EXIF Viewer:

Go to exif.regex.info/exif.cgi
Click "Choose file"
Upload your original photo
Click "View Image Data"

What to look for:

Field	Privacy Risk	Example Value
GPS Latitude/Longitude	🔴 HIGH	37.7749, -122.4194
DateTimeOriginal	🟡 MEDIUM	2024:03:15 14:32:07
Make/Model	🟡 MEDIUM	iPhone 14 Pro
Software	🟢 LOW	iOS 17.1
SerialNumber	🔴 HIGH	DX3XXXXXXXX
Thumbnail	🔴 HIGH	(embedded image)

Save the results! Take a screenshot or copy the data. You'll compare it later.

Step 3: Process Through the API

Use the RapidAPI playground (see our testing guide) or run this command:

curl -X POST 'https://zero-trust-api.p.rapidapi.com/' \
  -H 'x-rapidapi-key: YOUR_KEY' \
  -H 'x-rapidapi-host: zero-trust-api.p.rapidapi.com' \
  -H 'Content-Type: image/jpeg' \
  --data-binary @your_original_photo.jpg \
  --output rebuilt_photo.png

Save the output file: rebuilt_photo.png

Step 4: Check AFTER Metadata

Now analyze the rebuilt image:

Go to exif.regex.info/exif.cgi
Upload rebuilt_photo.png
Click "View Image Data"

Expected results:

┌─────────────────────────────────────────────────────────────┐
│  Jeffrey's Exif Viewer - Results                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Basic Image Info                                           │
│  ├── File Type: PNG                                         │
│  ├── Resolution: 4032 × 3024                                │
│  ├── Color Depth: 8-bit                                     │
│  └── Color Type: RGB                                        │
│                                                             │
│  PNG Chunks                                                 │
│  ├── IHDR (Image Header)                                    │
│  ├── IDAT (Image Data)                                      │
│  └── IEND (Image End)                                       │
│                                                             │
│  ❌ NO EXIF DATA                                            │
│  ❌ NO GPS DATA                                             │
│  ❌ NO XMP DATA                                             │
│  ❌ NO IPTC DATA                                            │
│  ❌ NO THUMBNAIL                                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Part 4: The Comparison

Side-by-Side Results

Metadata Field	Original Photo	After CDR
GPS Latitude	37.7749° N	❌ REMOVED
GPS Longitude	122.4194° W	❌ REMOVED
Camera Make	Apple	❌ REMOVED
Camera Model	iPhone 14 Pro	❌ REMOVED
Serial Number	DX3XXXXXXXX	❌ REMOVED
Date Taken	2024-03-15 14:32:07	❌ REMOVED
Time Zone	PST (UTC-8)	❌ REMOVED
Software	iOS 17.1	❌ REMOVED
Aperture	f/1.8	❌ REMOVED
ISO	100	❌ REMOVED
Embedded Thumbnail	Yes (228 KB)	❌ REMOVED
XMP Data	12 fields	❌ REMOVED

Visual Comparison

BEFORE (Original JPEG)              AFTER (Rebuilt PNG)
┌─────────────────────────┐        ┌─────────────────────────┐
│ File: photo_original.jpg│        │ File: rebuilt.png       │
│ Size: 2.4 MB            │        │ Size: 1.8 MB            │
│                         │        │                         │
│ EXIF: 47 fields         │   →    │ EXIF: 0 fields          │
│ GPS: 37.77, -122.41     │   →    │ GPS: (none)             │
│ Device: iPhone 14 Pro   │   →    │ Device: (none)          │
│ Thumbnail: YES          │   →    │ Thumbnail: NO           │
│                         │        │                         │
│ Visual: [Same image]    │   =    │ Visual: [Same image]    │
└─────────────────────────┘        └─────────────────────────┘

       47 metadata fields                 0 metadata fields

Part 5: Why This Matters

5.1 Real Privacy Risks

GPS Coordinates Reveal:

Your home address (photos taken at home)
Your workplace
Your daily routines
Your travel patterns
Your children's school locations

Timestamps Reveal:

When you're away from home
Your sleep schedule
When you take vacations
Alibis (or lack thereof)

Device Info Reveals:

Your phone model (for targeted exploits)
Your software version (for vulnerability matching)
Your device serial number (for tracking)

5.2 Metadata in the News

Incident	Year	Impact
John McAfee Located	2012	Fugitive found via photo metadata
Vice Journalists	2012	Reporters endangered by photo GPS
Higgins Arrest	2016	Suspect tracked by EXIF data
TikTok Controversy	2020	App collected extensive photo metadata

Part 6: Testing Edge Cases

Test 1: Phone Photo with Location

Take a photo with your phone (ensure location services are on)
Check metadata → should show GPS, device, timestamps
Process through CDR
Verify → all location data should be gone

Test 2: Downloaded Internet Image

Download any image from a website
Check metadata → often contains software info, copyright, dates
Process through CDR
Verify → all web metadata should be gone

Test 3: Screenshot

Take a screenshot on any device
Check metadata → usually minimal, but may include device info
Process through CDR
Verify → what little metadata existed is now gone

Test 4: Edited Photo

Take a photo, edit it (crop, filter, etc.)
Check metadata → may contain edit history, software used
Process through CDR
Verify → edit traces are gone

Part 7: Command Line Tools (Optional)

For power users who prefer command-line tools:

ExifTool (Cross-Platform)

Install:

# macOS
brew install exiftool

# Ubuntu/Debian
sudo apt-get install libimage-exiftool-perl

# Windows
# Download from exiftool.org

View all metadata:

exiftool photo.jpg

Compare before and after:

# Before
exiftool original.jpg > before.txt

# After processing
exiftool rebuilt.png > after.txt

# Compare
diff before.txt after.txt

Sample Output

Before (original.jpg):

ExifTool Version Number         : 12.76
File Name                       : original.jpg
File Size                       : 2.4 MB
MIME Type                       : image/jpeg
GPS Latitude                    : 37 deg 46' 29.64" N
GPS Longitude                   : 122 deg 25' 9.84" W
Camera Model Name               : iPhone 14 Pro
Date/Time Original              : 2024:03:15 14:32:07
Software                        : 17.1
... (47 more fields)

After (rebuilt.png):

ExifTool Version Number         : 12.76  
File Name                       : rebuilt.png
File Size                       : 1.8 MB
MIME Type                       : image/png
Image Width                     : 4032
Image Height                    : 3024
Bit Depth                       : 8
Color Type                      : RGB

Difference: 47+ fields reduced to 5 basic fields (format, dimensions only).

Part 8: What Should Remain vs. What's Removed

Should Be Removed (Privacy/Security):

Category	Fields	Status After CDR
Location	GPS coordinates, altitude, direction	❌ Removed
Device	Make, model, serial number	❌ Removed
Software	iOS version, app used, edits	❌ Removed
Timestamps	Creation date, modification date	❌ Removed
User Info	Copyright, author, comments	❌ Removed
Thumbnails	Embedded preview images	❌ Removed
XMP	Adobe metadata, edit history	❌ Removed
IPTC	News/agency metadata	❌ Removed

What Remains (Essential):

Category	Fields	Status After CDR
Visual Content	The actual pixels	✅ Preserved
Dimensions	Width and height	✅ Preserved
Color Space	RGB/RGBA	✅ Preserved

Conclusion

Using free online tools like Jeffrey's EXIF Viewer, you can:

See exactly what metadata your images contain
Verify that processing actually removes it
Understand the privacy implications

The key insight: true image rebuilding leaves only pixels. No metadata, no hidden data, no traces of the original file structure.

Try it yourself with your own photos. The results will speak for themselves.

Quick Reference

Free Metadata Viewers:

Jeffrey's EXIF Viewer: exif.regex.info/exif.cgi
ExifMeta: exifmeta.com
Jimpl EXIF: jimpl.com/exif

What to look for:

GPS coordinates (biggest privacy risk)
Device information
Timestamps
Embedded thumbnails
Custom comment fields

After proper CDR:

All metadata fields should be empty
File should be PNG format
Only basic image info (dimensions, color type) remains

📚 Want to Try It Yourself?

If you'd like to test image rebuilding without writing any code, I've put together a step-by-step playground guide:

How to Test Image Rebuilding APIs: A Step-by-Step Guide

It walks you through using the RapidAPI playground to:

Upload test images
See the processing in action
Download rebuilt files for verification

No coding required—just a browser and 5 minutes.

📚 Related Articles in This Series

How to Test Image Rebuilding API: A Step-by-Step Guide

Raviteja Nekkalapu — Sat, 20 Dec 2025 15:02:06 +0000

A beginner-friendly walkthrough for testing image security APIs on RapidAPI

Introduction

You've learned about image security threats like polyglot files, steganography, and metadata leaks. Now you want to test an image rebuilding solution to see if it actually works.

This guide walks you through testing any image CDR (Content Disarm & Reconstruction) API on RapidAPI's playground—no coding required.

What You'll Need

A web browser
An image file to test (any JPEG, PNG, GIF, or WebP)
5 minutes

That's it. No installation. No setup.

Step 1: Navigate to the API

Visit the Zero Trust API on RapidAPI.

You should see the API overview page with:

Description
Pricing tiers
Endpoints

Step 2: Subscribe to the Free Tier

Before you can test, you need an API key. RapidAPI handles this automatically.

2.1 Click "Subscribe"

You'll see the pricing section with four tiers:

Plan	Price	Requests/Month	Best For
Basic	Free	100	Testing & evaluation
Pro	$10/mo	5,000	Small projects
Ultra	$50/mo	50,000	Production apps
Mega	$100/mo	100,000	High-volume services

Click "Subscribe" on the Basic (free) tier to get started.

2.2 Authorize with RapidAPI

If you're not logged in, RapidAPI will ask you to sign in or create an account. You can use:

Email
Google
GitHub

Once subscribed, you'll have access to the API playground.

Step 3: Open the Playground

After subscribing, you'll see the endpoint listed in the left sidebar:

Endpoints
├── rebuildImage    ← Click this

Click on "rebuildImage" to open the endpoint details.

Step 4: Configure the Request

You'll see the playground interface with several tabs:

┌────────────────────────────────────────────────────────────────┐
│  App    Params    Headers(2)    Body    Authorizations         │
├────────────────────────────────────────────────────────────────┤

4.1 Check the "App" Tab

Make sure your application and API key are selected. RapidAPI auto-fills this for you.

App: default-application_xxxxx
X-RapidAPI-Key: 97d55cc...  ← Your key (auto-filled)
Request URL: rapidapi.com

4.2 Go to the "Body" Tab

Click the "Body" tab. This is where you'll upload your image.

┌────────────────────────────────────────────────────────────────┐
│  Media Type          Example Name                              │
│  ┌──────────────┐   ┌──────────────┐                          │
│  │ BINARY    ▼ │   │ New Example  │                          │
│  └──────────────┘   └──────────────┘                          │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│  file                                                          │
│  ┌───────────────────────────────────────────────────┐        │
│  │              📤 Upload                            │        │
│  └───────────────────────────────────────────────────┘        │
│                                                                │
└────────────────────────────────────────────────────────────────┘

4.3 Select BINARY Media Type

Make sure "BINARY" is selected in the Media Type dropdown (not JSON).

Media Type: BINARY  ✓

4.4 Upload Your Test Image

Click the "Upload" button under the "file" field.

Select any image from your computer:

JPEG (.jpg, .jpeg)
PNG (.png)
GIF (.gif)
WebP (.webp)

For best testing, use an image you know has metadata:

A photo from your phone (contains GPS, camera info)
A screenshot with EXIF data
Any image downloaded from the internet

Step 5: Test the Endpoint

With your image uploaded, click the blue "Test Endpoint" button:

┌─────────────────────────┐
│  ⚡ Test Endpoint       │
└─────────────────────────┘

5.1 Wait for the Response

The API will process your image. This typically takes 1-3 seconds.

You'll see a loading indicator while it processes.

5.2 View the Results

After processing, the "Results" tab will show the response:

┌────────────────────────────────────────────────────────────────┐
│  Code Snippets    Example Responses    Results                 │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│  Response: 200 OK                                              │
│                                                                │
│  Headers:                                                      │
│  ├── content-type: image/png                                   │
│  ├── content-disposition: attachment; filename="rebuilt.png"   │
│  ├── x-rebuilt-by: ZeroTrust-WASM                              │
│  └── content-length: 45678                                     │
│                                                                │
│  Body: [Binary Data - Download Available]                      │
│                                                                │
└────────────────────────────────────────────────────────────────┘

5.3 Download the Rebuilt Image

Click the download link to save your rebuilt image.

The output will be:

PNG format (regardless of input format)
No metadata (completely stripped)
Rebuilt from raw pixels (not the original container)

Step 6: Verify the Results

6.1 Compare File Sizes

The rebuilt file size will often differ from the original because:

Different format (PNG vs JPEG)
Different compression
All metadata removed

6.2 Check Response Headers

Look for these headers in the response:

Header	Meaning
`content-type: image/png`	Output is always PNG
`x-rebuilt-by: ZeroTrust-WASM`	Processed by the CDR engine
`content-disposition: attachment; filename="rebuilt.png"`	Safe filename

6.3 Use EXIF Tools to Verify

See our separate guide on using EXIF tools to compare input/output metadata.

Understanding the Response Codes

Code	Meaning	What to Do
200	Success	Your image was rebuilt successfully
400	Dimensions exceeded	Image is larger than 4096×4096 pixels
401	Unauthorized	Check your API key
413	File too large	Image exceeds 5MB limit
415	Unsupported format	Use JPEG, PNG, GIF, or WebP
422	Malformed file	File is corrupt or not a valid image
429	Rate limit	You've exceeded your quota

Troubleshooting

"Response is empty"

Make sure you selected BINARY as the Media Type, not JSON.

"401 Unauthorized"

Check that you've subscribed to a plan
Try refreshing the page
Make sure your API key is populated in the "App" tab

"415 Unsupported Format"

The API only accepts:

JPEG
PNG
GIF
WebP

Other formats (TIFF, BMP, SVG, etc.) are not supported.

"The upload button doesn't appear"

Make sure Media Type is set to BINARY
Try a different browser
Disable ad blockers

What Just Happened?

When you clicked "Test Endpoint," here's what occurred:

Your Image                      API Processing                    Output
┌─────────────┐                ┌─────────────────┐              ┌─────────────┐
│ photo.jpg   │                │ 1. Validate     │              │ rebuilt.png │
│             │                │ 2. Decode       │              │             │
│ - 2.4 MB    │ ──────────────▶│ 3. Extract      │─────────────▶│ - 1.8 MB    │
│ - GPS data  │                │    pixels only  │              │ - No GPS    │
│ - Camera    │                │ 4. Destroy      │              │ - No EXIF   │
│   info      │                │    original     │              │ - Pure PNG  │
│ - EXIF      │                │ 5. Rebuild PNG  │              │             │
└─────────────┘                └─────────────────┘              └─────────────┘

The input was completely deconstructed. Only the visual pixels were kept. A brand new, sterile PNG file was created from scratch.

Next Steps

Now that you've tested the API:

Verify the output using EXIF analysis tools (Verification guide - Image Metadata Removal in Action)
Integrate into your app using the code snippets provided in RapidAPI -
Test edge cases with different file types and sizes

📚 Related Articles in This Series

The Hidden Threat in Every Image: Why Your Upload Validation is Broken

Raviteja Nekkalapu — Sat, 20 Dec 2025 14:59:20 +0000

A deep technical guide for developers on image-based attack vectors that bypass standard security measures

Introduction

You've probably written code like this a hundred times:

if (file.type.startsWith('image/') && file.size < 5000000) {
  uploadImage(file);
}

You check the MIME type. You validate the file extension. Maybe you even strip EXIF metadata with a library. You feel secure.

You're not.

In 2023, security researchers documented over 340 CVEs related to image processing libraries. Major platforms including social media giants, cloud storage providers, and enterprise software have been compromised through image upload vulnerabilities.

This isn't theoretical. This is happening right now.

Part 1: The Anatomy of Image-Based Attacks

1.1 Understanding File Formats

Before we dive into attacks, let's understand what an image file actually is.

A JPEG file isn't just pixels. It's a complex container with:

┌─────────────────────────────────────────────┐
│  JPEG File Structure                        │
├─────────────────────────────────────────────┤
│  ┌─────────────────────────────────────┐    │
│  │ SOI Marker (Start of Image)         │    │
│  │ FF D8                               │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │ APP1 Marker (EXIF Data)             │    │
│  │ - Camera model                      │    │
│  │ - GPS coordinates                   │    │
│  │ - Timestamps                        │    │
│  │ - Thumbnail (another full image!)   │    │
│  │ - Custom fields (ANYTHING)          │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │ DQT (Quantization Tables)           │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │ SOF (Start of Frame)                │    │
│  │ - Image dimensions                  │    │
│  │ - Color components                  │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │ Compressed Image Data               │    │
│  │ (DCT coefficients)                  │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │ EOI Marker (End of Image)           │    │
│  │ FF D9                               │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │ TRAILING DATA                       │    │
│  │ (Ignored by image viewers!)         │    │
│  │ ⚠️ ANYTHING CAN HIDE HERE ⚠️        │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

See that "TRAILING DATA" section? Most image parsers stop reading at the EOI marker. But the data is still there. And that's where attackers hide things.

Part 2: The Three Attack Vectors That Bypass Your Validation

2.1 Polyglot Files: The Shape-Shifters

A polyglot file is a file that's valid in multiple formats simultaneously.

Real-World Example: The GIFAR Attack (2008)

In 2008, security researcher Billy Rios demonstrated an attack that combined GIF images with Java JAR files. The same file was:

A valid GIF image (browsers displayed it normally)
A valid Java applet (Java runtime executed it)

How It Works:

Normal GIF Structure:
[GIF Header: GIF89a] [Image Data] [Trailer: 0x3B]

Polyglot GIFAR:
[GIF Header: GIF89a] [Image Data] [Trailer: 0x3B] [ZIP/JAR Archive]
                                                   ↑
                                         Java reads from here

GIF parsers read from the beginning. ZIP/JAR parsers read from the end (they look for the End of Central Directory signature). Both see a valid file.

Modern Variants:

Polyglot Type	Visible Format	Hidden Format	Attack Vector
PHAR-JPEG	JPEG image	PHP archive	Server-side code execution
PDF-JS	PDF document	JavaScript	XSS in PDF viewers
PNG-HTML	PNG image	HTML page	XSS when served with wrong MIME
GIF-ZIP	GIF image	ZIP archive	Archive extraction vulnerabilities

Example: PHP Phar Polyglot

[JPEG Header FF D8 FF] [JPEG Data] [JPEG Footer FF D9] [<?php system($_GET['cmd']); ?>] [Phar Manifest]

This file:

Passes image validation ✓
Displays as a normal photo ✓
Executes as PHP code when accessed via phar:// wrapper ✓

This attack affected WordPress, Magento, Drupal, and many other PHP applications.

2.2 Steganography: Invisible Data Smuggling

Steganography isn't science fiction. It's a standard tool in Advanced Persistent Threat (APT) operations.

How It Works: LSB (Least Significant Bit) Encoding

Every pixel in an image has color values. In an 8-bit RGB image:

Original Pixel: RGB(156, 203, 89)

Binary:
R: 10011100 (156)
G: 11001011 (203)  
B: 01011001 (89)
        ↑
        Least Significant Bit

Changing the LSB modifies the color by ±1. The human eye cannot detect this difference:

Original: RGB(156, 203, 89)  → Olive green
Modified: RGB(157, 202, 88)  → Still olive green (imperceptible)

Data Capacity:

A 1920×1080 image = 2,073,600 pixels
Each pixel can hide 3 bits (one per color channel)
Total hidden capacity = 778 KB of secret data

Real-World Attacks Using Steganography:

Campaign	Year	Method	Purpose
Turla APT	2020	PNG images on legitimate websites	C2 command delivery
OceanLotus	2019	JPEG in spear-phishing emails	Malware payload
Platinum APT	2017	BMP images	Exfiltration channels
StegoLoader	2015	PNG files	Malware distribution

The Problem:

Your server becomes a "dead drop" for criminals. The malware doesn't run on your server—but your server hosts the encrypted payload for compromised machines worldwide to download.

Antivirus scans won't catch it. There's no malicious code in the file—just slightly modified colors that decode to commands when read by malware already on victim machines.

2.3 Image Bombs: The Memory Killers

Also called "decompression bombs" or "zip bombs for images."

How It Works:

Image files use compression. A small file can represent a massive image.

Example: The 50KB → 50GB Attack

Malicious PNG Configuration:
- File size on disk: 50 KB
- Claimed dimensions: 50,000 × 50,000 pixels
- Uncompressed size: 50,000 × 50,000 × 4 bytes = 10 GB

What happens when your server tries to process it:
1. Upload filter sees 50KB file → ✓ Passes size check
2. Server malloc() attempts 10GB allocation
3. OOM Killer terminates your process
4. Service crash → Denial of Service achieved

Dimension Attacks:

Some servers check total file size but not dimensions:

# Vulnerable code
if uploaded_file.size < 5_000_000:  # 5MB limit
    image = Image.open(uploaded_file)  # 💥 BOOM
    thumbnail = image.resize((100, 100))

A malformed image header can claim dimensions of 4,294,967,295 × 4,294,967,295 pixels (max uint32). Just opening this file to read dimensions causes memory allocation failures.

Historical Incidents:

2021: A single crafted PNG crashed multiple cloud image processing services
2019: CVE-2019-19326 in ImageMagick allowed billion-laugh-style attacks
2016: The "ImageTragick" vulnerability (CVE-2016-3714) affected thousands of websites

Part 3: Why Standard "Sanitization" Fails

3.1 The Metadata Stripping Myth

Many developers believe "just strip the EXIF data" is sufficient. Let's examine this claim.

What EXIF stripping tools actually do:

Original JPEG:
┌──────────────────────────────────────┐
│ SOI │ APP1 (EXIF) │ Image Data │ EOI │
└──────────────────────────────────────┘

After EXIF stripping:
┌──────────────────────────────────────┐
│ SOI │ Image Data │ EOI              │
└──────────────────────────────────────┘

Looks clean, right? But here's what they don't do:

❌ They don't verify the image data itself is valid
❌ They don't remove data after the EOI marker
❌ They don't destroy steganographic payloads
❌ They don't check for polyglot structures
❌ They don't enforce dimension limits during processing

Example: Polyglot Survives EXIF Stripping

Before stripping:
[JPEG Header][EXIF][Image][EOI][<?php malicious_code(); ?>]

After stripping:
[JPEG Header][Image][EOI][<?php malicious_code(); ?>]
                         ↑
                         STILL THERE!

The EXIF stripper only touched the EXIF segment. The malicious payload after the EOI marker remains intact.

3.2 The "Magic Bytes" Fallacy

Some developers check "magic bytes" (file signatures):

# "Secure" validation
def is_jpeg(data):
    return data[:2] == b'\xFF\xD8'  # JPEG magic bytes

# Reality: This checks nothing meaningful

A polyglot file has valid JPEG magic bytes. A steganographic image has valid magic bytes. An image bomb has valid magic bytes.

Magic byte checking tells you the file starts like a JPEG. It tells you nothing about what's inside or after.

3.3 Library Vulnerabilities

Running untrusted images through processing libraries is inherently dangerous.

CVE History for Popular Libraries:

Library	Critical CVEs (2020-2024)	Common Vulnerabilities
ImageMagick	47	RCE, SSRF, DoS, Memory corruption
libpng	12	Buffer overflow, DoS
libjpeg	8	Integer overflow, null pointer dereference
Pillow (Python)	23	DoS, buffer overflow, path traversal
Sharp (Node.js)	6	Memory corruption, DoS

Every time you call Image.open() or sharp() or convert, you're passing untrusted data to C code that has had dozens of memory safety vulnerabilities.

Part 4: The Correct Approach - Content Disarm & Reconstruction (CDR)

4.1 Philosophy Shift

Traditional security asks: "Is this file safe?"

This is impossible to answer with certainty
You're looking for "bad" things in an infinite search space
Attackers always find new hiding spots

CDR asks: "What do I know is safe?"

Only the raw pixel values are "good"
Everything else is discarded
The search space is exactly one thing: pixels

4.2 The CDR Process

┌─────────────────────────────────────────────────────────────┐
│                    CDR Pipeline                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   UNTRUSTED INPUT                                          │
│   ┌─────────────┐                                          │
│   │ user.jpg    │   Contains:                              │
│   │             │   - EXIF metadata                        │
│   │  📷🔓       │   - GPS coordinates                      │
│   │             │   - Possible steganography               │
│   │             │   - Possible polyglot payload            │
│   │             │   - Unknown structure                    │
│   └─────────────┘                                          │
│          │                                                  │
│          ▼                                                  │
│   ┌─────────────────────────────────────────────┐          │
│   │ STEP 1: Decode to Raw Pixels               │          │
│   │                                             │          │
│   │ Input → Image Decoder → RGBA Buffer        │          │
│   │                                             │          │
│   │ Only the pixel values are extracted.       │          │
│   │ Container structure is parsed, not copied. │          │
│   └─────────────────────────────────────────────┘          │
│          │                                                  │
│          ▼                                                  │
│   ┌─────────────┐                                          │
│   │ Raw Pixels  │   Just a flat array:                     │
│   │             │   [R,G,B,A, R,G,B,A, R,G,B,A, ...]      │
│   │  🎨         │                                          │
│   │             │   No metadata. No structure.             │
│   │             │   No hidden data. Just colors.           │
│   └─────────────┘                                          │
│          │                                                  │
│          ▼                                                  │
│   ┌─────────────────────────────────────────────┐          │
│   │ STEP 2: Destroy Original Container         │          │
│   │                                             │          │
│   │ 🗑️ Original file is completely discarded   │          │
│   │ 🗑️ All metadata gone                       │          │
│   │ 🗑️ All structure gone                      │          │
│   │ 🗑️ All trailing data gone                  │          │
│   │ 🗑️ All steganography destroyed             │          │
│   └─────────────────────────────────────────────┘          │
│          │                                                  │
│          ▼                                                  │
│   ┌─────────────────────────────────────────────┐          │
│   │ STEP 3: Rebuild New Container              │          │
│   │                                             │          │
│   │ Raw Pixels → PNG Encoder → New File        │          │
│   │                                             │          │
│   │ A brand new file is created from scratch.  │          │
│   │ Only standard PNG structure. No extras.    │          │
│   └─────────────────────────────────────────────┘          │
│          │                                                  │
│          ▼                                                  │
│   GUARANTEED SAFE OUTPUT                                    │
│   ┌─────────────┐                                          │
│   │ output.png  │   Contains:                              │
│   │             │   ✅ Clean PNG structure                 │
│   │  📷🔒       │   ✅ Just pixels, nothing else           │
│   │             │   ✅ No metadata                         │
│   │             │   ✅ No polyglot possible                │
│   │             │   ✅ No steganography                    │
│   │             │   ✅ Mathematically generated            │
│   └─────────────┘                                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4.3 What Gets Destroyed

When you rebuild an image from pixels, you eliminate:

Threat	How CDR Neutralizes It
EXIF/XMP/IPTC metadata	Original container discarded; new file has no metadata fields
GPS coordinates	Part of metadata; gone with the container
Polyglot payloads	Trailing data not copied; new file is pure PNG
Steganography	Re-encoding changes compression; hidden bit patterns scrambled
Comment fields	Not copied to new container
Thumbnails	Not copied; new file has no embedded images
ICC profiles	Optionally stripped or standardized
Malformed structures	Original structure not preserved; parsing exploits ineffective

Part 5: Evaluating Solutions

5.1 What to Look For

When choosing an image processing solution for security:

Must-Have Features:

Full decode/re-encode cycle - Not just metadata stripping
Memory limits - Hard caps on allocation to prevent DoS
Dimension limits - Enforced before or during decode
Format whitelisting - Explicit allow-list, not block-list
Sandboxed execution - Processing isolated from host system
No file system access - Processing in memory only

Red Flags:

"Strips metadata" (doesn't rebuild)
"Validates format" (doesn't process)
"Checks headers" (checks nothing meaningful)
Uses ImageMagick/GraphicsMagick (CVE-prone)
No memory/dimension limits mentioned
Runs on your server (you assume the risk)

5.2 The Enterprise CDR Market

Enterprise solutions for CDR exist but are typically:

Solution Type	Price Range	Target Market
On-premise appliances	$50,000 - $500,000+	Fortune 500, Government
Cloud enterprise	$10,000 - $50,000/year	Mid-market enterprises
API-based services	Varies widely	Developers, SMBs

Most enterprise CDR solutions are designed for email attachments and document processing. Image-specific CDR with developer-friendly API access is rare.

Part 6: Implementing Secure Image Handling

6.1 Defense in Depth

No single solution is perfect. Layer your defenses:

Layer 1: Edge/CDN
├── Rate limiting
├── File size limits at network level  
└── WAF rules for image endpoints

Layer 2: Application
├── Content-Type validation
├── Extension validation
└── Size validation

Layer 3: Processing
├── CDR (decode → destroy → rebuild)
├── Memory limits
└── Timeout limits

Layer 4: Storage
├── Separate domain for user content
├── No-execute permissions
└── Content-Type headers enforced

Part 7: Testing Your Security

7.1 Create Test Cases

Before deploying, test against:

Polyglot files - JPEG with PHP payload after EOI
Dimension bombs - Small file, massive claimed dimensions
Steganographic images - Use tools like steghide to embed data
Metadata-heavy files - GPS, comments, thumbnails
Malformed structures - Truncated files, wrong headers

7.2 Verification Checklist

After processing, verify:

[ ] Output file has no EXIF/XMP/IPTC data
[ ] Output file size is reasonable (not the original embedded polyglot size)
[ ] file command shows clean format identification
[ ] No trailing data after image end marker
[ ] Dimensions match expected (within your limits)

Conclusion

Image security is not solved by checking file extensions and stripping metadata. The threat landscape includes:

Polyglot files that pass validation but contain executable code
Steganographic payloads invisible to the human eye and antivirus
Image bombs that crash your servers
Library vulnerabilities in every major image processing tool

The only complete solution is Content Disarm & Reconstruction: decode to raw pixels, destroy the original container, and rebuild from scratch.

This eliminates the entire attack surface by reducing the trusted input to exactly one thing—the visual content itself.

This article is intended for educational purposes.

📚 Continue Learning

If you want to see CDR in action and understand exactly what gets removed from images, I've written a hands-on guide:

Hands-On: See Image Metadata Removal in Action

This follow-up guide shows you how to:

Use free online tools to inspect image metadata
Compare before/after results
Verify that processing actually eliminates threats

It's a practical companion to the theory covered here.

📚 Related Articles in This Series

Stop Using Inaccurate Nutrition APIs - How USDA Data Changes Everything

Raviteja Nekkalapu — Wed, 17 Dec 2025 13:13:33 +0000

The $50 Billion Problem

Health apps are everywhere. Calorie counters. Macro trackers. Diet planners. Fitness companions.

They all share one critical dependency: nutrition data.

And here's the uncomfortable truth: most of that data is garbage.

I spent months evaluating nutrition APIs for my own projects. What I found was shocking:

Crowdsourced databases where users enter "100 calories for a slice of pizza" (which slice? what size? what toppings?)
AI-estimated values that hallucinate nutrient content
Outdated datasets from the 1990s
Missing micronutrients hidden behind $100+/month paywalls

Your users trust these numbers to make health decisions. Some are managing diabetes. Others are tracking pregnancy nutrition. Athletes use them for performance optimization.

They deserve accurate data.

Why I Built the Nutrition Tracker API

After failing to find a reliable, affordable nutrition API, I built one myself.

Core principle: Laboratory-analyzed USDA data, accessible to everyone.

The USDA FoodData Central Advantage

The USDA doesn't guess. They:

Collect samples from actual food products
Analyze in certified laboratories using standardized methods
Publish peer-reviewed data with uncertainty measurements
Update regularly as food compositions change

This is the same data used by:

Hospital dietitians
Academic researchers
Government nutrition programs
Pharmaceutical companies

Now it's available via API for your health app.

What "25+ Nutrients" Actually Means

Every API says they have "comprehensive nutrition data." Here's what ours actually returns:

Energy & Macros

Nutrient	Included	Notes
Energy	✅	Kilocalories
Protein	✅	Complete amino acid profile
Total Fat	✅	With full breakdown
Carbohydrates	✅	By difference method
Fiber	✅	Dietary fiber
Sugars	✅	Total sugars

The Fat Breakdown Nobody Else Does

Most APIs: "fat": 15.2

Our API:

{
  "Fat": {
    "value": 15.2,
    "unit": "g",
    "breakdown": {
      "saturated": { "value": 5.1, "unit": "g" },
      "monounsaturated": { "value": 6.8, "unit": "g" },
      "polyunsaturated": { "value": 2.4, "unit": "g" },
      "trans": { "value": 0.3, "unit": "g" },
      "other": { "value": 0.6, "unit": "g" }
    }
  }
}

Why this matters:

Cardiologists recommend limiting saturated fat to <10% of calories
Trans fats are linked to heart disease—users need to track them
Monounsaturated fats have different health impacts
Keto and IIFYM apps need precise fat breakdowns

Complete Vitamin Suite

Vitamin	Unit	Why It Matters
A	IU	Vision, immune function
B1 (Thiamin)	mg	Energy metabolism
B2 (Riboflavin)	mg	Cell function
B3 (Niacin)	mg	DNA repair
B5 (Pantothenic)	mg	Hormone production
B6	mg	Brain development
B12	µg	Nerve function, blood cells
C	mg	Collagen, immune system
D	IU	Bone health, immunity
E	mg	Antioxidant
K	µg	Blood clotting, bones
Folate	µg	Cell division, pregnancy
Choline	mg	Brain, liver function

Essential Minerals

Mineral	Unit	Key Function
Calcium	mg	Bones, muscle function
Iron	mg	Oxygen transport
Magnesium	mg	300+ enzyme reactions
Phosphorus	mg	Energy, bone structure
Potassium	mg	Heart rhythm, fluid balance
Sodium	mg	Fluid balance, nerves
Zinc	mg	Immune function, healing
Copper	mg	Iron metabolism
Manganese	mg	Bone formation
Selenium	µg	Thyroid, antioxidant

All of these. In every response. Including the free tier.

Competitive Analysis

Feature	Nutrition Tracker API	Competitor A	Competitor B
Free Tier Nutrients	25+	6	10
Fat Breakdown	Saturated, Mono, Poly, Trans	Total only	Saturated only
Data Source	USDA Laboratory	Crowdsourced	Mixed
Natural Language	Yes	Limited	No
Response Time	<100ms	300ms	500ms
Free Monthly Calls	1,000	100	500

We're not hiding features behind paywalls. The free tier is genuinely useful.

Integration Examples

Python

from nutrition_api import NutritionAPI

api = NutritionAPI("your-api-key")
result = api.calculate("100g salmon with lemon and dill")

print(f"Protein: {result['Protein']['value']}g")
print(f"Vitamin D: {result['Vitamin D']['value']} {result['Vitamin D']['unit']}")

JavaScript

const response = await fetch(
  'https://nutrition-tracker-api.p.rapidapi.com/v1/calculate/natural',
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-RapidAPI-Key': 'your-key',
      'X-RapidAPI-Host': 'nutrition-tracker-api.p.rapidapi.com'
    },
    body: JSON.stringify({ text: '100g salmon with lemon' })
  }
);

const data = await response.json();
console.log('Nutrients:', data.data.totalNutrients);

Use Cases

Medical Nutrition Apps

Track sodium for hypertension patients
Monitor potassium for kidney disease
Calculate folate for pregnancy tracking

Fitness & Performance

Precise protein tracking for athletes
Electrolyte monitoring
Micronutrient optimization

Diet & Lifestyle Apps

Complete keto macros with fat breakdown
Vegan B12 and iron tracking
Full nutrient visibility

Pricing

Tier	Price	Monthly Calls	Items/Request
Free	$0	1,000	2
Starter	$25	50,000	5
Business	$50	100,000	10

Every tier gets full 25+ nutrient access.

Get Started

curl -X POST "https://nutrition-tracker-api.p.rapidapi.com/v1/calculate/natural" \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: nutrition-tracker-api.p.rapidapi.com" \
  -d '{"text": "1 large apple"}'

Resources

🚀 RapidAPI Listing
📖 Documentation
🐍 Python SDK
📦 JavaScript SDK
☕ Java SDK

The Bottom Line

Your users deserve nutrition data they can trust.

Not crowdsourced guesses. Not AI hallucinations. Not 4 nutrients when they need 25.

Real USDA laboratory data. Every nutrient. Every tier.

Try it free. Build something amazing.

Questions? Drop a comment!