Security

We take security seriously. This page summarises how Raeven Reader protects your data, and how you can responsibly disclose vulnerabilities to us.

Architecture summary

• Authentication via Supabase Auth (PKCE flow, JWT-based sessions, refresh-token rotation).
• Authorisation enforced by Postgres Row-Level Security on every table — even a stolen anon key cannot read another user's data.
• Privileged code paths live in a private schema and run as SECURITY DEFINER with empty search_path.
• Admin claims are stored in app_metadata (server-managed), never in user_metadata (user-editable).
• Storage buckets are private by default and namespaced by user UUID.
• Local Poison Guard sanitises every parsed document before it ever reaches an LLM, stripping hidden Unicode tags, zero-width characters, BiDi overrides and direct-injection phrases.
• Transport: TLS 1.2+ everywhere; HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are set on all responses.

Data retention

See our privacy policy for full retention windows. In short: account data persists while your account is active, full IPs are kept for 30 days for abuse follow-up, and you can delete everything on request.

Reporting a vulnerability

We welcome reports from the security community. Please email emorylebo@gmail.com with:

• A description of the issue and its impact.
• Steps to reproduce, ideally with a proof-of-concept.
• Any relevant logs, requests, or screenshots.

We commit to acknowledging reports within 3 business days, providing a substantive update within 14 days, and (where applicable) crediting the reporter in the changelog. Please:

• Give us a reasonable time to fix issues before public disclosure.
• Avoid privacy violations, data destruction, or service degradation while testing.
• Not test against accounts or data that are not your own.

Out of scope

• Reports on third-party services we depend on (please report those upstream first).
• Theoretical issues without a working proof-of-concept.
• Missing security headers on non-content endpoints (e.g. static assets).
• Self-XSS, clickjacking on pages without sensitive actions, missing rate limits on public endpoints already rate-limited at the edge.