Reporting a vulnerability
Don't publish vulnerability details in a public issue. Use GitHub's private vulnerability reporting in the repository's Security tab. If that isn't available, contact the maintainer privately through a trusted channel.
Implemented controls
- The HTTP API listens on loopback (
127.0.0.1) by default and never assumes a secure public proxy. - Workspace identity comes from a high-entropy bearer key. Only its SHA-256 digest is stored in PostgreSQL.
- SQL values are parameterized, and analytics filter by workspace ID.
- Composite keys enforce tenant-scoped identity and event idempotency; advisory locks reduce concurrency conflicts.
- 256 KB JSON body limit, at most 100 records per batch, strict timestamp and numeric validation.
- The dashboard sends the key as a bearer header, avoids local storage, renders customer data with
textContent, and gets CSP and no-store headers. - A per-process, per-workspace request limiter. Revocation checks live database state.
- A basic credential scan and dependency audit run in CI.
- Optional least-privilege PostgreSQL runtime grants with CI tests. They aren't enabled by the demo and don't provide tenant RLS.
v0.3 notes
- Workspace prices are append-only, but every valid workspace key has equal pricing write access. No user RBAC is shipped.
- The dashboard is a local static bundle under
/dashboard, with self-only scripts, same-origin requests and no key storage. - Adding or superseding a price never reprices stored events.
Production blockers
- No internet-facing authorization review or penetration test, and no database RLS. A compromised database credential can read every tenant.
- No TLS terminator or reverse proxy is shipped.
- The rate limiter is in-memory only. Instances don't share quotas, and invalid-key attempts aren't throttled.
- No operational assurance: backups, restore drills, log redaction, monitoring, secret rotation or incident response.
- No data governance: deletion and export policy, retention controls or compliance review. Customer identifiers may be personal data.
- Localhost E2E tests aren't a public deployment security review.
- Credential scanning is heuristic. A clean scan doesn't prove there are no secrets or vulnerabilities.
- The price catalog is trusted workspace input, not verified against provider invoices.
Verification
| Command | What it checks |
|---|---|
npm run check | TypeScript plus unit and integration suites |
npm run test:postgres | PostgreSQL 16 concurrency and isolation on a disposable, empty database |
npm audit --audit-level=low | Known dependency advisories |
scripts/check-release-files.py | Source-file scan |
scripts/browser-smoke.py | Chromium UI smoke test against a mocked API |
scripts/live-demo-smoke.py | CI-only live demo: local API auth, SDK, PostgreSQL and Chromium. Not a penetration test. |
Go for an experimental open-source alpha: clean source, license and warnings, passing CI and a working local demo. No-go for a production internet service until the blockers above are resolved and independently evaluated.