Sorolens takes the security of its API, indexer, dashboard, CLI, and on-chain contracts seriously. This document explains how to report a vulnerability, what to expect from us in return, and how coordinated disclosure works.

• Supported versions
• Authentication trust model
• Reporting a vulnerability
• What to include in your report
• Response timeline (SLA)
• Coordinated disclosure
• Researcher and maintainer responsibilities
• Bounty program
• Scope
• Questions

Only the latest release receives security fixes. If you are running an older version, please upgrade before reporting.

Caller identity is derived only from a credential the API can verify:

• Session tokens. POST /api/v1/auth/session mints an HMAC-SHA256-signed bearer token (sls_...) bound to a server-created user. Tokens are stateless and expire at the returned expires_at. Set IDENTITY_SIGNING_KEY to a stable secret in production; otherwise the API generates an ephemeral key at boot and sessions are invalidated by a restart.
• API keys. Keys are stored as SHA-256 hashes and carry scopes. A key may be bound to a user (user_id); a bound key acts as that user and inherits their role. Unbound keys authenticate scopes only. An admin:* key satisfies admin role checks so an operator can bootstrap and rotate keys.
• Trusted reverse proxy. Only when TRUSTED_IDENTITY_PROXY_SECRET is set, the API accepts X-Identity-User-ID, X-Identity-Timestamp and X-Identity-Signature (HMAC-SHA256 over method, request URI, user ID and timestamp). Signatures older than five minutes are rejected. Never expose these headers to untrusted clients; terminate them at the proxy.

The API ignores bare X-User-ID, X-GitHub-Login, X-User-Sub and X-GitHub-ID headers. They confer no identity, role or scope, and forwarding them cannot escalate privileges (issue #518). Routes that require a user (for example watchlists, groups and notes) return 401 without a verified session or user-bound key.

If you believe you have found a security vulnerability in Sorolens, please report it by email:

security@sorolens.dev

Do not open a public GitHub issue for security vulnerabilities. Public disclosure before a fix is available puts all users of the project at risk.

Email is currently the only confidential reporting channel: GitHub private vulnerability reporting is not enabled for this repository.

• A description of the vulnerability and the component it affects (API, indexer, dashboard, CLI, XDR decoder, or fixture contract).
• Steps to reproduce the issue, including any relevant contract IDs, network (testnet or mainnet), or request payloads.
• Your assessment of the potential impact.
• Whether you have already developed a proof of concept (you do not need to share exploit code, a description is sufficient).

If a fix requires more time, we will communicate that before the 90-day mark and agree on an extended timeline with you.

We follow a coordinated disclosure model:

1. Report privately. Send the details to security@sorolens.dev instead of opening a public issue.
2. Acknowledge and triage. We confirm receipt within 48 hours and share a preliminary assessment within 7 days.
3. Fix and agree a date. We develop and test a fix and agree a disclosure date with you. Our target is 90 days from the initial report.
4. Publish. We release the fix and publish the disclosure (with a CVE where applicable) once the fix is available.
5. Credit. We credit you by name (or by handle if you prefer) in the release notes unless you ask to remain anonymous.

We ask that you do not disclose the vulnerability publicly before the 90-day window has elapsed or before we have published a fix, whichever comes first.

Researchers:

• Report privately and give us a reasonable opportunity to fix the issue before any public disclosure.
• Avoid privacy violations, data destruction, and service disruption while testing.
• Only interact with accounts, data, and systems you own or have explicit permission to test.

Maintainers:

• Acknowledge reports within 48 hours and keep the reporter informed of progress.
• Confirm the affected versions, the severity, and the remediation.
• Credit the reporter in the release notes unless they ask to remain anonymous.

There is no bug bounty program at this time.

This policy covers:

• The Sorolens API (apps/api)
• The Sorolens indexer (services/indexer)
• The Sorolens CLI (cli/)
• The XDR decoder package (packages/xdr)
• The Sorolens dashboard (apps/web)
• The fixture contract (contracts/counter) when deployed to testnet or mainnet

Out of scope:

• Vulnerabilities in third-party dependencies (please report those to the upstream project). You are welcome to notify us as well so we can track the upstream fix.
• The Stellar network or Soroban protocol itself.
• Infrastructure operated by Neon, Upstash, or Vercel.

For anything unclear about this policy, email security@sorolens.dev.