Security Practices

Effective 15 June 2026 · Version 1.0

Giraffe (the "Service") is a small, independent project. This page describes how the Operator protects User data. It does not claim certifications the Operator does not hold; it states what is actually in place. The terms "Service", "Operator", and "User" are used as defined in the Terms of Use.

Encryption

Data is encrypted in transit (TLS) and at rest (database and storage encryption). The Provider Key receives an additional layer: it is encrypted at the application level with libsodium before storage, so it is protected beyond storage encryption.

Authentication

Sign-in is handled by Auth.js, supporting Google sign-in, magic links, and passwords, with optional multi-factor authentication (authenticator apps and passkeys). A User may review and revoke active sessions in settings.

Access control

The Service is multi-tenant, and isolation is enforced at the database level with row-level security: data is reachable only in the context of the account it belongs to. Within a shared trip, access follows per-trip roles (owner / editor / viewer).

Scanning and code safety

The build pipeline runs secret scanning, dependency-vulnerability scanning, container scanning, and static analysis, so issues are caught before release.

Logging and audit

Sensitive actions are recorded in an application audit log. Structured server logs are used for debugging and monitoring, scrubbed of personal data where practical.

Backups

Data is backed up regularly (managed backups plus periodic database snapshots to separate storage), with limited retention, to enable recovery from failures.

Incident response

On detecting or being notified of a security issue, the Operator triages promptly, contains it (for example, by rotating keys and revoking sessions), and notifies the relevant authority and affected Users where and as required by applicable law. The precise breach-notification commitment is set out in the breach section of the Privacy Policy.

Certifications

The Service does not hold SOC 2, ISO 27001, or similar formal certifications; it is an early-stage independent project. Rather than claim standards it does not meet, this page describes the measures actually in place, which the Operator improves as the project grows.

Reporting a vulnerability

Report suspected vulnerabilities to security@giraffe.land. The Operator welcomes good-faith security research and considers testing conducted in accordance with this policy to be authorized; it will not pursue legal action for such research. To remain in scope, a researcher must:

• not access, modify, or exfiltrate data that is not their own;
• not degrade or disrupt the Service (no denial-of-service, no spam, no automated scanning that impairs it);
• not use social-engineering or physical attacks; and
• give the Operator a reasonable opportunity to fix the issue — at least 90 days — before disclosing it publicly.

This authorization covers only the Service itself. The Operator's infrastructure providers (for example, Supabase, Vercel, and Cloudflare) operate their own security programs and terms.