DEV Community: mktbsh

I built Header Relay: a Chrome extension that captures response headers and replays them on later requests

mktbsh — Fri, 17 Jul 2026 17:02:07 +0000

If you develop against APIs that hand you a session token, trace ID, or gateway header in a response, and expect it back on the next request, you know the dance: copy the value from DevTools, paste it into ModHeader or curl, repeat every time it rotates.

The fix seems obvious: let the browser itself relay the header. But the API you would reach for — a blocking webRequest listener that rewrites request headers — is exactly what Manifest V3 removed. That constraint shaped most of the design below.

Header Relay - Chrome Web Store

Capture HTTP response headers and relay fixed or captured headers to matching browser requests.

chromewebstore.google.com

Header Relay automates the loop anyway, entirely inside the browser.

What it does

Header Relay is a Manifest V3 Chrome extension for API development and testing:

Captured headers — watch responses from a target origin, keep a configured header's value (e.g. x-session-token) in session memory, and attach it to later matching requests automatically.
Fixed headers — always attach static headers like x-client-id: my-app to a target origin.
Origin-scoped profiles — each profile targets specific origins (localhost, staging, internal envs), and multiple profiles can run at once.
Excluded paths — glob patterns to keep relay-managed headers off assets or specific endpoints, with a built-in tester.
URL Probe — paste a URL and see whether it matches, which profiles apply, and exactly which headers would be attached — before saving.

Why not a proxy or a static header extension?

Static header extensions (ModHeader-style) can't follow dynamic values that the server rotates per session.
A local proxy (mitmproxy, Charles) can, but it means TLS interception on your machine — heavyweight for "I just want the browser to keep sending this token back".

Header Relay sits in that gap: no proxy, no DevTools babysitting. And if ModHeader's recent removal from the stores left you shopping for a replacement, the static-header use case is covered too.

How it works under the hood

So how do you rewrite request headers on MV3 without blocking webRequest? By splitting observation from rewriting:

webRequest (non-blocking) observes response headers for enabled target origins and stores captured values in storage.session (memory only).
Every enabled profile + its session state is compiled into a single intermediate representation, which is synced to one declarativeNetRequest session ruleset. Attach rules add fixed/captured headers; remove rules strip them on excluded paths.
On the next matching request, Chrome's DNR engine attaches the headers natively — no request-time JavaScript involved.

One compile path

Origin matching and path exclusion are needed in three places: DNR rule generation, the URL Probe, and the runtime status view. Implement them three times and they will drift apart eventually — that's where bugs like "the Probe says the header attaches, but the real request never gets it" come from. So all three consume the output of a single compileConfig() step, and the matching logic exists in exactly one place.

Conflicts are errors

What happens when two enabled profiles set the same header on the same origin? DNR rules carry a priority field, so silent auto-resolution would be the easy answer. But in a testing tool, "which value actually got attached?" is worse than attaching nothing at all. So a conflict is a compile error: all owned rules are removed, the UI shows what conflicts with what, and disabling either profile recovers.

Privacy and permissions

This category of extension deserves suspicion, so the design is deliberately conservative:

Captured values live only in in-memory session storage — cleared on browser restart, extension reload, profile disable, or permission revocation. Masked by default in the UI.
No external transmission. Nothing is sent to me or any analytics backend. Configured headers go only to the target origins you configured.
Host permissions are optional and per-origin: adding a target origin triggers a permissions.request() from a user gesture. No grant → no rules, fail-closed. Only http://localhost/* is bundled for the default local workflow.
Response-only / transport headers (Set-Cookie, Host, Content-Length, Transfer-Encoding, …) are rejected outright; sensitive names like Authorization are allowed with an explicit warning.

Stack

WXT + TypeScript + SolidJS + Tailwind CSS. The runtime touches the browser through three ports only (storage / DNR / audit), so the whole extension runs headless in Vitest with in-memory adapters — config in, fake responses, assert on the resulting ruleset, no module mocks.

Try it

Header Relay - Chrome Web Store

Capture HTTP response headers and relay fixed or captured headers to matching browser requests.

chromewebstore.google.com

Website: https://hsblabs.github.io/header-relay/
Issues & feedback: https://github.com/hsblabs/header-relay/issues
Blog:
- en: https://hsb.horse/en/blog/header-relay-published/
- ja-JP: https://hsb.horse/blog/header-relay-published/

It ships with a localhost profile out of the box (x-session-token capture + a fixed x-client-id), so pnpm dev on port 3000 works immediately.

The source itself isn't public, but bug reports and feature requests are tracked openly on GitHub issues. Feedback very welcome — especially edge cases in your header workflows that it doesn't cover yet.

ModHeader was flagged as malware and pulled from Edge — here's how to audit any header-editing extension before you trust it

mktbsh — Mon, 13 Jul 2026 04:32:25 +0000

What happened

On July 3, 2026, Microsoft removed ModHeader — a header-editing extension with roughly 1.6M combined installs across Chrome and Edge — from the Edge Add-ons store after Google flagged it as malware.

Independent security researchers who analyzed build 7.0.18 found a hidden module disguised as a date-formatting library. It was capable of collecting visited domains and preparing a daily encrypted upload to an external endpoint. To be precise about what was and wasn't confirmed: the researchers reported the collector was dormant in the build they tested, and they found no confirmed evidence of data actually leaving a test profile. Still, the capability being present at all — undisclosed, in a widely-installed dev tool — is the story.

