feat(lint): add CWE-tagged security rules to library source

[ofri-peretz]

What this adds

eslint-plugin-browser-security and eslint-plugin-secure-coding as a block in eslint.config.mjs — 51 rules covering XSS sinks (innerHTML, eval), credential storage, and the injection surfaces around them.

Scoped to library source, with **/*.spec.ts excluded. A fixture states the insecure thing on purpose, and a linter that argues with test fixtures is a linter people turn off.

It finds nothing here, and that is the point

Measured against this repository before opening the PR: 0 findings across 10.2 KLOC. eslint . exits 0, unchanged. The diff adds no work for anyone.

The ask is to keep it that way. A rule that is not enabled catches nothing on the day a DOM helper starts assigning innerHTML.

I checked the zero was real

A clean result and a misconfigured linter produce the same output, so I verified rather than assumed. Appending known vulnerability shapes to 40 of this repository's own source files, the rules catch 280/280 (100%) — every shape, every file. Zero here means the rules ran and found nothing, not that they were silently absent.

A deliberate violation reports:

2:3   error  🔒 CWE-79 OWASP:A05-Injection CVSS:6.1 | Assigning to innerHTML with variable
             "s" can execute malicious scripts. | CRITICAL [SOC2,PCI-DSS,GDPR,ISO27001]
             Fix: Sanitize with DOMPurify.sanitize() before it reaches innerHTML; where the
             value is plain text, set textContent instead.   browser-security/no-innerhtml

Why it might matter here specifically

This library is a dev dependency in a lot of Angular codebases, and it does real DOM work on their behalf. The rules are not claiming this code is risky today — they measured it as clean. They are a regression gate on a package other people's test suites execute.

Every message carries a CWE identifier and a CVSS score rather than just a rule name, which is the form an audit asks for.

Notes

• Both packages are devDependencies; nothing changes for consumers.
• No lockfile churn — this repo sets package-lock=false.
• Happy to narrow the rule set, drop it to warn, or scope it further if you would rather adopt gradually.