v1.2.2 Bug-fix

[1.2.2] — 2026-08-01

Bug-fix release. Credential-bearing cookies were not carried through profile
duplication, export, or import. No new permissions, no schema change, and no
change to how credentials are stored.

Fixed

Duplicating a profile silently shared its cookie credential

• Duplicating a profile whose only credential was a cookie skipped the
  "configuration only / reuse / new credential" prompt entirely and fell
  through to the default
• Because the duplication step also ignored cookies, the copy kept a reference
  to the original's stored secret. The result was a shared credential the user
  was never asked about, where editing one profile's cookie would change the
  other's
• The prompt now appears whenever a profile holds any credential, cookie or
  header, and all three duplication modes apply to cookies:
  • Configuration only clears the cookie's secret reference and marks it as
    needing a credential
  • Reuse the existing credential keeps the same reference, as intended
  • New independent credential creates a fresh secret and asks for its value
    Exports omitted cookie credentials
• "Export with credentials" produced an empty value for every cookie, so a
  backup looked complete but restored a profile with no working cookie
• A configuration-only export wrote an empty string rather than the null
  placeholder an import reads, so restored profiles were not correctly marked
  as needing a credential
• Both export modes now handle cookies exactly as they handle headers
  Imports ignored cookie credentials
• Credential cookies in an imported file were not detected, so their values
  were neither reported to the user nor moved into the active storage mode
• Imported cookie credentials are now detected, disclosed before import, and
  stored under whichever credential mode is currently selected
• Import entries are keyed by section as well as name, so a header and a cookie
  sharing a name can no longer overwrite one another

Notes

Ordinary cookies such as locale were unaffected throughout and continue to
copy, export, and import with their values intact.

If you duplicated a profile containing a credential cookie on 1.2.1, check
whether the copy is sharing the original's credential: open the cookie row and
look for the "Shared" marker. Re-duplicating on this version gives the choice
that should have been offered.

v1.2.1

[1.2.1] — 2026-08-01

Added

Credential cookies

• Cookies get the same treatment as headers, because a session cookie is as
  much a credential as a bearer token
• session, sessionid, sid, connect.sid, jsessionid, phpsessid,
  csrf_token, access_token, refresh_token, jwt and similar are
  recognised, along with patterns for names ending in _token, _auth,
  _secret or _key
• A recognised cookie's value moves into the secret store: encrypted in vault
  mode, cleared on lock, revealed with the eye button, omitted from exports
• Ordinary cookies such as locale or theme keep their inline value
• The shield button marks any cookie the built-in list does not recognise

v1.2.0 - Major Security Update

[1.2.0] — 2026-08-01

Credential security release. Headers that carry credentials are now recognised,
scoped, and stored separately from the rest of your configuration. One new
permission: alarms, used solely to schedule the vault auto-lock.

Existing profiles keep working. Nothing is deleted, and you choose how your
credentials are stored the first time you open the popup after updating.

Added

Credential detection

• Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-API-Key,
  API-Key, X-Auth-Token, X-Access-Token and vendor variants such as
  X-Acme-Api-Key are recognised case-insensitively
• A shield button on every header row marks anything else as a credential,
  because no built-in list covers every vendor's naming
• Cookies created in the cookie editor are treated as credential-bearing

Host restrictions

• A credential-bearing header will not activate until its profile has a real
  URL or host filter. A bare * or <all_urls> does not count
• If you need one everywhere, a per-profile override accepts the risk for that
  profile alone and leaves the rest protected
• A warning when a credential targets a plain http:// host, with local
  development addresses exempt
  Three credential-storage modes
• Session only (default) — memory-only, cleared when the browser session
  ends. Profiles survive and simply ask for the credential again
• Encrypted vault — AES-GCM, key derived with PBKDF2 (600,000 SHA-256
  iterations), unique salt per vault and unique IV per secret. Unlocked with a
  passphrase after each restart
• Persistent plaintext — not recommended — the previous behaviour, kept for
  people who need it, behind an explicit confirmation

Vault locking

• Locking freezes every profile that holds credentials: rules stop applying and
  the profile cannot be viewed or edited. Profiles without credentials keep
  working and stay editable
• Auto-locks after a configurable period of inactivity, 15 minutes by default,
  measured from your last deliberate credential action. Network traffic does
  not hold the vault open
• Scheduled with the alarms API and verified against a stored timestamp, so a
  suspended background worker or a late alarm cannot leave it unlocked
• A Lock now action in the title bar and in the settings panel
• Change the passphrase, which re-encrypts every credential in one write, or
  reset the vault, which deletes them after a clear warning

Viewing credentials

• An eye button reveals a stored credential inline, and an eye-with-a-slash
  hides it again. Revealed values are cleared when the vault locks
• Unlocking is the authentication step, so an unlocked vault does not ask
  again. An optional strict mode, off by default, re-derives the key from a
  freshly typed passphrase for each reveal

Safer export, clipboard, and duplication

• Exports offer configuration only (the default), an encrypted backup, or
  plaintext with an explicit warning
• Clipboard copies omit credentials by default, and note that clipboard history
  tools may retain anything you do copy
• Duplicating a profile offers configuration only (the default), reusing the
  same stored secret, or creating an independent one
