CORS configuration in Supabase - Time & Space Complexity
When setting up CORS (Cross-Origin Resource Sharing) in Supabase, it's important to know how the number of allowed origins affects the system.
We want to understand how the time to check permissions grows as we add more origins.
Analyze the time complexity of checking CORS origins during an API request.
// Allowed origins configured in Supabase dashboard (Settings > API > CORS)
const allowedOrigins = [
'https://example1.com',
'https://example2.com',
// ... more origins
];
// On each incoming request, check if origin is allowed
const requestOrigin = req.headers.get('origin') || '';
const isAllowed = allowedOrigins.includes(requestOrigin);
This example shows the allowed origins list and the check performed on each request.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Checking if the request origin is in the allowed origins list.
- How many times: Once per incoming API request.
Each request checks the origin against the list of allowed origins one by one.
| Input Size (n) | Approx. Checks per Request |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: The number of checks grows directly with the number of allowed origins.
Time Complexity: O(n)
This means the time to check if an origin is allowed grows linearly with the number of origins configured.
[X] Wrong: "Checking CORS origins happens instantly no matter how many origins there are."
[OK] Correct: Each origin must be checked one by one, so more origins mean more checks and longer time.
Understanding how configuration size affects request handling time shows you can think about real system performance and scalability.
"What if allowed origins were stored in a fast lookup structure like a hash set? How would the time complexity change?"