Security

Security is foundational to Estaty. Real estate agents trust us with their business data, their clients' contact details, and their property listings. This page describes the technical and organisational measures we take to protect that data.

1. Infrastructure Security

• Estaty is hosted on Vercel, a globally distributed platform with ISO 27001-certified infrastructure and SOC 2 Type II compliance.
• Our database runs on Supabase, which is hosted on AWS in the EU West region. Supabase maintains SOC 2 Type II certification.
• All infrastructure uses redundant, high-availability configurations to minimise downtime.
• We do not manage our own servers. All underlying infrastructure security is handled by our hosting providers.

2. Data Encryption

In transit

• All data transmitted between your browser and Estaty is encrypted using TLS 1.2 or higher.
• HTTPS is enforced on all endpoints. HTTP requests are automatically redirected to HTTPS.
• We use HSTS (HTTP Strict Transport Security) headers to prevent protocol downgrade attacks.

At rest

• All data stored in our Supabase database is encrypted at rest using AES-256.
• File uploads (listing photos, profile images) are stored in Supabase Storage with server-side encryption.
• Database backups are encrypted with the same standard.

3. Authentication & Access Control

• User passwords are hashed using bcrypt with a high work factor. We never store plaintext passwords.
• Session tokens are cryptographically signed JWTs with short expiry times (1 hour), backed by rotating refresh tokens (30 days).
• Google OAuth is supported as a secure sign-in alternative.
• Internal access to production systems is restricted to authorised personnel only, using role-based access control (RBAC).
• We enforce the principle of least privilege: team members only have access to the data they need to perform their role.
• Production database access requires multi-factor authentication.

4. Application Security

• All API endpoints implement authentication checks. Unauthenticated requests are rejected.
• Input validation and sanitisation is applied to all user-supplied data to prevent injection attacks.
• Row-Level Security (RLS) is enforced at the database level using Supabase policies — users can only access their own data.
• Content Security Policy (CSP), X-Frame-Options, and other HTTP security headers are set on all responses.
• File uploads are validated for type and size before storage. Only image formats are accepted.
• Rate limiting is applied to authentication endpoints and API routes to prevent brute-force attacks.

5. Vulnerability Management

• We keep all dependencies up to date and monitor for known vulnerabilities using automated tooling.
• Security patches are applied promptly. Critical vulnerabilities are addressed within 24 hours.
• We review our codebase periodically for security issues.
• Third-party sub-processors are assessed for security compliance before onboarding.

6. Incident Response

In the event of a security incident or data breach:

1. 1.We will detect and contain the incident as quickly as possible.
2. 2.We will assess the scope and nature of any data exposed.
3. 3.We will notify affected users within 72 hours if required under GDPR or other applicable regulations.
4. 4.We will take corrective action and publish a post-incident review where appropriate.

To report a security incident or suspected breach, email security@estaty.io immediately.

7. Employee & Contractor Access

• Access to production data is granted only on a need-to-know basis.
• All team members with system access are required to use strong, unique passwords and MFA.
• Contractors are bound by confidentiality agreements and data processing terms.
• Access is revoked immediately upon end of employment or contract.

8. Reporting a Vulnerability

We take security disclosures seriously. If you discover a potential security vulnerability in Estaty, please report it responsibly by emailing hello@estaty.io with the subject line 'Security Disclosure'.

• Please include a description of the vulnerability and steps to reproduce it.
• Do not publicly disclose the vulnerability until we have had a chance to investigate and remediate.
• We aim to acknowledge all reports within 48 hours and provide a resolution timeline.
• We do not currently operate a formal bug bounty programme, but we appreciate and credit responsible disclosures.

9. Sub-Processor Security

We carefully evaluate the security posture of our sub-processors. All sub-processors are required to maintain appropriate security standards consistent with their role in processing your data. See our Data Processing page for the full list.