• Deleting a profile never removes a credential another profile still uses;
  genuinely unused ones are cleaned up
• Imports detect omitted, plaintext, and encrypted-backup credentials, never
  activate plaintext ones silently, and re-check host restrictions

Changed

• Interface icons are now inline SVG. Emoji picked up the system colour
  font and rendered differently on every platform
• Security moved out of the section tabs into a dedicated settings view
  reached from the title bar. It is app-level configuration, not per-profile
  content, and the tab strip is for the current profile
• The popup is wider, 700px instead of 620px, so all six section tabs show
  their full labels
• Profiles now reference credentials by identifier rather than storing the
  value inline, so a shared credential exists once rather than being copied
• Storage schema is version 3. Version 2 files still import correctly
• Unlocking caches only the derived key. Credentials are decrypted on demand
  rather than written to session storage as a readable set

Fixed

• Non-credential header rows displayed the text null where the credential
  control belongs
• Renaming a header to a credential-bearing name mid-edit left the plain value
  field in place, so a credential could be typed directly into the profile
• A credential-bearing header with no stored secret could be applied using
  whatever inline value it carried. It is now withheld
• Unlocking the vault did not refresh the interface until the popup was
  reopened, because a failed background notification aborted the redraw
• Section tab labels were clipped at the previous popup width

Migration

On first launch after updating, any credentials stored inline are detected and
you are asked to choose a storage mode, including staying on persistent
plaintext. Old Chromium dynamic rules holding credentials are removed at the
same time so a stale rule cannot stay active beside a new one. The migration is
idempotent and safely resumes if interrupted. Profile names, filters,
exclusions, ordering, enabled state, redirects and non-sensitive headers are
preserved exactly.

Known limitations

• Encryption protects credentials at rest. While the vault is unlocked the
  key is necessarily in memory, so anything running with that level of access
  can read them. Host restrictions are the protection that still applies in
  that case. See SECURITY.md
• On Chromium a missing credential withholds the whole sensitive rule; on
  Firefox only the protected header operation is skipped. This follows from the
  difference between declarativeNetRequest and webRequest
• Session-only and encrypted-vault modes need storage.session, present in
  Chrome 102+ and Firefox 115+. If it is unavailable the extension fails closed
  rather than storing a credential persistently

---

v1.1.0

[1.1.0] — 2026-07-31

Feature-parity release. Adds cookie editing, a Content-Security-Policy editor, URL redirects, and tab/window scoping. No new permissions were requested.

Added

Cookie editor

• Edit individual cookies instead of hand-writing the whole header
• Request cookies compose the Cookie header; response cookies become Set-Cookie
• Full attribute control on response cookies: Path, Domain, Max-Age, SameSite, Secure, HttpOnly
• Per-profile choice between merging with the browser's existing cookies and replacing them outright

Content-Security-Policy editor

• Three modes: leave CSP alone, strip it entirely, or replace it with a policy you compose
• Build a policy one directive at a time, with autocomplete for the standard directive names
• Live preview of the exact header that will be sent
• Toggle between enforcing and Report-Only

Redirects

• Send matching requests somewhere else — useful for pointing a CDN asset at localhost
• Match by substring or by regex, with \1 capture-group substitution in the target
• Loop protection: a redirect that resolves to the request's own URL is skipped

Filtering

• Tab and Window filters, each with a Use current button that fills in the id for you
• Exclude URL containing and Exclude URL regex, to carve exceptions out of a match

Interface

• Comments on header and redirect rows, as notes to yourself
• Undo with Ctrl+Z or the toolbar arrow, up to 40 steps
• Profile search, shown once you have more than five profiles
• Autocomplete for common request headers, response headers, and CSP directives
• A profile on/off switch in the profile menu
• Six sections, each with its own accent colour

Changed

• The badge and status bar now count rules rather than headers, so cookies and redirects are included in the total
• Export format is now version 2. Files exported by 1.0.0 still import correctly
• Chrome: profiles that filter by tab or window compile to session rules, because tabIds is only supported there. Everything else stays in dynamic rules and still survives a browser restart
• Chrome: minimum_chrome_version raised from 108 to 111

Fixed

• Chrome: the manifest declared a minimum of Chrome 108 while the interface actually required Chrome 111 for CSS color-mix(). On 108–110 the extension installed and worked, but the site-access banner rendered without its background colour
• Firefox: the manifest now declares data_collection_permissions: { required: ["none"] }, which recent AMO validation requires. OpenModHeader collects and transmits nothing, so none is the accurate declaration

Known platform differences

Two behaviours differ between the builds, both because Chrome's declarativeNetRequest cannot read a request before deciding what to do with it, while Firefox's webRequest can:

	Chrome	Firefox
Request cookie merge	Appended, so a duplicate name is sent twice	True merge; a same-name cookie is overwritten
Exclude URL filters	Suppress every profile's rules for that request	Scoped to the profile that defines them

On Chrome, use Replace all cookies instead of merge if a duplicate would confuse your server.

Tab ids do not survive a browser restart on either platform, so a tab-scoped profile needs its id re-captured with Use current afterwards.

v1.0.0

Version 1 of OpenModHeader. Follow README.md for instructions on how to install.