How I discovered an authorization vulnerability in Post-Bridge using SecureVibing's security tools that allowed users to escalate their own access privileges.
Testing Post-Bridge with SecureVibing Light Scan
Post-Bridge is a successful SaaS application with over $10,000 in monthly recurring revenue (MRR). Like many modern applications, it's built with Supabase as its backend. I decided to test it using SecureVibing's Light Scan tool to see if there were any exposed security vulnerabilities.
The Light Scan tool quickly analyzes websites for common security issues, including database misconfigurations, exposed API keys, and missing security headers. When I entered post-bridge.com into the scanner, it immediately detected something interesting.
🔍 What Was Detected
The Light Scan found exposed Supabase credentials including the public API key and Supabase URL. While these are technically "public" by design, they provided the entry point for deeper security testing.
Deep Dive with Supabase DeepScan
After detecting the Supabase configuration, I used SecureVibing's Supabase DeepScan tool to analyze the database schema and Row Level Security (RLS) policies. This tool performs a comprehensive analysis of all tables and their security configurations.
DeepScan analyzing the profiles table and detecting the vulnerability
The DeepScan revealed something concerning in the profiles table. While RLS was enabled (which is good!), the RLS policy had a critical flaw in its implementation.
The Vulnerability: Improper Authorization Controls
The profiles table contained both sensitive and non-sensitive data:
- Non-sensitive: name, email (user should be able to update these)
- Sensitive: has_access, access_level (user should NOT be able to update these)
🚨 The Problem
The UPDATE policy allowed users to update their entire profile, including the has_access and access_level columns. This meant any user could grant themselves premium access without paying!
When I tested this with a free account, I was able to update my profile and change my has_access to true and set my access_level to any value I wanted. This is a classic authorization vulnerability.
Understanding the Impact
This vulnerability is particularly dangerous because it's an authorization issue, not an authentication issue. Users were properly authenticated, but they had more permissions than they should have.
💸 Potential Impact
- Revenue Loss: Users could grant themselves premium access without paying
- Business Logic Bypass: Free users could access paid features indefinitely
- Unfair Advantage: Some users could have elevated privileges while others paid for them
- Trust Issues: Legitimate paying customers might feel cheated if they discovered this
The Fix: Better RLS Policy with Column-Level Protection
I contacted the Post-Bridge founder and explained the vulnerability and helped fix it. The solution was to add a WITH CHECK constraint to the UPDATE policy that prevents users from modifying sensitive columns.
✅ The Solution: Column-Level Protection
We added a WITH CHECK clause to the UPDATE policy:
-- Updated RLS Policy for profiles table
CREATE POLICY "Users can update their own profile"
ON public.profiles
FOR UPDATE
USING (auth.uid() = id)
WITH CHECK (
-- This prevents updates to has_access column
has_access IS NOT DISTINCT FROM (
SELECT has_access FROM public.profiles WHERE id = auth.uid()
)
AND
-- This prevents updates to access_level column
access_level IS NOT DISTINCT FROM (
SELECT access_level FROM public.profiles WHERE id = auth.uid()
)
);
The IS NOT DISTINCT FROM check ensures that the new value must be identical to the existing value. If a user tries to change has_access or access_level, the database will reject the update.
🎯 Alternative Approach: Table Separation
Another solution is to separate sensitive and non-sensitive data into different tables:
- profiles table: name, email (user can update)
- user_permissions table: has_access, access_level (only server/admin can update)
This architectural approach makes it impossible for users to accidentally or intentionally modify sensitive permissions, as they're stored in a completely separate table with strict RLS policies.
Key Takeaways: Authentication vs Authorization
🔐 Understanding the Difference
- Authentication: Verifying who the user is (login credentials)
- Authorization: Verifying what the user can do (permissions and access levels)
This vulnerability was an authorization problem. Users were authenticated correctly, but they had authorization to modify data they shouldn't have access to.
🛡️ How to Prevent This
- Use WITH CHECK constraints: Prevent users from modifying sensitive columns
- Separate tables: Store sensitive data in tables with stricter RLS policies
- Server-side validation: Always verify permissions on the backend, not just the database
- Regular security testing: Use tools like SecureVibing to catch these issues early
- Test your RLS policies: Actually try to bypass them as a user would
The Resolution
After I reported the vulnerability to the Post-Bridge founder, he quickly implemented the fix. The RLS policy was updated with the proper WITH CHECK constraints, and users can no longer modify their access levels.
✅ Outcome
- Zero Exploitation: The vulnerability was fixed before any users exploited it
- Improved Security: Post-Bridge now has stronger database security
- Educational Value: This case helps other developers learn from real-world examples
- Responsible Disclosure: The issue was handled professionally and ethically
🎯 Key Takeaway
Enabling RLS is not enough. You need to carefully think about what data users should be able to modify. Just because users can update their profile doesn't mean they should be able to update every column in the profile table.
Always separate concerns: use WITH CHECK constraints for column-level protection or separate sensitive data into different tables with appropriate access controls. Test your RLS policies by actually trying to exploit them!
Disclosure: This security research and case study was conducted with permission and in accordance with Jack Friks, founder of Post-Bridge. The vulnerability was responsibly disclosed and fixed before publication of this article.