The controls
actually running

Access is enforced in PostgreSQL, underneath the application. Every table carries row-level security, and a policy scopes each query to the projects the caller's account actually holds — so a query that should return nothing returns nothing, whatever the screen above it asked for.

• Four roles: owner, manager, tenant and super administrator. Each one is a different set of policies, not a different menu.
• Managers are scoped to the projects assigned to them. A manager with no assignment is granted nothing at all — the default is closed, and access has to be given deliberately.
• A tenant reaches their own lease and nothing adjacent to it.
• A signed-out visitor cannot read tenants, owners, cheques, managers, co-owners, maintenance, email logs, snapshots, request logs, notification preferences, or the access-request form's own submissions. The public request form can write to that table and cannot read back from it.

Contracts, Ejari certificates, identity documents, inspection photographs and property media live in private storage. There is no public URL to guess: a request for one is refused outright.

A file is opened through a link signed at the moment you ask for it, valid for one hour by default. When the platform opens one in a new tab it does so with noopener,noreferrer, so the signed address is not handed to the page that opened it.

Accounts are created by an administrator; there is no public sign-up. Authentication is handled by Supabase Auth, and passwords are never stored by the application itself.

Two-factor

Time-based one-time passwords (TOTP, any standard authenticator app) are available on staff accounts — portfolio owners and property managers — and are set up from the account's own security settings.

Sessions

A sign-in creates a session held in the browser on your own device. Signing out ends it.

Roles

An account's role is a database fact, not a client-side preference, and it cannot be changed from the browser.

A property can be published as a share page for a prospect. A share can carry a password and an expiry date. New share passwords are hashed server-side with bcrypt at cost 10 — the platform holds the hash, not the password — and an expired share stops working without anybody having to remember to withdraw it.

A share page is, by design, reachable without an account. Publish one deliberately, give it an expiry, and delete it when the deal is done.

The listings API is read-first and authenticates on a single key header. Keys are issued by the portfolio owner with the scopes they choose — reading published listings, or submitting an enquiry — so an integration is granted the narrow thing it needs rather than an account.

Every key carries its own quota over a rolling 24-hour window, and every response reports the remaining allowance, so a misbehaving client is throttled rather than left to hammer the service. An owner can revoke a key at any moment. Treat a key as a secret: it belongs on a server, never in a browser bundle or a public repository.

Much of a web application's exposure is decided by the build rather than by the code. Four things about ours:

• No source maps are shipped to production, so the deployed bundle does not hand out a readable copy of the application's source.
• Dependencies are pinned by a lockfile carrying integrity hashes for every package, and no dependency lifecycle scripts run during an install.
• The runtime container holds the built site and nothing else — no source tree, no build toolchain, no credentials file. Environment secrets have never been committed to the repository.
• The application contains no eval, no dynamic function construction and no javascript: URLs, and CSV exports are escaped against spreadsheet formula injection before a file is written.

The following would be easy to write and we are not writing it, because none of it is true today and a security page that pads itself is worse than none.

• No certification. Vatra Homes is not ISO 27001 certified, not SOC 2 attested, and has not been assessed against any compliance framework.
• No uptime commitment. We do not publish an availability figure, because we do not currently measure one. There is no status page.
• No specification of encryption at rest beyond what our hosting provider operates, which is theirs to describe rather than ours to assert.
• No claim that the platform is finished. Security work is continuous; where we know something needs hardening, it is on a list and it is being worked through in priority order.

If a procurement process needs any of the above in writing, ask — we would rather tell you where we actually stand than publish a badge.

If you believe you have found a vulnerability, please tell us before you tell anyone else. Write to contact@vatra.homes with what you found, how to reproduce it and what you think the impact is. We will acknowledge you, keep you informed while we work on it, and credit you when it is fixed if you would like us to.

In return we ask for the usual restraint: do not access, modify or delete data that is not yours, do not degrade the service for anybody else, and give us a reasonable chance to fix the issue before publishing. Research carried out on those terms is welcome and we will not treat it as a breach of our terms of service.