Security
You are being asked to upload a bank statement, which is a reasonable thing to hesitate over. This page is what happens to it — specific enough to check, and honest about what has not been done.
The whole argument, in one line
Nixpense cannot leak your banking password, because it never had one.
Apps that connect to your bank hold a credential, or a token that behaves like one. Whatever they promise about protecting it, the thing exists and is worth stealing. Nixpense has no aggregator, no read-only banking API and no credential store — not as a policy that could be relaxed later, but because there is no such code in the product. It reads documents you hand it. That is the entire attack surface.
Row-level security is enabled on all ten user tables, each with a policy scoping rows to your own user id. The database evaluates that on every row of every query, whatever the client asks for. It is the database enforcing it, not the application remembering to.
Retained documents live in a private bucket under your user id, with storage policies matching that path segment to your session. There are no public URLs. When you open one, the app issues a signed link that lasts sixty seconds and works only for you.
It lives in an httpOnly cookie, so JavaScript on the page cannot read it at all — which is what stops a cross-site scripting bug from turning into a stolen session.
Signed-out requests to the app are turned away before rendering, by a check that verifies the session against the auth server rather than trusting a cookie it can decode. If that gate were bypassed entirely, row-level security would still return nothing.
A content-security policy allowlists the only three origins the page may talk to: itself, the database, and the contact endpoint. A script injected onto the page could not send your figures to an arbitrary host.
No analytics, no tag manager, no ad pixel, no session recorder. Not configured to be private — simply absent. The only cookie set is the one that keeps you signed in.
You can, and you are meant to. That is the anon key, and it ships in the client bundle of every app built on this database, including the vendor’s own examples. It identifies the project, not a person.
On its own it can read nothing. Paste it into a console and ask for someone else’s data and you get an empty set, because the protection is row-level security in the database, not secrecy of the key.
The key that would matter is the service-role key, which bypasses those rules. It is used in exactly one place — removing your login when you delete your account — it is read only in server code, it is deliberately named without the prefix that would let it be sent to a browser, and the built client bundle has been scanned to confirm neither it nor the string service_role appears anywhere in it.
Nixpense is a small project under active development, and the honest version of a security page says so. There is no SOC 2 report, no external penetration test and no compliance certification, and you should treat any of those words on a site like this one with suspicion unless there is an auditor’s name attached.
What there is instead: a threat model written down in the open, an architecture where the most valuable thing to steal was never collected, and a way out. You can export everything you have — every record, including the original PDFs — as a single file built in your own browser, and delete the account entirely, without asking anyone.
Found something?
Security reports are read first.
Good-faith research is welcome, and the safe harbour in the Terms covers it. Send findings through the contact page or straight to the address below — please include enough detail to reproduce, and give a reasonable window before publishing.
feedback@nixpense.comMachine-readable at /.well-known/security.txt.
Free while in development
No card, no bank login · Export or delete everything, whenever you like