Testing RLS policies in Supabase - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to enable Row Level Security on the table.

Supabase

ALTER TABLE users ENABLE [1];

Drag options to blanks, or click blank then click option'

ARLS

BTRIGGER

CINDEX

DCONSTRAINT

Attempts:

3 left

💡 Hint

Common Mistakes

Using ENABLE TRIGGER instead of ENABLE RLS.

Trying to enable INDEX or CONSTRAINT which are unrelated.

Enabling RLS (Row Level Security) activates the policy enforcement on the table.

2fill in blank

medium

Complete the code to create a policy that allows users to select their own rows.

Supabase

CREATE POLICY "Users can select their own data" ON users FOR SELECT TO authenticated USING ([1] = auth.uid());

Drag options to blanks, or click blank then click option'

Aid

Bemail

Cuser_id

Dusername

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'user_id' or 'email' which may not match auth.uid().

Using 'username' which is not a unique identifier.

The policy checks if the row's 'id' matches the authenticated user's id.

3fill in blank

hard

Fix the error in the policy condition to correctly check user ownership.

Supabase

CREATE POLICY "Allow update if owner" ON posts FOR UPDATE TO authenticated USING (owner_id [1] auth.uid());

Drag options to blanks, or click blank then click option'

A==

B=

C!=

D<>

Attempts:

3 left

💡 Hint

Common Mistakes

Using '==' which causes syntax errors in SQL.

Using '<>' which means 'not equal'.

In SQL, '=' is used for equality comparison, not '==' which is invalid.

4fill in blank

hard

Fill both blanks to create a policy that allows inserts only if the new row's user_id matches the authenticated user.

Supabase

CREATE POLICY "Allow insert if user matches" ON orders FOR INSERT TO authenticated WITH CHECK ([1] = auth.uid() AND [2] = auth.uid());

Drag options to blanks, or click blank then click option'

Auser_id

Bauth.uid()

Cid

Dorder_id

Attempts:

3 left

💡 Hint

Common Mistakes

Using different columns like 'id' or 'order_id' which do not represent the user.

Using 'auth.uid()' in the blanks which is a function, not a column.

The policy checks that the 'user_id' in the new row matches the authenticated user's id for both conditions.

5fill in blank

hard

Fill the blanks to write a policy that allows deleting rows only if the row's owner_id matches the authenticated user and the row status is 'inactive'.

Supabase

CREATE POLICY "Allow delete if owner and inactive" ON tasks FOR DELETE TO authenticated USING ([1] = auth.uid() AND [2] = 'inactive');

Drag options to blanks, or click blank then click option'

Aowner_id

Bstatus

Ctable_name

Duser_id

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'user_id' instead of 'owner_id' for ownership check.

Confusing 'status' with other columns.

The policy checks that 'owner_id' matches the authenticated user and 'status' is 'inactive'.

Practice

1. What is the main purpose of Row Level Security (RLS) policies in Supabase?

easy

A. To encrypt data stored in the database

B. To speed up database queries by indexing rows

C. To backup data automatically every hour

D. To control which rows a user can access or modify in a table

Solution

1. Step 1: Understand RLS purpose

   RLS policies restrict access to rows based on user identity or conditions.

2. Step 2: Compare options

   Only To control which rows a user can access or modify in a table describes controlling access to rows per user, which is the core of RLS.

3. Final Answer:

   To control which rows a user can access or modify in a table -> Option D

4. Quick Check:

   RLS controls row access = A [OK]

Hint: RLS controls data visibility per user, not performance or backups [OK]

Common Mistakes:

• Confusing RLS with indexing or encryption
• Thinking RLS handles backups
• Assuming RLS speeds up queries

2. Which SQL command correctly enables Row Level Security on a table named profiles in Supabase?

easy

A. ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

B. ALTER TABLE profiles SET ROW LEVEL SECURITY ON;

C. ALTER TABLE profiles ENABLE RLS;

D. ALTER TABLE profiles ENABLE ROW_LEVEL_SECURITY;

Solution

