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 do not.
Scope
In scope
- The browser SDK (
@browsonic/sdk) and the seven framework adapters. They run in your users' browsers; a few adapter helpers also run on your server, such as the Next.js route-handler wrapper. - The build-time packages
@browsonic/cliand@browsonic/build-tools, which upload source maps from your build. - The published
dist/output of those packages. Each declaresfiles: ["dist"], sodist/is the code that reaches npm. - The release process that builds and publishes them.
- The hosted platform: ingest, the console, Atlas (including its Figma plugin) and the billing pages.
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
Current releases carry no npm provenance attestation. The source repository is private, and every package.json sets publishConfig.provenance: false.
For @browsonic/sdk, only 2.2.1, 3.1.0–3.6.0, 3.21.0 and 3.21.1 carry an attestation; 2.2.0, 3.6.1–3.19.0 and 3.21.2 onward do not. The current releases of the framework adapters, @browsonic/cli and @browsonic/build-tools carry none either.
What that means for you: npm audit signatures reports these versions with a registry signature but no provenance, and there is no transparency-log entry tying a tarball to a commit and a build. Treat them as you would any unattested dependency: pin the version and check the integrity hash (sha512-…) in your lockfile.
Coordinated disclosure
A fix lands first, then a public advisory. The advisory names the npm version that contains the fix once that version is 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.