Support wildcard patterns and regex in CORS configuration

[antoinekm]

Current Behavior

Payload v3's CORS configuration only supports:

• A wildcard string '*' (allows all origins)
• An array of exact strings string[] (requires exact match)
• A CORSConfig object with origins: '*' | string[]

cors: [
  'https://app.example.com',      // ✅ Works
  'https://*.example.com',        // ❌ Doesn't work - treated as literal string
  'https://dev-*.example.com',    // ❌ Doesn't work
]

Problem

When working with dynamic development environments where developers have individual subdomains (e.g., alice-dev.example.com, bob-dev.example.com), the current CORS implementation forces you to either:

1. Use '*' in development - Too permissive, security concern
2. Manually list every developer's subdomain - Not scalable, requires constant updates
3. Use environment variables per developer - Cumbersome to maintain

Use Case

// What we need
cors: [
  'https://example.com',
  'https://*-dev.example.com',  // Match alice-dev, bob-dev, etc.
]

Real-world scenario:

• Production: https://app.tonightpass.com
• Staging: https://staging.tonightpass.com
• Dev tunnels: https://alice-dev.tonightpass.com, https://bob-dev.tonightpass.com

Currently, we must use cors: '*' in development, which defeats the purpose of CORS protection.

Proposed Solution

Support pattern matching similar to Express CORS middleware:

Option 1: Regex patterns

cors: [
  'https://example.com',
  /^https:\/\/[a-z]+-dev\.example\.com$/,  // Regex support
]

Option 2: Wildcard strings with glob pattern

cors: [
  'https://example.com',
  'https://*-dev.example.com',  // Wildcard support
]

Option 3: Custom validation function

cors: {
  origins: (origin: string) => {
    // Custom logic
    return origin.endsWith('-dev.example.com') || origin === 'https://example.com'
  }
}

Benefits

• ✅ Better security - no need for '*' in development
• ✅ Scalability - supports dynamic environments without configuration changes
• ✅ Developer experience - matches patterns used in other frameworks (Express, Fastify, etc.)
• ✅ Backwards compatible - existing string arrays continue to work

Workaround (Current)

cors: process.env.NODE_ENV === 'production'
  ? ['https://example.com']  // Strict in production
  : '*'                       // Too permissive in development

References

• Express CORS supports regex and functions: https://expressjs.com/en/resources/middleware/cors.html
• Similar issue in other frameworks: Regular expression or wildcard origins corydolphin/flask-cors#54

Would love to see this feature in Payload v3! Happy to contribute if there's interest.