mirror of
https://github.com/Dvorinka/1356.git
synced 2026-06-04 12:02:56 +00:00
Tomas Dvorak
112 lines
4.7 KiB
Markdown
112 lines
4.7 KiB
Markdown
# LifeTimer — Security and Privacy Design
|
|
|
|
This document describes how LifeTimer should be built to reduce the risk of hacking, data leaks, and misuse.
|
|
|
|
## 1. Goals
|
|
|
|
- Protect user data (goals, milestones, countdown, email, profile).
|
|
- Make it hard for attackers to access or modify data they do not own.
|
|
- Limit damage even if a single part of the system is compromised.
|
|
|
|
---
|
|
|
|
## 2. Privacy model
|
|
|
|
- Each user chooses a single **account visibility** setting:
|
|
- **Private account** (default)
|
|
- Only the user can see their goals, milestones, countdown, and stats.
|
|
- Account never appears in feeds, search, or leaderboards.
|
|
- **Public account**
|
|
- Other users can see a **limited public view**: avatar, username, high level stats, and public milestones.
|
|
- Sensitive data (email, internal IDs, detailed logs) never leaves the backend.
|
|
- Visibility is implemented via a boolean flag `users.is_public_profile`.
|
|
|
|
---
|
|
|
|
## 3. Access control and Row Level Security (RLS)
|
|
|
|
High level rules for Supabase/Postgres:
|
|
|
|
- **General principles**
|
|
- Every table that contains user data has RLS enabled.
|
|
- There is no unauthenticated read access to private data.
|
|
- Service role key is used only in secure server environments, not in the mobile app.
|
|
|
|
- **users table**
|
|
- A user can `SELECT` and `UPDATE` only their own row.
|
|
- Other users can `SELECT` a limited subset of columns (username, avatar_url, is_public_profile, high level stats) **only when** `is_public_profile = true`.
|
|
- Email and other sensitive fields are never exposed in public queries.
|
|
|
|
- **goals, goal_steps, activities, notifications tables**
|
|
- Reads and writes are allowed only when `owner_id = auth.uid()` (or `user_id = auth.uid()`), regardless of public/private setting.
|
|
- Public feeds and leaderboards do **not** expose full goal records; they use derived or aggregated views that expose only non sensitive data.
|
|
|
|
- **followers and social features**
|
|
- Follow relationships can only be created for public accounts.
|
|
- Queries that build feeds or leaderboards always join through `users` and require `is_public_profile = true`.
|
|
|
|
- **Testing RLS**
|
|
- For each table, add tests that simulate different users:
|
|
- Owner can read/write their rows.
|
|
- Other users cannot read private rows.
|
|
- Other users can read only allowed fields for public accounts.
|
|
|
|
---
|
|
|
|
## 4. Authentication and session security
|
|
|
|
- Use Supabase Auth for all login and sign up flows.
|
|
- Enforce strong password rules for email/password sign up.
|
|
- Use OAuth flows (Google, Apple) via official SDKs only.
|
|
- Store access and refresh tokens only via platform secure storage APIs.
|
|
- Provide logout that clears tokens from secure storage and memory.
|
|
- Optionally add app level lock (PIN or biometrics) before opening sensitive screens on a shared device.
|
|
|
|
---
|
|
|
|
## 5. Key and configuration management
|
|
|
|
- Store Supabase keys and environment URLs only in configuration files, not hard coded in code.
|
|
- Ship **only** the public anon key in the mobile app.
|
|
- Keep the Supabase service role key in server side environments (CI, Edge Functions) and protect it with secret managers.
|
|
- Rotate keys if a leak is suspected.
|
|
|
|
---
|
|
|
|
## 6. Network and API security
|
|
|
|
- Enforce HTTPS for all communication with Supabase.
|
|
- Optionally enable certificate pinning in the mobile app for additional protection.
|
|
- Validate data on the server side (for example inside Edge Functions) for any complex operations.
|
|
- Use pagination and rate limiting on endpoints that can be abused for scraping.
|
|
|
|
---
|
|
|
|
## 7. Secure coding guidelines
|
|
|
|
- Use parameterized queries and the official Supabase client instead of building raw queries from strings.
|
|
- Never log passwords, tokens, or full request/response bodies that may contain secrets.
|
|
- Sanitize and validate user input before using it in business logic.
|
|
- Handle errors with generic messages for users and more detailed logs on the backend.
|
|
|
|
---
|
|
|
|
## 8. Logging, monitoring, and incident response
|
|
|
|
- Send errors to a crash/analytics service with anonymized context.
|
|
- Monitor for unusual patterns (for example many failed login attempts from one IP).
|
|
- Have a procedure for
|
|
- disabling compromised accounts,
|
|
- rotating keys,
|
|
- notifying affected users when needed.
|
|
|
|
---
|
|
|
|
## 9. Data lifecycle
|
|
|
|
- Store only data that is necessary for the product to work.
|
|
- Allow users to delete their accounts; deletion should remove or anonymize their data where possible.
|
|
- Consider providing data export in later phases so users can keep a copy of their progress.
|
|
|
|
This document should be kept in sync with `requirements-nonfunctional.md`, `database-schema.md`, and `architecture.md` as the system evolves.
|