What is Cross-Origin Resource Sharing (CORS)
Cross-Origin Resource Sharing (CORS) is a browser security mechanism. It controls how web applications request resources from different origins. An origin consists of a scheme, hostname, and port. Browsers block cross-origin requests by default to prevent security risks. Therefore, CORS defines rules that allow controlled access across origins.
Modern web applications often rely on APIs hosted on different domains, which is why understanding CORS is valuable for frontend and backend integration.
Same-Origin Policy
CORS extends the Same-Origin Policy (SOP). SOP is a core browser security concept that prevents scripts from accessing data from another origin. This restriction reduces risks such as data theft or session hijacking.
For example, a script from https://example.com cannot read responses from https://api.example.net. Without this restriction, malicious sites could access sensitive information. This way, SOP provides a strong security baseline.
How CORS Works
CORS relies on HTTP headers exchanged between the browser and the server. The browser initiates a request and evaluates the server response. If the response includes valid CORS headers, the browser allows access. Otherwise, it blocks the response.
The server defines which origins may access its resources. The browser enforces this decision. It is important to remember that CORS only applies to browsers. It does not prevent direct server-to-server requests.
Simple Requests
Some cross-origin requests qualify as simple requests. These requests do not trigger additional permission checks. A request is considered simple if it meets all required conditions:
- The HTTP method is GET, HEAD, or POST
- Only standard headers are used
- The content type matches predefined values
For these requests, the browser sends the request directly. The server must include the Access-Control-Allow-Origin header in the response. If the value matches the request origin, the browser allows access.
Preflight Requests
Requests that do not meet simple request criteria require a preflight request. The browser sends an OPTIONS request before the actual request. This step verifies permissions. The preflight request includes headers such as:
- Origin
- Access-Control-Request-Method
- Access-Control-Request-Headers
The server responds with allowed origins, methods, and headers. If the response meets browser requirements, the actual request is sent. Otherwise, the browser blocks it.
Preflight requests introduce additional latency. Therefore, efficient configuration improves performance.
Important CORS Headers
CORS behavior depends on specific HTTP response headers. The most relevant headers include:
- Access-Control-Allow-Origin: Defines which origins may access the resource.
- Access-Control-Allow-Methods: Specifies permitted HTTP methods.
- Access-Control-Allow-Headers: Lists allowed custom request headers.
- Access-Control-Allow-Credentials: Indicates whether credentials are permitted.
- Access-Control-Max-Age: Specifies how long preflight results are cached.
Each header has a defined purpose. Misconfigured values commonly cause access errors.
Credentials and Security Considerations
Requests that include credentials require additional restrictions. Credentials can include login cookies or authentication data. Browsers treat these requests as more sensitive. When a server allows such requests, it must be more restrictive. It cannot allow access from all websites.
Instead, the server must specify an explicit origin. Additionally, Access-Control-Allow-Credentials must be set to true. The browser then includes credentials in the request.
This configuration increases security risks if misused. Therefore, allowed origins should be strictly limited. CORS does not replace authentication or authorization. Servers must validate every request independently.
Common CORS Errors
CORS-related errors appear in browser developer tools. These errors can be misleading because the server still processes the request. However, the browser blocks access to the response.
Frequent causes include:
- Missing Access-Control-Allow-Origin headers
- Incorrect origin matching
- Unsupported HTTP methods
- Disallowed custom headers
Troubleshooting typically starts with inspecting response headers. Server logs often do not indicate CORS failures.
Typical Use Cases
CORS is common in API-based architectures. Frontend applications often run on separate domains. APIs must explicitly allow access from these domains.
Additional use cases include:
- Public APIs accessed by external clients
- Browser-based access to microservices
- Development environments using separate hosts
Each scenario requires carefully defined CORS rules.
Configuration Responsibility
CORS configuration always takes place on the server side. Web servers, application frameworks, or reverse proxies can set the required headers. The configuration method depends on the software stack used.
Overly permissive settings simplify development but increase exposure. Therefore, restrictive configurations are recommended for production environments.
