Security

Last updated: April 2026

Your financial data is one of the most sensitive categories of information you will ever entrust to software. Folko is built accordingly: encrypted in transit, encrypted at rest, isolated at the database level, and never sold to anyone.

1. Data in transit

All connections between your device and Folko's servers are encrypted with TLS. HTTP is not supported — the folko.io domain enforces HTTPS via a 2-year HSTS preload directive, and the mobile app only talks to Supabase over TLS.

2. Data at rest

Your cashbooks, transactions, and members are stored on Supabase cloud infrastructure with encryption at rest. On your device, local data lives in encrypted SQLite and MMKV storage, protected by the operating system's data-protection APIs (iOS Keychain / Android Keystore).

3. Account isolation

Every table in our database is protected by Row Level Security (RLS) policies. The policies are enforced at the Postgres layer itself, not in application code — meaning even a bug in Folko's API cannot let one user read another user's data. The only cross-user access allowed is between co-members of the same cashbook, and only for that cashbook's contents.

Privileged database functions run with fixed search_path and validate the calling user's identity before returning any data. The service-role key that can bypass RLS is never exposed to the client — it is used exclusively inside server-side edge functions.

4. Web security headers

The folko.io website ships with a restrictive set of HTTP security headers on every response:

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload — 2-year HSTS with preload.
• Content-Security-Policy: default-src 'none' baseline; only explicitly allowlisted CDNs can load scripts, styles, or fonts.
• X-Frame-Options: DENY — the site cannot be embedded in an iframe, blocking clickjacking.
• X-Content-Type-Options: nosniff — browsers will not second-guess MIME types.
• Referrer-Policy: strict-origin-when-cross-origin — outbound links do not leak the full URL you came from.
• Permissions-Policy: camera, microphone, geolocation, and payment APIs are disabled site-wide.
• Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy: same-origin — cross-origin windows cannot inspect Folko, and Folko's resources cannot be loaded by arbitrary cross-origin documents.

5. Code and operational security

We follow industry-standard secure-development practices:

• Every release goes through an adversarial audit — we actively try to break our own code from the perspective of an attacker with a valid user session, looking for RLS bypasses, privilege escalation, injection, and session hijacking.
• Edge functions validate every input with strict schemas and reject malformed requests before touching the database.
• CORS is restrictive on all edge functions — no wildcard origins.
• Dependencies are reviewed regularly for known vulnerabilities. We remove rather than patch packages with unresolved security issues (we replaced the xlsx library with exceljs for exactly this reason).
• Secrets, service-role keys, and signing credentials live only in server-side environments — never in client bundles, never in the repository.

6. What Folko does not do

• We do not sell your data. Ever. To anyone.
• We do not share your data with advertisers, data brokers, or analytics companies.
• We do not run third-party advertising SDKs, behavioral-tracking pixels, or fingerprinting scripts.
• We do not read your financial data. Folko's staff has no business reason to look at your transactions, and the production database does not grant them ad-hoc access.
• We do not handle your money. Payment rails (PIX, UPI, Venmo, PayPal, and the rest) are deep links only — Folko never holds, transfers, or sees your funds.

7. Breach notification

If we discover a security breach that affects your personal data, we will notify affected users by email without undue delay and publish a public incident report at folko.io/security describing what happened, what data was affected, and the steps we took to contain and remediate it. We will not quietly patch and move on.

8. Reporting a vulnerability

If you believe you have found a security issue in Folko — in the app, the website, or the backend — please email hello@folko.io with the subject line "Security" and as much detail as you can share (reproduction steps, affected endpoints, screenshots). We will acknowledge receipt within 72 hours and keep you updated as we investigate.

We ask that you do not publicly disclose the issue until we have had a reasonable opportunity to fix it, and that you do not access, modify, or delete other users' data while testing. Researchers who follow responsible disclosure will be credited in the release notes when the fix ships, unless they prefer to remain anonymous.

9. Subprocessors

A detailed list of third-party Subprocessors we rely on, the data each receives, and their location is maintained in our Privacy Policy at folko.io/privacy (Section 3).

10. Honest limits

No system is 100% immune, and Folko is not an exception. We do not use the phrase "end-to-end encrypted" because we hold the keys to your data on the server side — anyone telling you they run a multi-device sync product with true end-to-end encryption and searchable cloud data is either using a narrow technical definition of the term or stretching the truth. What we can honestly say is this: your data is encrypted in motion and at rest, isolated from other accounts at the database level, never sold, and under constant adversarial review. If that changes, this page changes with it.