Like a lot of developers, I had ModHeader pinned in my browser for years. It's the tool you reach for a dozen times a day — spoof an Authorization token, force a Cache-Control, fake a User-Agent, bypass CORS on localhost. It just works.

Then one morning Chrome switched it off and flagged it as malware.

No note. No reason. Just gone — for the 800,000+ people who had it installed. So I went looking for what happened, and what I found is the reason this extension now exists.

What actually happened

Security researchers at HackIndex pulled the delisted build (v7.0.18, on the official ModHeader listing, carrying valid Chrome Web Store signatures) and reverse-engineered it. The short version:

  • A spyware SDK was hidden inside a file named dayjs.min-*.js — disguised as a harmless date library. Its exports weren't date helpers; they were tools to grab the domains you visit, AES-GCM-encrypt them, and POST them once a day to api.stanfordstudies.com — a fake "Stanford research" front with no connection to Stanford.
  • The collector shipped dormant behind an empty allowlist. The endpoint, the encryption key, and the daily scheduler were all there — one auto-update away from switching on for everyone.
  • Separately, the extension's own "history" feature had quietly hoarded 178 MB of full request and response headers from all browsing, sitting unencrypted on disk. Headers routinely contain auth tokens, session cookies, and internal URLs.

(Full technical writeup and indicators of compromise: HackIndex's ModHeader malware analysis — credit to their research team.)

The uncomfortable part

None of this was a hack. It rode in on the official listing, with valid signatures, through the normal auto-update channel. A tool you already trusted, with permission to see all your traffic, simply started doing more than its job.

That's the real lesson: a header tool needs broad access to your traffic to function. That access is normal — and it's exactly what makes it a high-value target. Trust in an installed extension isn't a one-time decision; it silently re-ups with every background update you never see.

So I built the opposite

Open ModHeader is a header editor designed so this class of problem can't happen — and so you don't have to take my word for it:

  • declarativeNetRequest only. The browser applies your rules. The extension never reads, logs, or transmits your traffic. There is no webRequest listener, because there's no code path that needs to see your requests.
  • Zero network calls. No analytics, no telemetry, no remote config. Nothing phones home, because nothing is allowed to.
  • No header history. It stores your rules — nothing else. There's no 178 MB hoard to leak.
  • Minimal permissions. Just declarativeNetRequest and storage.
  • Fully open source and auditable. Every line is on GitHub. Reproducible builds, automated releases, and a real privacy policy. Read the code, or better, don't trust me — verify it.

It does what you actually use a header tool for: set/remove request and response headers, multiple profiles, one-click presets like CORS bypass, and import/export that's compatible with ModHeader so switching takes seconds.

I'm not claiming it's more polished than a tool with a decade of development. I'm claiming it's safe by construction — the architecture removes the capability to spy, rather than promising not to.

If you've got a header tool in your browser right now, go look at what it can see. Then decide whether you can audit it.

Install from the Chrome Web Store → https://chromewebstore.google.com/detail/open-modheader/ggkoalhonillnaanakakfgjamcklphkk

Open ModHeader → github.com/melon-husk/open-mod-header