Find a security bug. Get paid for it.

In scope

Anything a signed-in user can reach, and the pieces behind it:

• The web app at www.myaifin.app, including everything under /app.
• The edge functions the app calls on qvmgeoeigwztyrzayykn.supabase.co/functions/v1/.
• The database's access rules: reading or changing another household's rows is exactly what this program exists for.
• The assistant connector at www.myaifin.app/mcp, its OAuth endpoints, and personal access tokens.
• The iOS and Android apps.
• Sign-in, two-factor authentication, password reset, account recovery and household invitations.

What we care about most

• Reading or changing another user's or another household's financial data.
• Taking over an account, or getting past two-factor authentication.
• Getting hold of a bank connection token, or acting on someone else's bank connection.
• Calling an edge function or the assistant connector as someone you aren't.
• Stored cross-site scripting, server-side request forgery, or code execution on anything in scope.

Out of scope

These aren't eligible for a reward. Some are real problems for someone else; report those to that someone.

• The infrastructure of Plaid, Supabase, Vercel, Google or Apple. Report those to their own programs.
• Denial of service, load testing, or anything that degrades the app for other people.
• Social engineering, phishing, or physical attacks against users or anyone who works on the app.
• Findings from automated scanners without a working proof of impact.
• Missing security headers, cookie flags, or email records (SPF, DKIM, DMARC) with no demonstrated impact.
• Clickjacking on pages with no sensitive action, self-XSS, and logout CSRF.
• Rate limits on endpoints that don't guard a secret or cost money.
• Version numbers, stack traces, or outdated libraries without a way to exploit them.
• Anything that needs a rooted or jailbroken phone, or someone else's unlocked device in your hand.

Known and accepted

We've looked at each of these, more than once, and they're by design. Reports of them get a short reply pointing here and no reward.

The Supabase API key in the app

The publishable key ships in every copy of the web and mobile apps on purpose. It names the project; it doesn't sign anyone in. What protects data is the user's own sign-in token and the database's row-level security.

Access-Control-Allow-Origin on supabase.co

Supabase's API reflects the requesting origin, with Allow-Credentials. The app never signs in with cookies: the token travels in the Authorization header, which a browser does not add for another site, so a page on another origin can't make a signed-in request for a visitor.

Your own account, read with your own token

Endpoints such as /auth/v1/user return the signed-in account's own email, ID and sign-in details. A finding that needs someone's access token to begin with, and then does only what that session could already do, is not a vulnerability.

Table and column names in API errors

The database schema isn't secret. Access is decided by row-level security on every table, not by keeping names hidden.

'unsafe-inline' for styles

The Content Security Policy allows inline styles, which the interface components need. Inline scripts are not allowed.

Rules of engagement

• Test only against accounts you created. To test household isolation, make two free accounts and try to cross from one to the other.
• If you see data that isn't yours, stop. Don't keep it, change it, or look further; say what you saw in your report.
• Don't connect anyone's bank but your own, and don't disconnect or disturb other people's connections.
• Keep automated traffic low. Nothing that would slow the app down for real households.
• One vulnerability per report, unless several only matter together.
• Keep it private until it's fixed, or for 90 days after you report it, whichever comes first. We can agree on a different date.
• Asking for payment before you'll share the details is extortion, not research, and ends the conversation.

Rewards

Amounts aren't published. Each valid report is paid according to its real-world impact, how much of that impact you demonstrated, and how clear the report is. A short, reproducible report of a critical bug earns more than a long one about a minor one.

• The first report of an issue gets the reward. Later duplicates get thanks.
• Rewards are paid once the issue is confirmed, by a method we agree on.
• You're responsible for any tax on a reward. We can't pay where the law forbids it, including to people on sanctions lists.

What happens next

1. 1

   Acknowledged

   A reply within a few business days confirming we have your report.

2. 2

   Assessed

   We reproduce it and tell you the severity we've given it, usually within two weeks.

3. 3

   Fixed

   We fix it and let you know, so you can check the fix if you'd like.

4. 4

   Paid

   The reward is paid.

Safe harbor