Security

Last updated: 2026-05-20

SkyLog handles real personal data — jump logs, GPS tracks, gear, contact details — and we take its protection seriously. This page summarises how we secure the platform and how to responsibly report a vulnerability.

Security model

  • Encryption. All connections to SkyLog are TLS 1.2+. Data is encrypted at rest by Google Cloud (the storage backing for Cloud SQL, Cloud Storage, Firestore-derived services, and our log sinks).
  • Authentication. Firebase Authentication issues short-lived ID tokens (1 h). Every authenticated server request verifies the token signature server-side with firebase-admin before any database call — see our public design note in GOTCHAS.md → extractFirebaseUid.
  • App Check. Production traffic is gated by Firebase App Check with reCAPTCHA v3, so requests not coming from a legitimate SkyLog client are rejected.
  • Row-level ownership. Our Data Connect schema and API layer cross-check the authenticated user against any row reference in the request; cross-user reads and writes are blocked at the boundary, not just the UI.
  • Rate limiting. Sensitive flows (SMS verify- link, sign-in attempts) are rate-limited via Upstash Redis, both per-caller and per-target, so an attacker can’t burn another user’s SMS quota or brute-force account-link codes.
  • Secret management. Runtime secrets live in Google Secret Manager and are mounted into Cloud Run at request time; no secrets are baked into images or git history.
  • Workload Identity Federation. Our CI/CD authenticates to Google Cloud via Workload Identity Federation (no long-lived service-account keys), and the seeder service account follows least-privilege role scoping.

We do not currently hold SOC 2 or ISO 27001 certification. We’ll update this page when we do.

Responsible disclosure

If you’ve found a vulnerability, please tell us before disclosing it publicly. We commit to:

  • Acknowledge your report within 3 business days.
  • Provide an initial assessment within 10 business days.
  • Keep you updated on remediation progress and credit you (if you’d like) when we publish a fix.
  • Not pursue legal action against good-faith research that follows the rules below.

What’s in-scope:

  • SkyLog web app — skyloglive.com, beta.skyloglive.com, and the underlying *.web.app hosting domains.
  • SkyLog API — every route under /api/v1/*.
  • SkyLog iOS and Android apps (when released).

What’s out-of-scope:

  • Reports from automated scanners with no demonstrated impact (we already run scanners).
  • Findings dependent on social engineering of our staff or our users.
  • Denial-of-service attacks. Please do not load-test our production infrastructure.
  • Issues in third-party services we depend on (report those to the vendor first; CC us if helpful).
  • Missing security headers / cookie flags with no demonstrated security impact.

Rules of engagement:

  • Use test accounts you create yourself. Don’t access, modify, or destroy data belonging to other users.
  • Don’t exfiltrate more data than necessary to demonstrate the issue. Stop immediately if you encounter PII you didn’t expect, and tell us.
  • Give us reasonable time to fix before publishing — typically 90 days, longer for complex issues.
  • We don’t currently run a paid bug bounty. We’re happy to credit you publicly and provide swag where appropriate.

Contact

Send reports to contact@skyloglive.com. PGP key on request — we’ll provide one as soon as we publish it.

You can also see the RFC 9116 disclosure metadata at /.well-known/security.txt.

Cookies & privacy

SkyLog uses strictly necessary cookies to keep you signed in and protect against fraud. We'd also like to use analytics cookies to understand how the app is used — only if you agree. Read our privacy policy