Cross Origin Resource Sharing commonly known as CORS is an important security mechanism used by modern browsers to control how web applications access resources from different domains. In today's web ecosystem many applications interact with APIs, microservices, and external platforms. These interactions often happen across different domains, which makes proper CORS configuration essential for maintaining both functionality and security.
Without a CORS policy in place, browsers restrict cross domain requests by default. This restriction prevents malicious websites from accessing sensitive resources belonging to another domain. With CORS headers, a server can explicitly define which origins are allowed to interact with its resources.
Implementing CORS correctly ensures secure data sharing while protecting your application from unauthorized cross site requests.
What Cross Origin Resource Sharing Means
Cross Origin Resource Sharing is an HTTP based mechanism that allows a server to specify which external domains are permitted to access its resources.
An origin is defined by three components
Domain name
Protocol such as HTTP or HTTPS
Port number
If any of these differ between the requesting site and the target resource, the request is considered cross origin.
For example
Site A
https://app.example.com
Site B
https://api.example.com
Although these belong to the same organization, the browser treats them as different origins. In such cases the server must explicitly allow the request using CORS headers.
Why CORS Is Important for Web Security
CORS plays a major role in browser security models. It helps prevent attacks such as cross site request forgery and unauthorized API access.
Key benefits include
- Protection against malicious websites attempting to read private data
- Controlled access to APIs and backend services
- Secure interaction between frontend applications and external APIs
- Improved flexibility for distributed architectures
Modern web platforms often rely on multiple services, which makes CORS configuration an important part of web infrastructure management.
CORS policies are enforced through specific HTTP response headers returned by the server.
Below are the most important headers used in a CORS configuration.
Access Control Allow Origin
This header defines which origin is allowed to access the resource.
Example
Access-Control-Allow-Origin: https://example.com
Only requests coming from this domain will be accepted.
A wildcard can also be used
Access-Control-Allow-Origin: *
However this allows all domains to access the resource and should only be used for public content.
Access Control Allow Methods
This header specifies which HTTP methods are allowed.
Example
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
This tells the browser that these request methods are permitted for cross origin access.
This header defines which custom headers can be included in the request.
Example
Access-Control-Allow-Headers: Content-Type, Authorization
This allows clients to send these headers during cross origin requests.
Access Control Allow Credentials
This header controls whether cookies or authentication information can be sent with the request.
Example
Access-Control-Allow-Credentials: true
When enabled, the requesting site can include session cookies or authentication tokens.
Note that credentials cannot be used when the origin is set to a wildcard.
Access Control Max Age
This header determines how long a browser can cache the result of a preflight request.
Example
Access-Control-Max-Age: 3600
This allows the browser to reuse the preflight response for one hour without repeating the validation process.
This header specifies which response headers the browser is allowed to access from the client side.
Example
Access-Control-Expose-Headers: X-Custom-Header
Without this setting, certain headers remain inaccessible to client side scripts.
How the CORS Request Flow Works
Understanding the CORS request flow helps developers troubleshoot access issues.
When a webpage makes a request to a different domain, the browser automatically includes an Origin header.
Example
Origin: https://app.example.com
This tells the server where the request is coming from.
Step 2 Server Evaluates the Request
The server checks whether the origin is allowed based on its CORS policy.
If the origin is permitted, the server returns the appropriate CORS headers.
Step 3 Preflight Request for Complex Operations
For certain requests the browser performs an additional verification step known as a preflight request.
This happens when
Custom headers are used
HTTP methods such as PUT or DELETE are involved
Credentials are included
The browser sends an OPTIONS request to verify that the server allows the intended operation.
Step 4 Server Responds to Preflight Request
The server returns CORS headers indicating whether the request is permitted.
If the response is valid, the browser proceeds with the actual request.
Step 5 Actual Request Is Sent
After successful validation, the browser sends the real HTTP request and processes the server response.
Configuring CORS on Web Servers
Proper server configuration ensures that CORS policies are consistently applied.
Apache Example Configuration
Header set Access-Control-Allow-Origin "https://example.com"
Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
Header set Access-Control-Allow-Credentials "true"
Header set Access-Control-Max-Age "3600"
This configuration allows only a specific domain to access resources.
Nginx Example Configuration
location / {
add_header Access-Control-Allow-Origin https://example.com always;
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE" always;
add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
add_header Access-Control-Allow-Credentials true always;
add_header Access-Control-Max-Age 3600 always;
}
This ensures the server returns the correct CORS headers for incoming requests.
Best Practices for Secure CORS Configuration
Follow these recommendations when implementing CORS policies.
- Allow only trusted domains instead of using wildcard origins
- Restrict HTTP methods to only those required by the application
- Limit custom headers to necessary values
- Avoid enabling credentials for public APIs
- Use caching for preflight requests to improve performance
- Regularly audit your CORS configuration for security issues
A restrictive policy that gradually expands as needed is the safest approach.
Testing and Validating Your CORS Policy
After implementing CORS settings, it is important to test them.
- Use browser developer tools to inspect response headers
- Trigger cross origin requests and review the network logs
- Verify that allowed domains can access the resources
- Confirm that unauthorized domains are blocked
Monitoring server logs can also reveal misconfigurations or unexpected access attempts.
Common CORS Misconfigurations
Some common mistakes can expose applications to security risks.
- Allowing all origins for sensitive endpoints
- Combining wildcard origins with credentials
- Allowing unnecessary HTTP methods
- Permitting excessive custom headers
Carefully reviewing these settings helps prevent unintended data exposure.
Conclusion
CORS is a foundational component of modern web security. It enables safe interaction between applications hosted on different domains while maintaining strict browser level protections. Properly configured CORS policies ensure that only trusted clients can access backend resources.
Organizations that rely on APIs, distributed services, and third party integrations should treat CORS configuration as part of their core security strategy. By understanding how CORS headers work and applying best practices, developers can build secure and scalable web applications.