Supabase RLS Gap Exposes User Chat History and Analytics Data to Potential API Bypass

A critical security gap in a Supabase-backed application leaves user chat history and session analytics vulnerable to direct database access. The system stores sensitive user data in two tables—`learning_sessions` (full chat history) and `analytics_events` (session metadata)—without verified Row Level Security (RLS) policies. While the application's API layer includes user-scoping logic, this protection is rendered useless if RLS is not enforced at the database level. A compromised API key or a successful SQL injection attack could bypass the application entirely, granting unfettered access to all user data. The current RLS status is officially 'unknown' and not tracked in the codebase, creating a blind spot in the security posture.

The core vulnerability centers on the `learning_sessions` and `analytics_events` tables. The API's `LearningRepository.get_session_by_id` function is designed to scope queries to the authenticated user, but this logic is purely application-based. Without corresponding RLS policies on the database tables themselves, any direct query to the Supabase database would ignore these scoping rules. For the `learning_sessions` table, the requirement is explicit: users must only be able to read and write their own rows. The requirements for the `analytics_events` table are less defined but still necessitate documented restrictions or a rationale for leaving it open.

This oversight has been elevated to a launch-blocking issue. The acceptance criteria mandate immediate verification and documentation of all RLS policies in a dedicated `db/rls-policies.sql` file. If RLS is not applied, implementing it is a required pre-launch step. Furthermore, a runbook in the `docs/` folder or the project README must explicitly note that RLS policies are a mandatory, non-negotiable component of the data security architecture. This move signals a shift from implicit trust in the application layer to a defense-in-depth model where the database itself acts as the final security gatekeeper for user data.