Security & compliance

Overview

Swyvl is built with security as a core requirement, not an afterthought. Spatial data often contains sensitive asset information, infrastructure locations, and proprietary survey data. Here’s how we protect it.

Authentication

All users authenticate via Supabase Auth — industry-standard JWT-based authentication
Sessions expire and are automatically refreshed
Passwords are hashed with bcrypt and never stored in plaintext
MFA (multi-factor authentication) support: coming soon

Data access control

Row-level security (RLS)

Every database table has Row-Level Security policies enforced at the database level by PostgreSQL. Even if application code has a bug, the database will not return data you don’t have permission to see.

Access is scoped by:

Organisation membership — you can only see data in organisations you belong to
Workspace membership — you can only see data in workspaces you’re a member of

Share links are public by design — they’re intended for clients who don’t have Swyvl accounts. Share link security is controlled by:

Access mode — view-only prevents downloads
Unpublish — revokes access immediately
Expiry and password protection — coming soon

File access

Files are stored in private object storage. Access is granted only via short-lived presigned URLs (1-hour expiry) generated by the Swyvl server. URLs are never cached with credentials.

Data storage

Files are stored in Wasabi object storage — SOC 2 Type II, ISO 27001 certified
Storage is region-locked — files in your chosen region never leave it
All data is encrypted at rest (AES-256) and in transit (TLS 1.2+)
File data is never used for AI training

Viewer security

Swyvl’s file viewers run inside sandboxed iframes. Viewer code cannot:

Access your Swyvl session or cookies
Make requests outside the viewer sandbox
Read or write to the parent page’s DOM

This is enforced via:

sandbox attribute on the iframe element
Content-Security-Policy headers restricting allowed origins
Subresource integrity checks on viewer libraries

Infrastructure

Database: Supabase (PostgreSQL on AWS) — automated backups, point-in-time recovery
Processing: Google Cloud Run — isolated containers per job, no persistent state
File storage: Wasabi S3-compatible — zero egress costs, no data transfer to third parties
Hosting: Firebase Hosting (Google CDN) — global edge network, DDoS protection

Compliance

Standard	Status
SOC 2 Type II (via Wasabi)	✓ Storage layer
ISO 27001 (via Wasabi)	✓ Storage layer
GDPR	✓ EU region available, DPA on request
Australian Privacy Act	✓ AU region, APP compliant
CCPA	In progress

For compliance documentation, DPA requests, or security questions: security@swyvl.io

Responsible disclosure

If you discover a security vulnerability in Swyvl, please report it to security@swyvl.io. We aim to acknowledge reports within 24 hours and resolve critical issues within 72 hours.

Please do not publicly disclose vulnerabilities before we’ve had a chance to address them.

Audit logging

Every significant action in Swyvl is recorded in an audit log:

File uploads, downloads, and deletions
Share link creation, viewing, and unpublishing
Account changes (login, password change, member added/removed)

Audit logs are accessible to organisation administrators and are available for export on Enterprise plans.