Vulnerability Disclosure Policy
Effective date: September 13, 2026
Bao Budget is operated by NAS Innovation LLC, a Massachusetts limited liability company, 82 Wendell Ave Ste 100, Pittsfield, MA 01201.
Security reports go to security@baobudget.com.
1. Why this policy exists
1.1 Bao Budget holds people's financial data. We would much rather hear about a vulnerability from you than read about it somewhere else, and we would rather you knew in advance exactly what testing we consider acceptable than have to guess.
1.2 This document is that answer. If you test within the rules in section 3, report under section 4, and stay inside the scope in section 2, we will treat your work as authorized and we will not pursue legal action against you for it. Section 5 says what that commitment covers and — just as importantly — what it cannot.
1.3 This policy is referenced by the Acceptable Use Policy (document 09, section 8). The Acceptable Use Policy prohibits unauthorized security testing; testing conducted in compliance with this policy is authorized testing and is not a violation of it.
2. Scope
2.1 In scope
- The Bao Budget web application at
https://app.baobudget.com. - The Bao Budget iOS and Android applications.
- The Bao Budget marketing site at
https://baobudget.com. - The Bao Budget HTTP API, accessed with your own API key or access token.
2.2 Out of scope — our vendors' own systems
2.2.1 Bao Budget runs on third-party services. Their systems are not ours to authorize testing against, and this policy grants you nothing in respect of them. That includes at least:
| Vendor | Role |
|---|---|
| Quiltt | Bank-account aggregation |
| Stripe | Payments and subscriptions |
| Vercel | Application hosting |
| Neon | Database hosting |
| PostHog | Product analytics |
| Upstash | Rate limiting and caching |
2.2.2 If you find a vulnerability in a vendor's own product or infrastructure, report it to that vendor under their disclosure program. If you believe the issue is in how Bao Budget uses a vendor — a misconfiguration on our side, a leaked key of ours, a permissions mistake in our integration — that is in scope and we want to hear about it.
2.3 Out of scope — activities
None of the following is authorized by this policy, whatever else you have complied with:
(a) Anything that touches another person's account, financial data, or personal information. This is the exclusion we care about most. Bao Budget holds bank balances, transaction histories, and account connections belonging to real people who have no way to consent on your behalf. Demonstrating that a boundary can be crossed does not require crossing it against a real user, and we will not treat it as good-faith research if you do.
(b) Social engineering of our staff, our users, our vendors, or our support channels — including phishing, pretexting, vishing, smishing, and any attempt to obtain credentials from a person.
(c) Physical attacks against, or physical access attempts to, any premises, person, or device.
(d) Denial-of-service testing, stress testing, volumetric testing, or any load intended to degrade availability.
(e) Automated scanning of production — see section 3.5.
(f) Any test that destroys, corrupts, or alters data you do not own, or that degrades the service for anyone else.
(g) Testing against the accounts, infrastructure, or data of anyone other than yourself.
2.4 Findings we generally do not act on
We will read every report, but reports of the following are usually closed without a fix: missing security headers with no demonstrated impact; the output of an automated scanner with no working proof of concept; version-disclosure banners; TLS configuration findings with no exploit path; self-XSS; rate-limiting concerns without a demonstrated abuse case; social-engineering findings; and issues affecting only unsupported or heavily modified client software. Send them anyway if you think we are wrong — just expect that answer.
3. Rules of engagement
3.1 Use only your own test account. Create one, use that one. Never authenticate as, or attempt to authenticate as, anybody else.
3.2 Stop as soon as you have confirmed a vulnerability. Do not pivot deeper. Confirming that an endpoint returns a record you should not be able to reach is a finding. Enumerating the rest of the records is not additional evidence, it is additional harm.
3.3 Never access, modify, save, download, retain, or exfiltrate another user's data. Not to prove impact, not to a private repository, not temporarily.
3.4 If you encounter personal or financial data belonging to someone else, stop immediately and tell us. Do not continue testing that path, do not look further, do not keep a copy. Report what you saw in general terms — enough for us to find and fix it — and tell us what, if anything, was written to disk so we can confirm it is gone. Encountering such data by accident is not a violation of this policy; continuing after you have is.
3.5 Do not run automated scanners, fuzzers, or crawlers against production. Manual, targeted testing only. If a finding genuinely needs automation to demonstrate, email us first and describe what you want to run.
3.6 Do not degrade the service. No flooding, no deliberate resource exhaustion, no leaving persistent payloads in place. If your test creates data (a stored payload, a test record), remove it and tell us what you created.
3.7 Do not exploit a finding for gain, and do not use it to obtain anything of value beyond the proof that it exists.
3.8 Comply with applicable law. This policy authorizes testing of our systems; it does not authorize anything unlawful.
3.9 If you are unsure whether something is permitted, ask first at security@baobudget.com. We
would rather answer a question than litigate a misunderstanding.
4. How to report
4.1 Email security@baobudget.com. That address is monitored for this purpose.
4.2 Please include, as far as you can:
(a) the affected endpoint, URL, screen, or app version; (b) a clear description of the vulnerability and its class; (c) step-by-step instructions to reproduce it; (d) what an attacker could actually do with it — the impact, in plain terms; (e) any proof-of-concept code, request/response captures, or screenshots, with any third-party data redacted; (f) the test account you used; and (g) how you would like to be credited, if you want to be (section 7).
4.3 One vulnerability per email, where you can. It keeps the thread readable and the fix traceable.
4.4 Please do not disclose publicly before we have responded and had a reasonable opportunity to fix. Section 6 sets out the timeline we work to and how to raise it with us if you think it is too slow. Public disclosure before that window has run, without talking to us first, takes you outside this policy — including outside the safe harbor in section 5.
4.5 Do not report a vulnerability through a public channel: not a GitHub issue, not social media, not a support ticket. Email the security address.
4.6 If you believe user data is actively exposed right now, say so in the subject line. We will treat availability of a fix as secondary to stopping the exposure.
5. Safe harbor
5.1 If you make a good-faith effort to comply with this policy, we will consider your security research to be authorized conduct, and we will not initiate or support legal action against you in respect of it. That commitment covers, without limitation, claims under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), the Massachusetts Computer Crime statutes and other state-law analogues, the anti-circumvention provisions of the Digital Millennium Copyright Act (17 U.S.C. § 1201) where circumvention was necessary to your research, and any claim under our Terms of Service or Acceptable Use Policy arising out of the research itself.
5.2 We will not ask your employer, your university, or a platform to act against you for research conducted under this policy, and we will not report it to law enforcement as an offense.
5.3 If a third party brings an action against you for research that complied with this policy, we will make your compliance known. On your request, we will state — publicly if that is what helps, or to the court, the third party, or their counsel — that the conduct described was authorized under this policy and was conducted in good faith. That is a commitment we can actually keep, and we will keep it.
5.4 The limits of this, stated honestly:
(a) We can only speak for ourselves. We cannot waive, settle, or release claims belonging to anyone else — our users, our vendors, our hosting providers, or any other third party — and nothing here purports to.
(b) We cannot bind law enforcement or any government agency. Criminal authorities act independently of us. A statement from us that your conduct was authorized is relevant to whether an offense occurred, and we will provide it — but it is not a guarantee of the outcome.
(c) This safe harbor is conditional. It applies to conduct that complies with this policy. It does not apply to activity in section 2.3, to accessing another person's data, to extortion or a demand for payment in exchange for withholding a finding, or to public disclosure in breach of section 4.4. If your conduct falls outside the policy, we evaluate it on its own facts — the rest of this document does not become a defense retroactively.
(d) We do not authorize testing of anything not in section 2.1. In particular, this policy gives you no authorization whatsoever in respect of our vendors' systems.
5.5 If we believe you have stepped outside the policy, we will tell you what we think happened before we do anything else, and give you the chance to explain. A misjudgment made in good faith and reported promptly is not the same thing as bad faith, and we will not treat it as such.
6. What we commit to
6.1 We are a small team. The commitments below are deliberately modest so that they are ones we can actually meet. A missed commitment in a security policy costs more trust than a conservative one ever saves.
6.2 Acknowledgment: within 5 business days of your report reaching security@baobudget.com. That
is a human confirming receipt, not a triage verdict.
6.3 Initial assessment: within 15 business days — whether we can reproduce it, our severity view, and whether we intend to fix it.
6.4 Status updates: at least every 14 days while a report is open, until it is fixed or closed. If we go quiet past that, chase us; the address is the same.
6.5 Coordinated disclosure: 90 days from your report, after which you are free to publish, whether or not we have shipped a fix. The 90 days is negotiable in both directions — if a fix is straightforward we will usually ask you to hold for days rather than months, and if a fix is genuinely hard we may ask you for more time. We will ask; we will not simply let the clock run out in silence.
6.6 We will tell you when the issue is fixed, and — where you want it — coordinate the timing of your publication with ours.
6.7 We will not require you to sign a non-disclosure agreement as a condition of us reading, triaging, or fixing your report.
6.8 The response times in 6.2 and 6.3 were set by the owner on 2026-08-24 at 5 business days to acknowledge and 15 to assess — deliberately modest so they hold without an on-call rotation. They will be revisited if the team grows.
7. No bounty
7.1 This is not a paid bug bounty program. We do not offer money, credits, subscriptions, swag, or any other compensation for vulnerability reports, and submitting a report creates no expectation or obligation of payment.
7.2 We say this plainly because the alternative is worse: a program that hints at reward and then does not pay generates more ill will than one that was honest from the start. If that changes, we will say so here and the changelog will record it.
7.3 We do offer credit. With your permission, we will acknowledge you by the name or handle you choose for a valid report of a genuine issue. Tell us in your report how you would like to be credited, or that you would prefer not to be. We do not maintain a public acknowledgments page; credit is given privately, and where you agree, in the release note or fix announcement for the issue you reported.
7.4 On request, we will confirm in writing that you reported a specific issue and that you complied with this policy. Researchers use this for their own portfolios and it costs us nothing.
8. Changes to this policy
8.1 We may update this policy. The version number and effective date above change with every update, and section 9 records what changed.
8.2 The version in force when you began testing is the one that governs that testing. We will not apply a later, narrower version retroactively to research already conducted.
9. Changelog
| Version | Effective date | Change |
|---|---|---|
| 1.0 | September 13, 2026 | Initial publication. |