Select policies for read access in Supabase - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Row Level Security (RLS) for Read Access

In Supabase, you want to allow users to read only their own data from a table with Row Level Security enabled. Which policy condition correctly restricts read access to the current user's rows?

A Using the condition: <code>auth.uid() = user_id</code> in the policy for SELECT

B Using the condition: <code>user_id IS NOT NULL</code> in the policy for SELECT

C Using the condition: <code>auth.role() = 'authenticated'</code> in the policy for SELECT

D Using the condition: <code>TRUE</code> in the policy for SELECT

💡 Hint

Think about how to match the current user's ID with the row's user ID.

The condition auth.uid() = user_id ensures that users can only read rows where the user_id column matches their own user ID. Other options either allow too broad access or do not restrict to the current user.

❓ Configuration

intermediate

Policy to Allow Public Read Access to a Table

You want to allow anyone (even unauthenticated users) to read all rows from a public table in Supabase. Which policy condition should you use?

A Condition: <code>auth.role() = 'authenticated'</code>

B Condition: <code>TRUE</code>

C Condition: <code>auth.uid() IS NOT NULL</code>

D Condition: <code>user_id = auth.uid()</code>

💡 Hint

Think about allowing access without checking user identity.

Using TRUE as the condition allows all users, including unauthenticated ones, to read all rows. Other conditions restrict access to authenticated users or specific user IDs.

❓ Architecture

advanced

Combining Policies for Role-Based Read Access

You have a table where admins can read all rows, but regular users can only read their own rows. Which combination of policy conditions correctly implements this?

A Policy 1: <code>TRUE</code> for SELECT<br>Policy 2: <code>auth.role() = 'admin'</code> for SELECT

B Policy 1: <code>auth.uid() = user_id</code> for SELECT<br>Policy 2: <code>auth.role() = 'authenticated'</code> for SELECT

C Policy 1: <code>auth.role() = 'admin'</code> for SELECT<br>Policy 2: <code>auth.uid() = user_id</code> for SELECT

D Policy 1: <code>auth.role() = 'admin'</code> for SELECT<br>Policy 2: <code>TRUE</code> for SELECT

💡 Hint

Admins should have full read access, users only their own rows.

Policy 1 allows admins to read all rows. Policy 2 restricts regular users to their own rows by matching auth.uid() with user_id. Other options either allow too broad access or do not restrict properly.

❓ service_behavior

advanced

Effect of Missing SELECT Policy on Read Access

If Row Level Security is enabled on a table but no SELECT policy exists, what happens when a user tries to read data from that table?

A The user cannot read any rows because no SELECT policy allows access.

B The user can read rows only if they are the table owner.

C The user can read all rows because RLS defaults to allow.

D The user can read rows only if they have admin role.

💡 Hint

Think about default behavior of RLS when no policies exist.

When RLS is enabled, access is denied by default unless a policy explicitly allows it. Without a SELECT policy, no reads are permitted.

✅ Best Practice

expert

Best Practice for Secure Read Policies in Multi-Tenant Apps

In a multi-tenant Supabase app, each row has a tenant_id column. What is the best policy condition to ensure users only read data belonging to their tenant?

A Condition: <code>TRUE</code>

B Condition: <code>tenant_id = auth.uid()</code>

C Condition: <code>auth.role() = 'authenticated'</code>

D Condition: <code>tenant_id = auth.jwt().tenant_id</code>

💡 Hint

Consider how tenant information is passed securely in JWT claims.

The best practice is to use the tenant ID from the user's JWT token to match the tenant_id column, ensuring users only access their tenant's data. Using auth.uid() matches user ID, not tenant. TRUE allows all access, and auth.role() does not restrict by tenant.

Practice

1. What is the main purpose of a SELECT policy in Supabase?

easy

A. To control who can read data from a table

B. To control who can write data to a table

C. To create new tables in the database

D. To delete data from a table

Solution

1. Step 1: Understand the role of SELECT policies

   SELECT policies define rules for reading data from tables.

2. Step 2: Differentiate from other policies

   Write policies control data insertion or updates, not reading.

3. Final Answer:

   To control who can read data from a table -> Option A

4. Quick Check:

   SELECT policy = read access control [OK]

Hint: SELECT policies = rules for reading data only [OK]

Common Mistakes:

