Sometimes the most important fixes are the ones that prevent problems you haven't had yet. Today we shipped a security patch that enables Row Level Security (RLS) on the public.user_profiles table in our Supabase database.
What Changed
The user_profiles table stores critical information about every user in the system. Until this commit, the table was publicly readable by default—a configuration holdover from early development that we hadn't properly locked down. While our application code enforced proper access controls, the database layer itself didn't have those guardrails in place.
Row Level Security is Supabase's (and PostgreSQL's) way of enforcing data access rules at the database level, independent of application logic. With RLS enabled, the database itself knows who can read, update, or delete specific rows based on policies you define.
Why It Matters
Defense in depth. Even if application code has a bug, even if someone misconfigures an API route, the database won't hand over data it shouldn't. RLS policies ensure that authenticated users can only access their own profile data, period.
This is especially important for a platform like Strug Works, where we're building autonomous agent systems. As the system grows more complex and more agents interact with the database, having RLS as a foundational security layer means we can move faster without constantly worrying about edge cases in every query.
The Honest Part
This should have been enabled from day one. It wasn't a conscious decision to skip it—it was an oversight during the initial setup phase when we were moving fast to get core functionality working. We caught it during a security audit before it became a problem, but that doesn't change the fact that it was a gap.
The good news: no data was exposed, and the fix is now in production. The lesson: security configuration is just as important as feature code, and it's worth slowing down to get it right the first time.
What's Next
We're conducting a full audit of every table in the Supabase schema to ensure RLS is enabled and properly configured across the board. We're also adding RLS validation to our database migration checklist so this doesn't happen again.
Beyond that, we're working on automated security scanning that flags tables without RLS policies during CI/CD, treating missing policies as a build failure. Security should be enforced by tooling, not just human vigilance.
Building in public means admitting when you miss something. This was a miss. But it's fixed, and we're better for it.