1. Step 1: Recall correct syntax for enabling RLS

   The correct SQL command is ALTER TABLE table_name ENABLE ROW LEVEL SECURITY;.

2. Step 2: Match options with syntax

   Only ALTER TABLE profiles ENABLE ROW LEVEL SECURITY; matches the exact syntax supported by Supabase/PostgreSQL.

3. Final Answer:

   ALTER TABLE profiles ENABLE ROW LEVEL SECURITY; -> Option A

4. Quick Check:

   Enable RLS syntax = A [OK]

Hint: Use exact phrase ENABLE ROW LEVEL SECURITY after ALTER TABLE [OK]

Common Mistakes:

• Using 'RLS' shorthand incorrectly
• Using underscores incorrectly
• Using SET instead of ENABLE

3. Given this RLS policy on messages table:

CREATE POLICY "Users can view their messages" ON messages
FOR SELECT USING (user_id = auth.uid());

What will happen if user with auth.uid() = '123' runs SELECT * FROM messages;?

medium

A. They will see all messages regardless of user_id

B. They will see only messages where user_id = '123'

C. They will see no messages because policy blocks all

D. They will get a syntax error

Solution

1. Step 1: Understand the policy condition

   The policy allows SELECT only if user_id = auth.uid(). For user '123', only rows with user_id '123' are visible.

2. Step 2: Predict query result

   The SELECT query returns only messages owned by user '123'. No syntax errors occur.

3. Final Answer:

   They will see only messages where user_id = '123' -> Option B

4. Quick Check:

   Policy filters rows by user_id = auth.uid() = B [OK]

Hint: Policy filters rows by user_id matching auth.uid() [OK]

Common Mistakes:

• Assuming all rows are visible
• Thinking policy blocks all rows
• Confusing syntax error with policy effect

4. You wrote this RLS policy:

CREATE POLICY "Allow updates" ON profiles
FOR UPDATE USING (user_id = auth.uid());

But users report they cannot update their profiles. What is the likely problem?

medium

A. auth.uid() returns NULL causing policy to fail

B. RLS is not enabled on the profiles table

C. The policy should use WITH CHECK instead of USING

D. The policy name is invalid

Solution

1. Step 1: Understand difference between USING and WITH CHECK

   USING controls which rows can be selected or updated; WITH CHECK controls which updated rows are allowed after update.

2. Step 2: Identify update permission issue

   For UPDATE, WITH CHECK is needed to allow the new row values. Using only USING blocks updates even if row is accessible.

3. Step 3: Check other options

   RLS must be enabled, but question implies it is. auth.uid() returning NULL is unlikely if user is logged in. Policy name is valid.

4. Final Answer:

   The policy should use WITH CHECK instead of USING -> Option C

5. Quick Check:

   Update policies need WITH CHECK = A [OK]

Hint: Use WITH CHECK for update permission, not just USING [OK]

Common Mistakes:

• Using only USING clause for updates
• Forgetting to enable RLS
• Assuming policy name affects behavior

5. You want to test if your RLS policy on orders table correctly restricts users to only see their own orders. Which approach is best to verify this?

hard

A. Run SELECT * FROM orders; as different authenticated users and check results

B. Disable RLS temporarily and check if all orders are visible

C. Check the policy text only without running queries

D. Run SELECT * FROM orders; as the database admin user

Solution

1. Step 1: Understand testing RLS requires simulating user access

   Testing RLS means running queries as different users to see if access is limited correctly.

2. Step 2: Evaluate options

   Run SELECT * FROM orders; as different authenticated users and check results runs queries as different users, which tests the policy effectively. Disable RLS temporarily and check if all orders are visible disables RLS, which doesn't test policy. Check the policy text only without running queries only reads policy text, no test. Run SELECT * FROM orders; as the database admin user uses admin user who bypasses RLS.

3. Final Answer:

   Run SELECT * FROM orders; as different authenticated users and check results -> Option A

4. Quick Check:

   Test RLS by querying as different users = D [OK]

Hint: Test RLS by querying as different users, not admin [OK]

Common Mistakes:

• Testing only as admin user
• Disabling RLS to test policies
• Not running actual queries