Sources (do your own reading, don't just take my word for it):

HackIndex — "ModHeader Malware: Inside the Chrome Spyware Google Removed"
GridinSoft — "ModHeader Malware Warning: Remove Extension 7.0.18"
OffSeq Threat Radar — "ModHeader removed for malware"
Koi Security — "Is ModHeader safe?"

Why this matters beyond ModHeader

Header-editing extensions are a uniquely sensitive category. To do their job they need broad host permissions (<all_urls> or close to it) and they sit in the request/response path of literally everything you browse — including whatever internal APIs, staging environments, and authenticated sessions you're debugging. A malicious or compromised one is a bigger blast radius than almost any other extension class.

If you rely on one of these for API development, this is a good moment to actually check what yours does, not just assume it's fine because it has a lot of installs.

A quick checklist for auditing your header extension

Read the permissions it actually requests. Does it need <all_urls>, or could it be scoped to specific origins?
Check what network requests the extension itself makes — not the pages you're on, the extension's own background/service worker. chrome://extensions → enable Developer mode → inspect the service worker → Network tab.
Look for bundled dependencies that don't match what a header tool needs. A hidden analytics/upload module dressed up as a date library is exactly the kind of thing that hides in plain sight in a large bundle.
Prefer extensions where captured/stored values are visible, not hidden. If a tool captures a session token or API key from a response header, you should be able to see the actual value it captured, not just a black box confirming "captured."
Prefer declarativeNetRequest over raw webRequest blocking where possible — it's a narrower, more sandboxed API for attaching headers, and easier to audit.

Where I'm coming from

I maintain Header Relay, a Chrome extension in the same category (attach fixed or captured headers to requests for local/staging/internal API development). I'm not neutral here, so take the following with that in mind — but the checklist above applies to Header Relay too, and you should hold it to the same bar:

No bundled code that talks to any external endpoint — header relay logic lives in one reviewable module, and requests are attached entirely via Chrome's declarativeNetRequest + local storage.
Captured and fixed header values are shown in plain text in the popup and options page.
Runtime behavior is scoped to the origins enabled in your active profile — nothing else gets touched.
Full source and privacy policy are linked from the project site if you want to verify any of this yourself rather than trust the bullet points.

If you're migrating off ModHeader (or auditing whatever extension you currently use, header-related or not), migration is 3 steps: create a profile with your target origins, re-add any fixed headers (API keys, client IDs) as Fixed Headers, and set up Captured Headers for anything you were previously copy-pasting from responses (session tokens, trace IDs).

Full writeup with sources: https://hsblabs.github.io/header-relay/modheader-alternative

Not affiliated with ModHeader or its developers — everything above is based on the third-party research linked, published July 2026.

Releasing @hsblabs/web-stream-extras: small utilities for WHATWG byte stream pipelines

mktbsh — Wed, 04 Mar 2026 18:30:00 +0000

I published @hsblabs/web-stream-extras.

It started as internal plumbing I kept copy-pasting across projects. Enough utility collected around ReadableStream<Uint8Array> that it made sense to package it properly.

npm install @hsblabs/web-stream-extras

Node.js ≥22 and modern browsers. No runtime dependencies.

What's in the root package

The root export handles the everyday byte stream operations.

import {
  readableFromChunks,
  readAllBytes,
  stringToBinary,
  binaryToString,
} from "@hsblabs/web-stream-extras";

const stream = readableFromChunks([
  stringToBinary("hello"),
  stringToBinary(" world"),
]);

const result = await readAllBytes(stream);
console.log(binaryToString(result)); // "hello world"

readableFromChunks wraps an array of Uint8Array chunks into a proper ReadableStream. readAllBytes collects everything from a stream into a single Uint8Array. The string and buffer conversion helpers — stringToBinary, binaryToString, toU8Array, toArrayBuffer, concatU8Arrays — exist because converting between string, Uint8Array, and ArrayBuffer is repetitive and easy to get subtly wrong.

ByteTransformStream is an abstract base for building typed binary transform pipelines. ByteQueue handles internal buffering with a clean read/write interface — useful when you need to track partial byte reads across chunks.

Base64url encoding is included too: encodeBase64Url and decodeBase64Url, without padding.

Stream encryption

The encryption subpath adds encryption built on the Web Crypto API.

import {
  encryptStream,
  decryptStream,
} from "@hsblabs/web-stream-extras/encryption";

const key = crypto.getRandomValues(new Uint8Array(32));
const encrypted = encryptStream(key, plaintext);
const decrypted = decryptStream(key, encrypted);

encryptStream and decryptStream take a ReadableStream and return a ReadableStream. The underlying EncryptionStream and DecryptionStream are exposed as TransformStream wrappers if you need to compose them differently.

For cases where you need key management, webCryptoStream(masterKey) handles deriving and encrypting per-stream keys with an AES-GCM master key.

Why Web Streams

The WHATWG Streams API is available natively in Node.js ≥18 and all modern browsers. Using it directly avoids Node.js-specific stream abstractions and keeps the code portable. If you're targeting environments where both sides — browser and server — need to handle the same byte pipeline, the WHATWG API is the right base layer.

npm · GitHub

Issues and feedback welcome.