Bird
Raised Fist0
Expressframework~8 mins

Configuring allowed origins in Express - Performance Optimization Steps

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Performance: Configuring allowed origins
MEDIUM IMPACT
This affects how the server handles cross-origin requests, impacting network latency and browser security checks.
Allowing cross-origin requests securely and efficiently
Express
const allowedOrigins = ['https://example.com', 'https://app.example.com'];
app.use(cors({ origin: (origin, callback) => {
  if (!origin || allowedOrigins.includes(origin)) {
    callback(null, true);
  } else {
    callback(new Error('Not allowed by CORS'));
  }
}}));
Restricts origins to trusted domains, reducing unnecessary preflight requests and improving security.
📈 Performance GainReduces preflight requests and network delays, improving interaction responsiveness
Allowing cross-origin requests securely and efficiently
Express
app.use(cors({ origin: '*' }));
Allowing all origins causes browsers to send preflight OPTIONS requests more often and can expose security risks.
📉 Performance CostTriggers frequent preflight requests, increasing network latency and blocking rendering until response
Performance Comparison
PatternNetwork RequestsPreflight RequestsSecurity RiskVerdict
Allow all origins (*)High - all requests allowedHigh - many preflightsHigh - security risk[X] Bad
Allow specific originsLow - only trusted domainsLow - fewer preflightsLow - secure[OK] Good
Rendering Pipeline
When a browser makes a cross-origin request, it may send a preflight OPTIONS request to check permissions. The server's allowed origins configuration determines if the request proceeds. Proper configuration reduces network round-trips and delays before rendering or interaction.
Network Request
Browser Preflight
Server Response
Interaction Readiness
⚠️ BottleneckNetwork latency caused by unnecessary preflight OPTIONS requests
Core Web Vital Affected
INP
This affects how the server handles cross-origin requests, impacting network latency and browser security checks.
Optimization Tips
1Avoid using wildcard '*' for allowed origins in production.
2Specify only trusted domains in allowed origins to reduce preflight requests.
3Use CORS middleware with origin as a function to dynamically validate origins.
Performance Quiz - 3 Questions
Test your performance knowledge
What is a performance downside of allowing all origins with CORS in Express?
ABlocks all cross-origin requests
BReduces network requests and speeds up loading
CTriggers many preflight OPTIONS requests increasing latency
DImproves browser caching automatically
DevTools: Network
How to check: Open DevTools, go to Network tab, filter by OPTIONS requests, and observe preflight requests when making cross-origin calls.
What to look for: Fewer OPTIONS preflight requests indicate better CORS configuration and improved performance.

Practice

(1/5)
1. What is the main purpose of configuring allowed origins in an Express app using cors middleware?
easy
A. To encrypt data sent between client and server
B. To speed up the server response time
C. To control which websites can access your server resources
D. To log all incoming requests

Solution

  1. Step 1: Understand what allowed origins mean

    Allowed origins specify which websites are permitted to make requests to your server.
  2. Step 2: Identify the role of cors middleware

    The cors middleware in Express helps set these allowed origins to control access.
  3. Final Answer:

    To control which websites can access your server resources -> Option C
  4. Quick Check:

    Allowed origins = control access [OK]
Hint: Allowed origins control access, not speed or encryption [OK]
Common Mistakes:
  • Confusing allowed origins with encryption
  • Thinking it speeds up server
  • Assuming it logs requests
