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.