Security Policy | BayanSheet

BayanSheet handles bank-statement data, so we take security reports seriously and we would rather hear from you than not. Thank you for taking the time.

BayanSheet is built and run by one person. We are saying so up front so you can calibrate. The windows below are deliberately longer than a larger team would quote, because we would rather give you a date we can keep than a fast one we cannot. If we are going to miss one, we will tell you before it passes rather than after.

Reporting a vulnerability

Email support@bayansheet.com with SECURITY in the subject line. Please include:

What the issue is and which part of the system it affects — a URL, an endpoint, a page.
Steps to reproduce it. This is the single most useful thing you can send. A report we can reproduce gets fixed; one we cannot usually stalls.
What an attacker could actually do with it.
Any proof of concept, request/response capture, or screenshot.

Please do not open a public issue or disclose it publicly before we have had a chance to fix it. A quiet report gives us time to protect users; a public one gives everyone else the exploit first. If you would like to encrypt your report, say so in a first email and we will arrange it.

What we commit to

Acknowledge your report within 5 business days.
Assess it within 15 business days and tell you whether we consider it valid, with our reasoning.
Fix critical issues as fast as we possibly can. This is a one-person team, but a critical issue takes priority over everything else, including shipping features.
Keep you updated as we work on it, rather than going silent after the acknowledgement.
Credit you in the fix or the release notes if you would like to be named — tell us how. Staying anonymous is equally fine.
Tell you when it is fixed, so you can verify it yourself.

We are a small independent product and do not currently run a paid bug-bounty programme. We can offer credit, thanks, and a genuinely fast response.

Scope

In scope: bayansheet.com — the live site, including the converter, the account area, the API routes under /api/, and the admin console.

Out of scope:

Volumetric denial of service — load testing, traffic floods, resource exhaustion. Please do not run these against the live site; they affect real customers and tell us nothing we can act on.
Automated scanner output with no demonstrated impact — a raw report of missing headers or a version banner, with no explanation of what an attacker could achieve. We are glad to look at scanner findings you have investigated and can show impact for.
Social engineering of us, our customers or our vendors. No phishing, and no attempts to access accounts that are not yours.
Findings requiring a compromised device, a malicious browser extension, or physical access to a user's machine.
Reports about our email SPF/DKIM/DMARC configuration unless you can demonstrate a practical spoofing attack.

Please stay within the rules of the road: test only against your own accounts, do not access or modify other people's data, and stop and report as soon as you have confirmed a vulnerability rather than exploring how far it goes. Act in good faith and we will too.

What data actually exists here

Bank statements are converted entirely inside the user's browser and are never uploaded to us. The PDF is read into the tab's memory, parsed by JavaScript on the user's own device, and the Excel or CSV file is generated locally. No statement, no transaction and no filename is transmitted to a server we operate by any code path in the app.

This is verifiable, and we would rather you checked than took our word for it: disconnect from the internet after the page loads and convert a file — it still works. Or watch the Network tab during a conversion.

A correction we are making before you find it, because this document previously overstated one thing. It used to say our Content-Security-Policy connect-src allowed no host that could receive an upload. That is not accurate: it includes https://*.supabase.co, a wildcard, so in principle any Supabase project — including one an attacker creates — is a permitted destination. No code in the app sends statement data anywhere, and that is the claim we stand behind; but the CSP is not the control that would stop it, and presenting it as one was wrong. Fixed on 5 August 2026: connect-src is now narrowed at build time to this project's single Supabase origin, derived from the same variable the app itself uses so the two cannot drift apart. Reports about this are welcome and in scope, and you will not be told it is a known non-issue. We are leaving the admission above in place rather than quietly deleting it — a policy that only ever shows you its wins is not worth reading.

The practical consequence for your research: there is no server-side store of statement data to disclose, because none exists. No database table holds it, no log contains it, no backup includes it. A full compromise of our infrastructure would not, by design, give an attacker access to converted statement data — because we hold none.

The one exception, and we would rather tell you than have you find it: a statement someone chooses to email us. We invite this — the site offers a "send us a sample and we will tune the parser" contact link — and an emailed sample is a normal attachment in a normal inbox, covered by our Privacy Policy, not by the in-browser architecture above. It never travels through the app, and nothing in the app ever sends a file for anyone. But it is real data in a real mailbox, so treat our support inbox as in scope for what it is: an email account.

Where the interesting findings live. Our server-side surface is accounts (email addresses, hashed passwords, authentication and sessions), billing (subscription and credit state, and the webhook that receives payment events — card data is never ours, as Paddle is the merchant of record), and the admin console (access control and internal management routes). Findings in those three areas are the ones we most want to hear about.