Reporting a vulnerability
Please do not open a public issue or post publicly. A public report gives attackers a head start on every site running the SDK before a fix ships.
Email browsonic-security@smartiobilisim.com with the subject prefix [browsonic security]. This is the only private channel today.
Include:
- What the issue is and the impact you believe it has.
- A minimal reproduction — an HTML page, a snippet, or a proof of concept.
- The SDK version and the browser you saw it in.
- Any mitigation or workaround you have already found.
What to expect
| Step | Target |
|---|---|
| Acknowledgement of receipt | within 3 business days |
| Initial assessment and severity rating | within 7 business days |
| Fix merged | by severity; critical issues are prioritised |
| Patched version on npm | with the next release |
| Public advisory | after the fix has landed |
These are targets, not guarantees. Critical issues get out-of-hours attention; routine ones will not. Saying so here is more useful than a promise that quietly does not hold at 2am on a Sunday.
Scope
In scope
- The browser SDK (
@browsonic/sdk) and the seven framework adapters. These run inside your users' browsers. - The published
dist/output of those packages — each declaresfiles: ["dist"], so that is the entirety of what reaches npm. - The release pipeline that builds and publishes them.
- The hosted platform: ingest, the dashboard, and the billing surfaces.
Out of scope
- Vulnerabilities in your own application caused by misusing the SDK — for example, putting personal data into
appKey. - Issues that need an attacker to already control the page the SDK is loaded on. The SDK trusts its own host by design; if that is compromised, it is not the SDK's boundary that failed.
Release provenance
Packages published from @browsonic/sdk 3.21.0 onwards carry no npm provenance attestation. Every package.json setspublishConfig.provenance: true, but npm rejects a provenance bundle whose source repository is not public, so those releases publish without one. 3.19.0 and earlier were cut from a public repository and do carry provenance.
What that means for you: npm audit signatures will report these versions as having a registry signature but no provenance, and there is no transparency-log entry tying the tarball to a commit and a workflow run. Treat them as you would any unattested dependency — pin the version, check the integrity hash in your lockfile, and diff dist/ against a build of the matching tag if you need stronger assurance.
We would rather write this down than let you discover it from a tooling warning. Provenance returns on its own if the repository becomes public again.
Coordinated disclosure
A fix lands first, then a public advisory. The advisory names the fixing commit, and names an npm version only once one has actually been published — it will not point at a version that does not exist. Reporters are credited unless they would rather not be.
Thank you for helping keep the SDK and the people using it safe.