CORS configuration in Supabase - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding CORS Purpose

What is the main reason to configure CORS (Cross-Origin Resource Sharing) in a Supabase project?

A To automatically backup Supabase data to another region

B To encrypt data stored in Supabase databases

C To speed up database queries by caching results

D To allow web applications from different origins to securely access Supabase APIs

💡 Hint

Think about why browsers restrict web pages from calling APIs on different domains.

CORS is a security feature that controls which web pages from other origins can access your Supabase APIs. It prevents unauthorized cross-origin requests.

❓ Configuration

intermediate

Correct CORS Origin Setting

You want to allow only your website https://myapp.example.com to access your Supabase API. Which CORS origin setting is correct?

A https://myapp.example.com

B *

C http://myapp.example.com

D myapp.example.com

💡 Hint

Remember CORS origins must include the scheme (http or https) and be exact.

Only the exact origin with https scheme matches your website. Using * allows all origins, which is insecure. Omitting scheme or using http is incorrect.

❓ Architecture

advanced

Impact of Incorrect CORS Configuration

If you set CORS origin to * in Supabase, what is a likely security risk?

A Any website can make requests to your Supabase API, potentially exposing user data

B Your Supabase database will become read-only

C Your API will reject all requests from browsers

D Your Supabase project will automatically scale down

💡 Hint

Think about what allowing all origins means for API access.

Setting CORS to * means any website can call your API, risking data exposure or misuse if authentication is weak.

❓ service_behavior

advanced

Behavior of Supabase API with Missing CORS Header

What happens when a browser calls a Supabase API from an origin not listed in the CORS configuration?

A The browser automatically retries the request with CORS headers

B The API call succeeds and returns data normally

C The browser blocks the response due to missing CORS headers, so the frontend cannot read the data

D The Supabase API returns a 403 Forbidden error

💡 Hint

Consider how browsers enforce CORS policies on responses.

If the response lacks the correct CORS headers for the calling origin, browsers block frontend JavaScript from accessing the response, even if the server sends data.

❓ security

expert

Best Practice for CORS in Supabase with Multiple Frontends

You have two frontend apps: https://app1.example.com and https://app2.example.com. How should you configure CORS in Supabase to allow both securely?

A Set CORS origin to <code>https://app1.example.com https://app2.example.com</code> as a single string

B List both origins explicitly in the CORS settings separated by commas

C Set CORS origin to <code>https://example.com</code> without subdomains

D Set CORS origin to <code>*</code> to allow all origins

💡 Hint

Check how Supabase expects multiple origins to be listed.

Supabase allows multiple origins by listing them separated by commas. Using * is insecure. Omitting subdomains or combining origins without commas is invalid.

Practice

1. What does CORS configuration in Supabase control?

easy

A. How fast your database queries run

B. Which websites can access your Supabase backend

C. The color scheme of your Supabase dashboard

D. The size of your database storage

Solution

1. Step 1: Understand CORS purpose

   CORS stands for Cross-Origin Resource Sharing and controls which websites can send requests to your backend.

2. Step 2: Apply to Supabase context

   In Supabase, CORS settings define allowed origins that can communicate with your backend securely.

3. Final Answer:

   Which websites can access your Supabase backend -> Option B

4. Quick Check:

   CORS controls access origins [OK]

Hint: CORS controls website access to backend [OK]

Common Mistakes:

• Confusing CORS with database speed
• Thinking CORS changes UI colors
• Assuming CORS affects storage size

2. Which of the following is the correct way to allow only https://example.com in Supabase CORS settings?

easy

A. Set allowed origins to ['https://example.com']

B. Set allowed origins to ['http://example.com']

C. Set allowed origins to ['*']

D. Set allowed origins to ['example.com']

Solution

1. Step 1: Understand allowed origins format

   Allowed origins must include the full scheme (https://) and domain to be valid.

2. Step 2: Match correct origin

   Only 'https://example.com' matches the requirement exactly; '*' allows all origins, which is insecure.

3. Final Answer:

   Set allowed origins to ['https://example.com'] -> Option A

4. Quick Check:

   Use full URL with https [OK]

Hint: Use full URL with https:// for origins [OK]

Common Mistakes:

• Using '*' which allows all origins
• Omitting https:// in origin
• Using only domain without scheme

3. Given this Supabase CORS config: { allowedOrigins: ['https://app.com'], allowedMethods: ['GET', 'POST'] }, what happens if a browser sends a DELETE request from https://app.com?

medium

A. Request is allowed but logged as warning

B. Request is allowed and processed

C. Request is blocked due to origin not allowed

D. Request is blocked due to method not allowed

Solution

1. Step 1: Check allowed origins

   The origin 'https://app.com' is allowed, so origin is not the issue.

2. Step 2: Check allowed methods

   Only 'GET' and 'POST' methods are allowed; 'DELETE' is not permitted.

3. Final Answer:

   Request is blocked due to method not allowed -> Option D

4. Quick Check:

   Method not in allowedMethods [OK]

Hint: Check if method is in allowedMethods list [OK]

Common Mistakes:

• Assuming origin blocks the request
• Thinking DELETE is allowed by default
• Believing request is allowed with warning

4. You configured Supabase CORS with allowedOrigins: ['https://myapp.com'] but your frontend at https://myapp.com still gets CORS errors. What is the likely mistake?

medium

A. You forgot to include 'https://' in allowedOrigins

B. You set allowedOrigins to '*' instead of specific origin

C. You did not add the frontend URL exactly as it appears

D. You need to add 'http://' instead of 'https://'

Solution

1. Step 1: Verify exact origin match

   CORS requires exact match including scheme, domain, and port if any.

2. Step 2: Check frontend URL correctness

   If frontend URL differs (e.g., with www or port), it must be added exactly in allowedOrigins.

3. Final Answer:

   You did not add the frontend URL exactly as it appears -> Option C

4. Quick Check:

   Exact origin match needed [OK]

Hint: Match frontend URL exactly in allowedOrigins [OK]

Common Mistakes:

• Assuming '*' fixes errors
• Using http instead of https incorrectly
• Ignoring subdomains or ports in origin

5. You want to securely allow your React app at https://app.example.com and your admin panel at https://admin.example.com to access Supabase. Which CORS configuration is best?

hard

A. allowedOrigins: ['https://app.example.com', 'https://admin.example.com']

B. allowedOrigins: ['*']

C. allowedOrigins: ['https://example.com']

D. allowedOrigins: ['http://app.example.com', 'http://admin.example.com']

Solution

1. Step 1: Avoid using '*' for security

   Using '*' allows all origins, which is insecure for private apps.

2. Step 2: Specify exact allowed origins

   List both 'https://app.example.com' and 'https://admin.example.com' to allow only these trusted sites.

3. Step 3: Use correct scheme https

   Use 'https://' to match secure frontend URLs exactly.

4. Final Answer:

   allowedOrigins: ['https://app.example.com', 'https://admin.example.com'] -> Option A

5. Quick Check:

   List exact secure origins [OK]

Hint: List each allowed origin explicitly with https [OK]

Common Mistakes:

• Using '*' which is insecure
• Using only base domain without subdomains
• Using http instead of https