Restore and harden Row Level Security (RLS) policies (Critical Access… - #36
Open
mertcano wants to merge 1 commit into
Open
Restore and harden Row Level Security (RLS) policies (Critical Access…#36mertcano wants to merge 1 commit into
mertcano wants to merge 1 commit into
Conversation
… Control)
This PR patches a critical Broken Access Control vulnerability in the database layer. Previously, a development migration (`remove_rsl_policies_for_development`) completely disabled Row Level Security (RLS) across the platform. As a result, the public `anon` key could be exploited to perform unauthorized CRUD operations on any user's wallets, transactions, and escrow agreements.
** Vulnerabilities & Anti-Patterns Remediated:**
* **Broken Access Control / Disabled RLS (CRITICAL):**
With RLS disabled, the database lacked native authorization checks. Any client-side request could bypass application logic to read or modify sensitive financial records and escrow states belonging to other users.
**Fix:** Introduced a new migration (`20260813000000_restore_and_harden_rls_policies.sql`) that completely re-enables RLS on `profiles`, `wallets`, `transactions`, `escrow_agreements`, and `dispute_resolutions`.
**Key Code Changes:**
* Re-enabled `ROW LEVEL SECURITY` across all primary data tables.
* Implemented strict `auth.uid() = user_id` binding for `SELECT`, `INSERT`, `UPDATE`, and `DELETE` actions on `wallets` and `transactions`.
* Secured the `escrow_agreements` table by verifying that the authenticated user (`auth.uid()`) owns either the `depositor_wallet_id` or the `beneficiary_wallet_id` via a nested `EXISTS` query before allowing read or mutation access.
* Revoked wide-open permissions that may have been incorrectly assigned to the `anon` role during the development phase.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
… Control)
This PR patches a critical Broken Access Control vulnerability in the database layer. Previously, a development migration (
remove_rsl_policies_for_development) completely disabled Row Level Security (RLS) across the platform. As a result, the publicanonkey could be exploited to perform unauthorized CRUD operations on any user's wallets, transactions, and escrow agreements.** Vulnerabilities & Anti-Patterns Remediated:**
With RLS disabled, the database lacked native authorization checks. Any client-side request could bypass application logic to read or modify sensitive financial records and escrow states belonging to other users.
Fix: Introduced a new migration (
20260813000000_restore_and_harden_rls_policies.sql) that completely re-enables RLS onprofiles,wallets,transactions,escrow_agreements, anddispute_resolutions.Key Code Changes:
ROW LEVEL SECURITYacross all primary data tables.auth.uid() = user_idbinding forSELECT,INSERT,UPDATE, andDELETEactions onwalletsandtransactions.escrow_agreementstable by verifying that the authenticated user (auth.uid()) owns either thedepositor_wallet_idor thebeneficiary_wallet_idvia a nestedEXISTSquery before allowing read or mutation access.anonrole during the development phase.