![[The AI Show Episode 143]: ChatGPT Revenue Surge, New AGI Timelines, Amazon’s AI Agent, Claude for Education, Model Context Protocol & LLMs Pass the Turing Test](https://www.marketingaiinstitute.com/hubfs/ep%20143%20cover.png)
![Am I responsible for data which is being sent but not stored? [closed]](https://cdn.sstatic.net/Sites/softwareengineering/Img/apple-touch-icon@2.png?v=1ef7363febba)
.png?#)
.png?width=1920&height=1920&fit=bounds&quality=70&format=jpg&auto=webp#)
.png?#)
![Apple Posts Full First Episode of 'Your Friends & Neighbors' on YouTube [Video]](https://www.iclarified.com/images/news/96990/96990/96990-640.jpg)
![Apple May Implement Global iPhone Price Increases to Mitigate Tariff Impacts [Report]](https://www.iclarified.com/images/news/96987/96987/96987-640.jpg)
![Apple Aims to Launch Revamped Siri This Fall After AI Setbacks [Report]](https://www.iclarified.com/images/news/96984/96984/96984-640.jpg)
![[Weekly funding roundup April 5-11] VC inflows into Indian startups remain subdued](https://images.yourstory.com/cs/2/220356402d6d11e9aa979329348d4c3e/WeeklyFundingRoundupNewLogo1-1739546168054.jpg)
Postgres Views: The Hidden Security Gotcha in Supabase
When building with Supabase, Postgres Views can be a powerful tool for simplifying complex queries. But they come with a critical security consideration that isn't immediately obvious: Views bypass Row Level Security (RLS) by default, potentially exposing sensitive data even when your tables are properly secured. As a reminder: RLS is what allows you to safely query your Supabase database directly from the frontend, without routing through your backend server. But if RLS isn't working on a table, that table is like your phone screen on public transport—anyone who wants to take a glance, can. The Security Challenge Even if you've carefully configured RLS policies on your tables, views can create an unintended backdoor because: By default, views don’t use RLS Supabase's RLS policies page doesn't show or warn about exposed views (last checked 09.03.2025) Views don't support RLS in the same way tables do Testing Your View's Security Before deploying any view to production, it's crucial to verify that it properly respects your RLS policies. Here's a quick way to test if your view is secure: // First, sign in as a specific user // Then try to fetch ALL rows from your view const { data } = await supabase.from('my_view').select('*') // If your view respects RLS, you should only see rows this user has permission to access. // If you see ALL rows, your view is bypassing RLS!
When building with Supabase, Postgres Views can be a powerful tool for simplifying complex queries. But they come with a critical security consideration that isn't immediately obvious: Views bypass Row Level Security (RLS) by default, potentially exposing sensitive data even when your tables are properly secured.
As a reminder: RLS is what allows you to safely query your Supabase database directly from the frontend, without routing through your backend server. But if RLS isn't working on a table, that table is like your phone screen on public transport—anyone who wants to take a glance, can.
The Security Challenge
Even if you've carefully configured RLS policies on your tables, views can create an unintended backdoor because:
- By default, views don’t use RLS
- Supabase's RLS policies page doesn't show or warn about exposed views (last checked 09.03.2025)
- Views don't support RLS in the same way tables do
Testing Your View's Security
Before deploying any view to production, it's crucial to verify that it properly respects your RLS policies. Here's a quick way to test if your view is secure:
// First, sign in as a specific user
// Then try to fetch ALL rows from your view
const { data } = await supabase.from('my_view').select('*')
// If your view respects RLS, you should only see rows this user has permission to access.
// If you see ALL rows, your view is bypassing RLS! 