2. Which of the following is the correct way to allow only 'https://example.com' as an origin using the cors middleware in Express?
easy
A. app.use(cors({ origin: [https://example.com] }));
B. app.use(cors({ origin: 'https://example.com' }));
C. app.use(cors({ origins: 'https://example.com' }));
D. app.use(cors(https://example.com));

Solution

  1. Step 1: Check the correct option name for allowed origins

    The correct option is origin, not origins.
  2. Step 2: Verify the value type for origin

    It accepts a string for a single allowed origin, so 'https://example.com' is correct.
  3. Final Answer:

    app.use(cors({ origin: 'https://example.com' })); -> Option B
  4. Quick Check:

    Option name is origin, value is string [OK]
Hint: Use 'origin' option with string for single allowed site [OK]
Common Mistakes:
  • Using 'origins' instead of 'origin'
  • Passing array for single origin string
  • Calling cors without options
3. Given this Express code snippet, what will be the result when a request comes from 'https://allowed.com'?
const cors = require('cors');
app.use(cors({ origin: ['https://allowed.com', 'https://other.com'] }));
medium
A. The request will be allowed because 'https://allowed.com' is in the list
B. The request will be blocked due to invalid origin format
C. The request will be allowed only if it uses POST method
D. The request will be blocked because origin must be a string

Solution

  1. Step 1: Understand the origin option accepts an array

    The origin option can accept an array of allowed origins to permit multiple sites.
  2. Step 2: Check if 'https://allowed.com' is in the array

    Since 'https://allowed.com' is listed, requests from it will be allowed.
  3. Final Answer:

    The request will be allowed because 'https://allowed.com' is in the list -> Option A
  4. Quick Check:

    Array of origins allows listed sites [OK]
Hint: Array of origins lets listed sites access [OK]
Common Mistakes:
  • Thinking origin must be string only
  • Assuming method affects origin check
  • Believing array format causes error
4. Identify the error in this Express CORS setup that aims to allow only 'https://site.com':
app.use(cors({ origin: 'https://site.com', methods: ['GET', 'POST'] }));
app.use(cors());
medium
A. Calling cors() twice causes conflict and overrides settings
B. The methods option is invalid in cors middleware
C. The origin value should be an array, not a string
D. Missing next() call in middleware

Solution

  1. Step 1: Check middleware usage order

    Calling cors() twice means the second call overrides the first, ignoring origin restrictions.
  2. Step 2: Confirm methods option is valid

    The methods option is valid to restrict HTTP methods, so no error there.
  3. Final Answer:

    Calling cors() twice causes conflict and overrides settings -> Option A
  4. Quick Check:

    Multiple cors calls override previous config [OK]
Hint: Only call cors once with all options [OK]
Common Mistakes:
  • Calling cors middleware multiple times
  • Thinking origin must be array always
  • Ignoring middleware order effects
5. You want to allow requests only from origins that end with '.trusted.com' dynamically in Express. Which cors configuration correctly implements this?
hard
A. app.use(cors({ origin: ['*.trusted.com'] }));
B. app.use(cors({ origin: (origin, callback) => { if (origin.includes('.trusted.com')) callback(null, true); else callback(new Error('Not allowed')); } }));
C. app.use(cors({ origin: '/^https:\/\/.*\.trusted\.com$/' }));
D. app.use(cors({ origin: (origin, callback) => { if (origin.endsWith('.trusted.com')) callback(null, true); else callback(new Error('Not allowed')); } }));

Solution

  1. Step 1: Understand dynamic origin checking

    To allow origins ending with '.trusted.com', a function can check the origin string dynamically.
  2. Step 2: Evaluate each option's approach

    app.use(cors({ origin: (origin, callback) => { if (origin.endsWith('.trusted.com')) callback(null, true); else callback(new Error('Not allowed')); } })); uses a function with endsWith to precisely match the domain ending, which is correct. app.use(cors({ origin: ['*.trusted.com'] })); uses wildcard string which is not supported. app.use(cors({ origin: '/^https:\/\/.*\.trusted\.com$/' })); uses regex but cors does not accept regex directly. app.use(cors({ origin: (origin, callback) => { if (origin.includes('.trusted.com')) callback(null, true); else callback(new Error('Not allowed')); } })); uses includes which may allow unwanted matches.
  3. Final Answer:

    app.use(cors({ origin: (origin, callback) => { if (origin.endsWith('.trusted.com')) callback(null, true); else callback(new Error('Not allowed')); } })); -> Option D
  4. Quick Check:

    Use function with endsWith for dynamic origin [OK]
Hint: Use function with endsWith() to allow domain patterns [OK]
Common Mistakes:
  • Using wildcard strings in origin array
  • Passing regex directly as origin
  • Using includes() instead of endsWith()