Your data, protected.

What IHAB stores — and what it doesn't.

IHAB is a budgeting tool that works with data you enter. It is not a bank, does not process payments, and does not access your financial accounts by default. Here's a clear breakdown of what lives in your IHAB account.

Encryption and hashing.

Per-user data isolation.

Every IHAB user's data is stored in a dedicated Firestore document. There is no shared state between users. Your expenses, scheduled set-asides, income data, and budget configurations exist in a single document that only your authenticated session can read or write.

Firestore security rules enforce that a user can only access their own document. There is no admin endpoint that reads across user documents. The API authenticates every request against your Firebase Auth session or your hashed API key before accessing your data.

This is a simple isolation model, and that's deliberate. Per-user document isolation means there's no query path that could accidentally return another user's data. Your budget is your document, and nothing else touches it.

Authentication.

IHAB uses Google SSO via Firebase Authentication. When you sign in, Firebase handles the OAuth flow with Google. IHAB receives your email address and display name. No passwords are created, stored, or managed by IHAB.

Your session is maintained by Firebase Auth tokens, which are short-lived and automatically refreshed. API access uses separately generated API keys that are hashed at rest (see above).

There is currently one sign-in method: Google SSO. This means your IHAB account is as secure as your Google account. We recommend enabling two-factor authentication on your Google account if you haven't already.

API protection.

Rate Limiting

IHAB enforces per-IP and per-user rate limits on all API endpoints. Requests that exceed the limit receive a 429 (Too Many Requests) response. Limits are set conservatively to prevent abuse while allowing normal usage patterns — including automated integrations like Sequence.

CORS Restrictions

Browser-based API requests are restricted to the ihab.io origin via CORS policy. Requests from other origins are rejected at the preflight stage. API key-based access (e.g., from Sequence or custom scripts) is not subject to CORS since it originates from server-side contexts, not browsers.

GDPR compliance.

IHAB is built with GDPR compliance from the start, not retrofitted. Data export is a built-in feature, not a support ticket. Here are your rights and how IHAB supports them.

• Right to access
  You can view all of your data within the IHAB app at any time. Every expense, scheduled set-aside, income configuration, and budget override you've entered is visible in your dashboard.
• Right to data portability
  IHAB includes a built-in data export feature. You can export all of your data in a structured, machine-readable format directly from the app. No support request needed.
• Right to erasure
  You can delete your account and all associated data. When you request deletion, your Firestore document — containing all of your budget data — is removed. There is no soft-delete or retention period for user budget data.
• Right to rectification
  All of your data is editable through the IHAB interface. You can modify any expense, set-aside, or configuration at any time.
• Right to restrict processing
  IHAB processes your data only to provide the budgeting service. There is no analytics profiling, no data selling, and no third-party data sharing beyond the service providers required to operate (Firebase for auth/storage, Stripe for billing if you subscribe to Premium, Plaid for bank linking if you opt in).

What IHAB does not access.

IHAB is a budgeting tool that works with data you enter manually. It is not a financial aggregator. It does not scrape bank websites. It does not read your transaction feed. Here is what IHAB explicitly does not do:

• No bank account access by default. IHAB works entirely with numbers you type in. You tell it your income amount, your rent, your subscriptions. It doesn't pull these from your bank.
• No spending transaction imports. IHAB does not import, categorize, or analyze your spending. It allocates your income forward — it doesn't look backward at what you spent.
• No direct bank balance reads. IHAB does not connect directly to your bank accounts. If you use Sequence integration, IHAB reads balance data from Sequence — the amounts Sequence tracks after executing transfers — to show goal progress. IHAB never talks to your bank directly.
• No credit score or credit report access. IHAB does not pull credit data from any bureau.
• Plaid is opt-in and not yet active on the frontend. The Plaid integration exists on the backend for future bank linking. It is not active in the current product. If and when bank linking is enabled, it will be an explicit opt-in — IHAB will never connect to your bank without your direct authorization.

If you're evaluating whether IHAB is safe to try: the worst case is that it knows your rent is $1,400 and you want to save $200/month for a vacation. That's the scope of data we're talking about.

Testing.

IHAB has 953+ automated tests covering budget calculations, set-aside allocation logic, API endpoints, and UI interactions. The test suite runs on every code change. The current test baseline is zero failures.

Security measures are not manual checklists — they're implemented in code and verified by tests. API key hashing, rate limiting behavior, CORS enforcement, and authentication checks are all covered by automated test cases. If a code change breaks a security behavior, the test suite catches it before deployment.

The testing framework is Vitest with Testing Library for UI components. Tests cover unit logic (calculation engines), integration paths (API request-to-response), and component behavior (user interactions in the UI).