Security & Responsible Disclosure

Inboard takes the security of its platform and the data customers entrust to it seriously. This page describes how to report a vulnerability, what we will do when you do, and the boundaries of our safe-harbour commitment to good-faith researchers.

The machine-readable equivalent of this document lives at /.well-known/security.txt per RFC 9116.

1. How to report

• Email security@inboard.dev with a description, reproduction steps, and any supporting material (screenshots, request captures, proof-of-concept).
• Encrypt anything sensitive with our PGP key — published at the same address once minted; until then, prefer reproduction-step prose over raw payloads in the clear.
• Please do not open public GitLab issues, post on social media, or contact individual employees about a suspected vulnerability before we have had a chance to respond.

2. What we will do

• Acknowledge your report within 24 hours (business days; we'll respond on weekends for issues marked critical).
• Triage and assign severity within 5 business days.
• Fix critical-severity issues within 30 days; lower severities on a best-effort basis coordinated with you.
• Credit you in our disclosures unless you ask us not to. With your consent, we'll add you to the hall of fame at the bottom of this page once the issue is fixed.

3. Scope

In scope

• inboard.dev and its subdomains (marketing, app, documentation).
• api.inboard.dev — the public REST API and the embedded-widget endpoints it serves.
• The published widget script and any installable plugins we ship.
• Authentication, authorisation, and tenant-isolation boundaries (e.g. one customer reading another's data).
• Cryptographic correctness of features we ship — signature verification, hash chains, rate-limit bypasses. The active and historical Ed25519 public keys are published at api.inboard.dev/.well-known/inboard-signing-keys.json for offline verification.

Out of scope

• Denial-of-service via volumetric load. If you find an algorithmic DoS (e.g. a single request that pegs CPU), that is in scope; please describe rather than execute.
• Social engineering of Inboard staff or customers, physical attacks, and attacks against third-party services we depend on (Stripe, Supabase, Vercel, GitLab, our DNS provider). Report those upstream.
• Reports based purely on automated scanner output without a demonstrated impact (e.g. missing security headers on pages that don't handle credentials, version disclosure, theoretical TLS downgrades on hosts that don't carry sensitive data).
• Self-XSS, clickjacking on pages without sensitive actions, and findings that require an already-compromised victim device.
• End-of-life browsers and platforms outside our published support matrix.

4. Safe harbour

We will not pursue legal action against, nor support law-enforcement action against, researchers who:

• Make a good-faith effort to comply with this policy and avoid privacy violations, service disruption, and data destruction.
• Limit their testing to in-scope assets and stop as soon as they have enough information to demonstrate the issue.
• Do not access, modify, or retain data that is not their own beyond the minimum needed to demonstrate the vulnerability — and notify us if they incidentally encounter such data.
• Give us a reasonable opportunity to remediate before public disclosure (we suggest 90 days; we are happy to coordinate a longer window for complex issues).

This safe harbour applies to research conducted under this policy. It does not waive any third party's rights. If your research touches a service operated by one of our sub-processors (see Privacy Policy), their terms apply to that portion of your work.

5. Bug bounty

At launch we operate a private bug bounty program by invitation. Reward bands are graded by impact:

• Critical — remote code execution, full authentication bypass, cross-tenant data access. Reward in the mid-four-figure range.
• High — privilege escalation, signed-payload forgery, sensitive-data exposure scoped to a single tenant. Reward in the four-figure range.
• Medium — authenticated information disclosure, stored XSS in admin surfaces, billing manipulation. Three-figure range.
• Low — reflected XSS without elevated impact, missing rate-limits with a demonstrable user-visible effect. Token rewards and hall-of-fame credit.

Reports outside the private program are still welcome via security@inboard.dev and remain eligible for credit and discretionary rewards.

6. Hall of fame

Names listed here have responsibly disclosed issues that improved Inboard's security posture. With your permission we'll add yours alongside them.

None yet — be the first.

7. Updates

Material changes to this policy are reflected in the Last updated date at the top of the page. Researchers who have submitted reports in the prior 12 months will be notified by email. We do not retroactively narrow scope or weaken safe-harbour.