Enabling RLS on tables in Supabase - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What happens when you enable RLS on a Supabase table without any policies?

In Supabase, if you enable Row Level Security (RLS) on a table but do not create any policies, what will be the effect on data access?

A No users can access the data until policies are created.

B All users can read and write data without restrictions.

C Only the table owner can access the data regardless of policies.

D Data is publicly readable but not writable.

💡 Hint

Think about what RLS means for access control when no rules are defined.

Enabling RLS without any policies blocks all access to the table. This is a security feature to prevent unauthorized access until explicit rules are set.

❓ Configuration

intermediate

Which SQL command enables RLS on a Supabase table named 'orders'?

Select the correct SQL command to enable Row Level Security on the 'orders' table.

A ALTER TABLE orders SET ENABLE RLS = ON;

B ALTER TABLE orders SET ROW LEVEL SECURITY = TRUE;

C ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

D ALTER TABLE orders ENABLE RLS;

💡 Hint

Look for the exact syntax PostgreSQL uses for enabling RLS.

The correct command to enable RLS is ALTER TABLE table_name ENABLE RLS;. Other options are invalid syntax.

❓ Architecture

advanced

How to design RLS policies to allow users to access only their own rows in a 'messages' table?

You have a 'messages' table with a column 'user_id' that stores the owner of each message. Which RLS policy correctly restricts access so users can only see their own messages?

A CREATE POLICY "Users can access own messages" ON messages FOR SELECT USING (user_id = session_user);

B CREATE POLICY "Users can access own messages" ON messages FOR SELECT USING (user_id = current_user);

C CREATE POLICY "Users can access own messages" ON messages FOR SELECT USING (user_id = auth.uid());

D CREATE POLICY "Users can access own messages" ON messages FOR SELECT USING (user_id = user());

💡 Hint

Consider the Supabase function that returns the current authenticated user's ID.

The function auth.uid() returns the current user's unique ID in Supabase. Using it in the policy ensures users only access rows where 'user_id' matches their ID.

❓ security

advanced

What is the risk of disabling RLS on a sensitive table in Supabase?

If you disable Row Level Security on a table that contains sensitive user data, what is the main security risk?

A All authenticated users can access all rows without restriction.

B Data becomes encrypted automatically.

C Users can only read data but cannot modify it.

D Only the database admin can access the data.

💡 Hint

Think about what happens when no row-level restrictions are applied.

Disabling RLS removes row-level restrictions, so any authenticated user can read or write all data in the table, risking data leaks.

❓ service_behavior

expert

What is the effect of combining multiple RLS policies with 'USING' clauses on a Supabase table?

Suppose you create two RLS policies on a table with 'USING' clauses. How does Supabase evaluate these policies when a user queries the table?

A Policies are ignored if multiple exist; access is unrestricted.

B The user can access rows if any one policy's 'USING' clause returns true (logical OR).

C Only the first policy created is evaluated; others are ignored.

D The user can access rows only if all policies' 'USING' clauses return true (logical AND).

💡 Hint

Consider how PostgreSQL combines multiple row-level security policies.

PostgreSQL combines multiple RLS policies with a logical OR, so if any policy allows access to a row, the user can see it.

Practice

1. What does enabling Row Level Security (RLS) on a Supabase table do?

easy

A. It backs up the table data to a secure location.

B. It encrypts the entire table data automatically.

C. It controls which rows a user can access based on their identity.

D. It increases the table's storage capacity.

Solution

1. Step 1: Understand RLS purpose

   RLS restricts access to rows in a table depending on who the user is.

2. Step 2: Compare options

   Only It controls which rows a user can access based on their identity. describes controlling row access by user identity, others describe unrelated features.

3. Final Answer:

   It controls which rows a user can access based on their identity. -> Option C

4. Quick Check:

   RLS = Row access control [OK]

Hint: RLS controls row access by user identity, not encryption or backup [OK]

Common Mistakes:

• Confusing RLS with encryption
• Thinking RLS backs up data
• Assuming RLS increases storage

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

easy

A. ALTER TABLE profiles SET RLS = TRUE;

B. ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

