CORS configuration in Supabase - Step-by-Step Execution

Process Flow - CORS configuration

Client sends request

↓

Browser sets Origin

↓

Request reaches Supabase API

↓

Supabase checks allowed origins

↓

Response sent

↓

Browser accepts

When a client sends a request, the browser includes the Origin header. Supabase checks if the origin is allowed. If allowed, it responds with CORS headers; if not, the browser blocks the response due to missing CORS headers.

Execution Sample

Supabase

// Origin: https://example.com (automatically set by browser)
await supabase.from('test').select('*');

This simulates a client request from 'https://example.com' to Supabase with an Origin header.

Process Table

Step	Action	Origin Header	CORS Allowed Origins	CORS Check Result	Request Outcome
1	Client sends request	https://example.com	https://example.com, https://app.example.com	Origin matches allowed list	Request proceeds
2	Supabase receives request	https://example.com	https://example.com, https://app.example.com	Origin allowed	Response sent with CORS headers
3	Browser receives response	https://example.com	https://example.com, https://app.example.com	CORS headers present	Browser accepts response
4	Client sends request	https://malicious.com	https://example.com, https://app.example.com	Origin not in allowed list	Request blocked
5	Browser blocks response	https://malicious.com	https://example.com, https://app.example.com	No CORS headers	Browser blocks response

💡 Requests from origins not in the allowed list are blocked by the browser due to missing CORS headers.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
Origin Header	None	https://example.com	https://example.com	https://example.com	https://malicious.com	https://malicious.com
CORS Allowed Origins	https://example.com, https://app.example.com	https://example.com, https://app.example.com	https://example.com, https://app.example.com	https://example.com, https://app.example.com	https://example.com, https://app.example.com	https://example.com, https://app.example.com
CORS Check Result	None	Allowed	Allowed	Allowed	Not Allowed	Not Allowed
Request Outcome	None	Proceed	Response Sent	Accepted	Blocked	Blocked

Key Moments - 2 Insights

Why does the browser block the request from 'https://malicious.com' even though the request reaches Supabase?

Because 'https://malicious.com' is not in the allowed origins list, Supabase does not send CORS headers. The browser sees this and blocks the response as shown in steps 4 and 5.

What happens if the Origin header matches one of the allowed origins?

Supabase includes CORS headers in the response, so the browser accepts the response and allows the client to use it, as shown in steps 1 to 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the CORS Check Result at Step 4?

A Allowed

B Not Allowed

C Pending

D Unknown

💡 Hint

Check the 'CORS Check Result' column for Step 4 in the execution table.

At which step does the browser accept the response?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Look at the 'Request Outcome' column to find when the browser accepts the response.

If we add 'https://malicious.com' to the allowed origins, what changes in the execution table?

A Step 1 Origin Header changes

B Step 5 Request Outcome remains Blocked

C Step 4 CORS Check Result becomes Allowed

D No changes occur

💡 Hint

Adding an origin to allowed origins affects the CORS Check Result for requests from that origin.

Concept Snapshot

CORS configuration controls which website origins can access Supabase APIs.
Set allowed origins in Supabase settings.
Browser sends Origin header with requests.
Supabase responds with CORS headers if origin allowed.
Browser blocks responses without matching CORS headers.
Proper CORS setup prevents unauthorized cross-site requests.

Full Transcript

CORS configuration is a security feature that controls which websites can access Supabase APIs. When a client sends a request, the browser includes the Origin header. Supabase checks if this origin is in its allowed list. If yes, it sends back CORS headers allowing the browser to accept the response. If not, the browser blocks the response to protect the user. This flow ensures only trusted websites can interact with Supabase resources.

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