Project data isn't abstract. It includes commercial-in-confidence contract terms, test results that determine regulatory acceptance, personnel qualifications, and documentation that will be used in dispute resolution. Putting that data on a cloud platform requires more than a privacy policy — it requires an architecture that makes unauthorised access structurally difficult, not just policy-prohibited.

This post explains how Oestler's security architecture works at the infrastructure, authentication, and data access layers.

Infrastructure: Google Cloud and Firebase

Oestler is built on Google Firebase, which runs on Google Cloud Platform infrastructure. GCP holds ISO 27001, SOC 2 Type II, and SOC 3 certifications. Firebase Firestore and Firebase Storage are both encrypted at rest using AES-256, and all data in transit is encrypted using TLS 1.2 or later.

What this means in practice: the physical and network security of Oestler's data is backed by the same infrastructure that secures Google's own services. The attack surface for infrastructure-level compromise is not a shared hosting server — it's Google Cloud.

Authentication: Firebase App Check and OAuth

All Oestler users authenticate via Firebase Authentication, supporting email/password and OAuth providers (Google, Microsoft) for organisations that want SSO integration with their identity provider.

Firebase App Check is active on all Oestler deployments. App Check verifies that requests to Firestore and Firebase Storage originate from legitimate Oestler app instances — not from automated scripts or API clients attempting to query the database directly. Requests that fail App Check attestation are rejected before they reach the data layer.

This closes a class of attack that affects many Firebase applications: direct database queries using valid credentials extracted from a client bundle. With App Check enforced, a valid auth token alone is not sufficient to read data — the request must also pass App Check attestation from a verified app instance.

Data access: Firestore security rules

Firestore security rules govern every read and write operation at the document level. Rules are evaluated server-side before any data is returned or written — they cannot be bypassed by client-side code.

Oestler's Firestore rules enforce the following access model:

  • Project isolation. All data is scoped to a project identifier. Users can only read and write documents within projects they have been explicitly added to. There is no mechanism for a user to enumerate or access data from other projects.
  • Role-based access. Within each project, users have an assigned role. Roles determine which operations are permitted — read-only users cannot write records, and non-admin users cannot modify project settings or user lists.
  • Document-level ownership. Sign-off records and audit logs carry creator and modifier fields that are validated server-side. A user cannot write a document that attributes authorship to another user.
  • Public share links. Roadmap and document register public links are tokenised URLs validated against the document record. Without a valid token, the resource returns access denied. Public links can be revoked by the project owner at any time.

Storage: Firebase Storage access controls

Files uploaded to Oestler — PDFs, photos, IFC models, attachments — are stored in Firebase Storage. Storage security rules mirror the Firestore access model: files are scoped to a project path, and read access requires authenticated requests with valid project membership.

Storage rules are evaluated per-request, server-side, before any file is served. There are no publicly accessible storage buckets in Oestler. File URLs are signed URLs with expiry, generated on-demand from authenticated requests. An expired or revoked signed URL returns access denied, even if the file physically exists in storage.

Audit logging

Every Firestore write operation in Oestler generates an audit record: the document path, the operation type, the authenticated user, and the timestamp. Audit logs are immutable — they can be read by project admins but cannot be modified or deleted from within the application. This provides a verifiable record of who changed what and when, which is particularly important for regulated document workflows and dispute resolution contexts.

AI processing: Vertex AI and data handling

Oestler's AI features — document summarisation, attribute extraction, validation rule generation — use Google's Vertex AI via the Firebase AI SDK. Document content sent for AI processing is handled under Google's Vertex AI data terms: it is not used to train Google's models, it is not retained beyond the processing request, and it is transmitted over the same encrypted channels as all other API traffic.

Oestler does not send document content to third-party AI providers. All AI processing routes through Vertex AI on the same Google Cloud infrastructure as the rest of the platform.

What Oestler doesn't do

  • No client-side access control. Hiding UI elements from unauthorised users is a UX decision, not a security control. All access controls are enforced at the Firestore rules and Storage rules layer — server-side, before data is returned.
  • No security through obscurity. The security model assumes that path structure is discoverable and relies on authentication and authorisation rules to prevent unauthorised access, not on opaque paths.
  • No plaintext credentials. API keys, service account credentials, and configuration secrets are managed as environment variables and Firebase config, not committed to the codebase.

If you're deploying Oestler on a project with specific data residency requirements, security audit requirements, or regulated document workflows, contact us at hello@oestler.com. We can provide details of the Firebase/GCP compliance certifications relevant to your jurisdiction and support any security review process your organisation requires.