C. ENABLE RLS ON TABLE profiles;

D. SET ROW LEVEL SECURITY ON profiles;

Solution

1. Step 1: Recall correct SQL syntax for enabling RLS

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

2. Step 2: Match options to syntax

   Only ALTER TABLE profiles ENABLE ROW LEVEL SECURITY; matches the exact syntax; others are invalid SQL commands.

3. Final Answer:

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

4. Quick Check:

   ALTER TABLE + ENABLE ROW LEVEL SECURITY = correct syntax [OK]

Hint: Use ALTER TABLE ... ENABLE ROW LEVEL SECURITY to enable RLS [OK]

Common Mistakes:

• Using SET instead of ENABLE
• Wrong command order
• Missing ALTER TABLE keyword

3. Given the following policy on table tasks with RLS enabled:

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

What will happen if a user tries to select tasks where user_id is different from their own?

medium

A. They will see only tasks where user_id matches their auth.uid().

B. They will get a syntax error.

C. They will see all tasks regardless of user_id.

D. They will see no tasks at all.

Solution

1. Step 1: Understand the policy condition

   The policy allows SELECT only if user_id = auth.uid(), meaning users see only their own tasks.

2. Step 2: Predict query result for mismatched user_id

   If user_id differs, the condition fails, so those rows are not visible.

3. Final Answer:

   They will see only tasks where user_id matches their auth.uid(). -> Option A

4. Quick Check:

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

Hint: Policy USING clause filters rows by user identity [OK]

Common Mistakes:

• Assuming all rows are visible
• Expecting syntax errors from policy
• Thinking no rows are visible at all

4. You enabled RLS on the orders table but users report they cannot see any rows even though policies exist. What is the most likely cause?

medium

A. The table has too many rows.

B. The table is missing a primary key.

C. The database connection is lost.

D. RLS is enabled but no policies allow access to rows.

Solution

1. Step 1: Understand RLS behavior

   When RLS is enabled, access depends on policies. Without policies allowing access, no rows are visible.

2. Step 2: Evaluate other options

   Missing primary key, connection loss, or row count do not directly cause no rows to show due to RLS.

3. Final Answer:

   RLS is enabled but no policies allow access to rows. -> Option D

4. Quick Check:

   RLS needs policies to permit row access [OK]

Hint: Enable policies after RLS to allow row access [OK]

Common Mistakes:

• Ignoring missing policies
• Blaming unrelated database issues
• Assuming RLS shows all rows by default

5. You want to allow users to insert rows into the messages table only if the sender_id matches their authenticated user ID. Which policy correctly enforces this with RLS enabled?

hard

A. CREATE POLICY "Allow insert if sender matches" ON messages FOR INSERT WITH CHECK (sender_id = auth.uid());

B. CREATE POLICY "Allow insert" ON messages FOR INSERT USING (sender_id = auth.uid());

C. CREATE POLICY "Allow insert" ON messages FOR SELECT WITH CHECK (sender_id = auth.uid());

D. CREATE POLICY "Allow insert" ON messages FOR UPDATE WITH CHECK (sender_id = auth.uid());

Solution

1. Step 1: Identify correct policy type for INSERT

   For INSERT, WITH CHECK controls if new rows meet the condition.

2. Step 2: Match condition to sender_id and auth.uid()

   The condition sender_id = auth.uid() ensures users insert only their own messages.

3. Step 3: Verify options

   CREATE POLICY "Allow insert if sender matches" ON messages FOR INSERT WITH CHECK (sender_id = auth.uid()); uses FOR INSERT with WITH CHECK and correct condition; others use wrong commands or clauses.

4. Final Answer:

   CREATE POLICY "Allow insert if sender matches" ON messages FOR INSERT WITH CHECK (sender_id = auth.uid()); -> Option A

5. Quick Check:

   INSERT policies use WITH CHECK to validate new rows [OK]

Hint: Use WITH CHECK for INSERT policies to validate new rows [OK]

Common Mistakes:

• Using USING instead of WITH CHECK for INSERT
• Applying SELECT or UPDATE instead of INSERT
• Missing condition on sender_id