Casa Cabana

Security

Last updated 17 August 2026. This page describes what Casa Cabana does today. Where something is planned rather than built, it says so.

You are being asked to put your group's financial records, your insurance documents and photographs of the inside of your property into someone else's software. That deserves a straight answer about how it is protected, including the parts that are not finished.

We never handle your password

Casa Cabana has no password of its own. You sign in through Google, which means your credential is never sent to us, never stored by us, and cannot be leaked by us because we do not have it.

A practical consequence worth knowing: if you have two-factor authentication on your Google account, it already protects your Casa Cabana account. If you do not, turning it on is the single most useful thing you can do for the security of your property's records.

Email addresses are verified before an account can be used.

Access is enforced in the database, not in the interface

This is the part we would most want a technical reader to check.

Every table holding customer data has row level security enabled in Postgres. Permissions are decided by the database itself when a query runs, rather than by the application choosing what to display. The difference matters: an interface can hide a button, but a database that refuses the query cannot be talked round by a crafted request.

  • One property's data cannot be reached from another property's session. Not by changing a number in a URL, not by any route.
  • A property manager never sees a dollar figure. Not a budget, not a receipt, not a split, not a contribution, not a cost on a work order, not a comment discussing money. This is enforced at the data layer, which is why we are willing to state it this plainly.
  • Owners, finance administrators, property managers and guests each reach a different set of records, and the boundaries between them are the same mechanism.

Guests and brokers, without accounts

A guest link and a broker link both give access to a narrow slice of one property and nothing else. The link is generated once, shown to you once, and never stored anywhere it could be read back. It can be revoked immediately, and it expires.

A broker can read the annual report you shared and leave a note on it. They cannot see your calendar, your finances or your inventory.

Where your data lives

  • Supabase, hosted in Canada. Database, authentication and file storage.
  • Vercel, hosted in Canada. Application hosting.
  • Stripe. Payments. Card numbers go directly to Stripe and never reach us. We hold a customer reference and a subscription status, nothing resembling a card.
  • SendGrid. Email delivery.
  • Anthropic. Only when you use room capture, and only the photograph you choose to capture.

Everything is served over HTTPS. Backups are handled by Supabase.

Photographs

Location data embedded by your camera is stripped before a photograph is stored. A phone picture of a cabin ordinarily carries the cabin's exact coordinates, and we remove them rather than storing a map reference to your property alongside a photograph of it.

Who can reach the production database

One person. Casa Cabana is built and run by its founder, and no employee, contractor or third party has administrative access. The accounts that matter, including our hosting, database, payments and domain, are protected with multi-factor authentication.

A one-person company is a smaller attack surface than a team, and we would rather say that than imply a security department that does not exist.

Nothing is ever deleted

Cancelling a plan hides the features of that plan. It does not delete your records. They return unchanged if you subscribe again. Corrections inside the product work the same way: entries are voided with a trail rather than erased, so the history stays honest.

What we do not have yet

An honest list is more useful to you than silence.

  • No SOC 2 or ISO 27001 certification. These are meaningful for enterprise buyers and expensive for a product at this stage. Not planned in the near term.
  • No third-party penetration test. Planned before we grow beyond the founding groups.
  • No bug bounty programme. Planned. Responsible disclosure is welcome now, and is described below.
  • No cyber insurance. Planned.
  • No written incident response plan. Planned. What would actually happen is described below.
  • No uptime commitment. Planned. We would rather publish one we can keep than one that sounds reassuring.
  • No third-party error monitoring. Application errors are written to our hosting provider's logs, which we read. Nothing pages us automatically, though the two billing failures that could leave someone paying without access do send an alert. Planned.
  • Sessions do not expire on inactivity. Signing out ends a session; leaving a tab open does not. On a shared computer, sign out.
  • No access logging beyond the in-app activity log, which records who changed what inside your property.

If something went wrong

There is no committee. What would happen is this: we would establish what was reached and whose data was affected, revoke the credentials involved, and email every affected account holder telling them what happened and what we had done. Where the law requires it we would also notify the Office of the Privacy Commissioner of Canada.

We would rather describe the three steps we would actually take than publish a policy we would not follow at two in the morning.

Reporting a vulnerability

If you find a security problem, please write to ron@vissersolutions.com with enough detail to reproduce it. We will not pursue legal action against anyone who reports in good faith and gives us a reasonable chance to fix it before disclosing publicly. We will acknowledge your report and tell you when it is resolved.

Please do not access, modify or delete anyone else's data while investigating.

Questions

ron@vissersolutions.com. If you are evaluating Casa Cabana for a group and something here is not enough, ask. We would rather answer than have you assume.