The HTTP bridge's Origin allowlist previously matched by scheme only (chrome-extension://… / moz-extension://…), which any installed extension satisfies equally — not just BraveMCP's own. A malicious or compromised neighbor extension could talk to /api/capture, /api/note, /api/stage-groups, etc. exactly as freely as the real extension. This is the same "unauthenticated internal channel trusts any sender" gap disclosed in Claude for Chrome's extension-messaging vulnerability (2026-07), applied to a directly comparable architecture.
Security
- Extension-origin pinning (trust-on-first-use): pins the specific extension origin seen on first contact (
storage/trusted-origin.json, git-ignored) and rejects every other extension-shaped origin afterward — zero configuration required. See the Security section in the README for the re-pinning steps if you ever move the repo to a new path.
Testing
- 7 new tests covering the pinning decision logic and persistence; 35 tests passing (was 28). Verified end-to-end against a live server with curl: first extension origin is trusted and pinned, survives a server restart, and a second/different extension origin gets 403 even though it passes the scheme check.
Full changelog: CHANGELOG.md