• Confusing SELECT with INSERT or UPDATE policies
• Thinking SELECT policies create or delete tables
• Assuming SELECT policies control write access

2. Which of the following is the correct syntax to create a read policy allowing all users to select from a table named profiles?

easy

A. CREATE POLICY "Allow all" ON profiles FOR UPDATE USING (true);

B. CREATE POLICY "Allow all" ON profiles FOR INSERT USING (true);

C. CREATE POLICY "Allow all" ON profiles FOR SELECT USING (true);

D. CREATE POLICY "Allow all" ON profiles FOR DELETE USING (true);

Solution

1. Step 1: Identify the correct command for read access

   FOR SELECT is used to allow read (select) operations.

2. Step 2: Confirm the condition for allowing all users

   USING (true) means no restriction, so all users can read.

3. Final Answer:

   CREATE POLICY "Allow all" ON profiles FOR SELECT USING (true); -> Option C

4. Quick Check:

   FOR SELECT + USING (true) = allow all read [OK]

Hint: FOR SELECT + USING (true) allows all reads [OK]

Common Mistakes:

• Using FOR INSERT instead of FOR SELECT
• Forgetting the USING clause
• Using FOR DELETE or UPDATE for read access

3. Given the policy:

CREATE POLICY "User can read own profile" ON profiles FOR SELECT USING (auth.uid() = user_id);

What will happen if a user tries to select a profile where user_id is different from their auth.uid()?

medium

A. The user will be able to read the profile

B. The user will get an empty result (no rows)

C. The query will cause a syntax error

D. The user will be able to update the profile

Solution

1. Step 1: Understand the policy condition

   The policy allows reading only if auth.uid() equals user_id.

2. Step 2: Analyze the case when user_id differs

   If user_id is different, the condition fails, so no rows are returned.

3. Final Answer:

   The user will get an empty result (no rows) -> Option B

4. Quick Check:

   Condition false = no rows returned [OK]

Hint: Read allowed only if auth.uid() matches user_id [OK]

Common Mistakes:

• Assuming user can read all profiles
• Expecting an error instead of empty result
• Confusing read with update permissions

4. You wrote this policy:

CREATE POLICY "Allow read" ON orders FOR SELECT USING (user_id = auth.uid);

But users cannot read their orders. What is the problem?

medium

A. USING clause should be omitted

B. The policy should use FOR UPDATE instead of FOR SELECT

C. The table name is incorrect

D. auth.uid should be called as a function: auth.uid()

Solution

1. Step 1: Check the usage of auth.uid

   auth.uid is a function and must be called with parentheses: auth.uid()

2. Step 2: Understand impact of missing parentheses

   Without (), the condition is invalid and blocks access.

3. Final Answer:

   auth.uid should be called as a function: auth.uid() -> Option D

4. Quick Check:

   auth.uid() is required for correct condition [OK]

Hint: Always call auth.uid() with parentheses [OK]

Common Mistakes:

• Using auth.uid without parentheses
• Confusing FOR SELECT with FOR UPDATE
• Removing USING clause mistakenly

5. You want to allow users to read only their own messages from a messages table. The table has columns id, content, and owner_id. Which policy correctly enforces this read access?

hard

A. CREATE POLICY "Read own messages" ON messages FOR SELECT USING (owner_id = auth.uid());

B. CREATE POLICY "Read own messages" ON messages FOR SELECT USING (owner_id != auth.uid());

C. CREATE POLICY "Read own messages" ON messages FOR SELECT USING (true);

D. CREATE POLICY "Read own messages" ON messages FOR UPDATE USING (owner_id = auth.uid());

Solution

1. Step 1: Identify correct condition for own data

   Users should read rows where owner_id equals their auth.uid()

2. Step 2: Confirm correct policy type and condition

   FOR SELECT with USING (owner_id = auth.uid()) restricts reads properly.

3. Final Answer:

   CREATE POLICY "Read own messages" ON messages FOR SELECT USING (owner_id = auth.uid()); -> Option A

4. Quick Check:

   owner_id = auth.uid() restricts read to own rows [OK]

Hint: Use owner_id = auth.uid() in USING for own read access [OK]

Common Mistakes:

• Using != instead of = in condition
• Allowing all reads with USING (true)
• Using FOR UPDATE instead of FOR SELECT