Совместное использование ресурсов между источниками (CORS)

Welcome! Today we'll explore Cross-Origin Resource Sharing (CORS), a crucial security feature for modern web applications.

CORS allows web browsers to securely handle requests between a client-side application (like a Single-Page Application, SPA) and an API server when they're on different domains.

This is especially vital when your SPA uses OAuth2 or OpenID Connect to access protected resources.

To understand CORS, we first need to know about the Same-Origin Policy (SOP).

• SOP is a fundamental browser security feature.
• It prevents web pages from making requests to a different domain than the one that served the page.
• For example, a script from app.example.com cannot directly make an AJAX request to api.anothersite.com.

This protects users from malicious scripts trying to steal data from other sites you're logged into.

While SOP is great for security, it creates a problem for modern web architectures.

Many applications, especially SPAs, need to fetch data from APIs hosted on a different domain or port. For instance:

• Your SPA is at https://my-app.com
• Your API is at https://api.my-app.com
• Your OAuth2 Authorization Server is at https://auth.my-app.com

CORS provides a controlled way to relax the SOP, allowing these cross-origin requests while maintaining security.

Some cross-origin requests are considered 'simple' by browsers. These don't trigger a special preflight check.

A request is simple if it meets all these conditions:

• Method is GET, HEAD, or POST.
• Only specific allowed headers (e.g., Accept, Accept-Language, Content-Language, Content-Type).
• Content-Type header is limited to application/x-www-form-urlencoded, multipart/form-data, or text/plain.

If simple, the browser sends the request directly, and the server includes CORS headers in its response.

Most requests in modern SPAs, especially those involving OAuth2 tokens, are not simple.

A 'complex' request requires a browser to send a 'preflight' OPTIONS request before the actual request:

• Methods: PUT, DELETE, or custom methods.
• Headers: Custom headers (like Authorization for access tokens).
• Content-Type: application/json (common for APIs).

The server must respond to this OPTIONS request with appropriate CORS headers, indicating if the actual request is allowed.

The server communicates its CORS policy through specific HTTP response headers:

• Access-Control-Allow-Origin: Specifies which origins are allowed to access the resource. Can be * (wildcard, generally discouraged for security) or a specific origin like https://my-app.com.
• Access-Control-Allow-Methods: Lists the HTTP methods (e.g., GET, POST, PUT, DELETE) allowed for the resource.
• Access-Control-Allow-Headers: Indicates which HTTP headers (e.g., Authorization, Content-Type) are allowed in the actual request.

These headers are crucial for the browser to permit the cross-origin request.

The Access-Control-Allow-Credentials header is another important CORS header.

When set to true, it tells the browser that the server permits cookies, HTTP authentication, or client-side SSL certificates to be included with the cross-origin request.

For OAuth2/OIDC, access tokens are typically sent in the Authorization header, not as cookies. However, if you're using session cookies for authentication or identity management alongside tokens, this header becomes relevant.

CORS is essential at several points in OAuth2/OIDC:

• Token Exchange: Your SPA might need to exchange an authorization code for an access token at the Authorization Server's token endpoint. This is a cross-origin POST request.
• API Access: Once your SPA has an access token, it uses it to call a Resource Server's API (e.g., GET /userinfo, POST /orders). This is also a cross-origin request.

The Authorization Server and Resource Server must be configured correctly to allow these requests from your SPA's origin.

To ensure secure OAuth2/OIDC implementations with CORS:

• Specific Origins: Always specify exact origins (e.g., https://my-app.com) in Access-Control-Allow-Origin, never use * in production.
• Limit Methods & Headers: Only allow the HTTP methods and headers that your client applications genuinely need.
• Configure Servers: Ensure your Authorization Server and Resource Server are correctly configured to send the necessary CORS headers.
• Handle Preflights: Make sure your server can respond to OPTIONS requests for preflight checks.

Misconfigured CORS can lead to security vulnerabilities, allowing unauthorized access.

Your SPA at https://my-app.com needs to make a POST request with an Authorization header and Content-Type: application/json to your API at https://api.my-app.com/data. Which CORS response headers should the API server include to allow this?

You've learned about Cross-Origin Resource Sharing (CORS) and its vital role in securing modern web applications, especially those leveraging OAuth2 and OpenID Connect.

• CORS relaxes the browser's Same-Origin Policy.
• It enables secure communication between different origins.
• Preflight requests for 'complex' API calls are common with OAuth2 tokens.
• Proper server-side configuration of CORS headers (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers) is key.

Always follow best practices to prevent misconfigurations that could expose your protected resources.