Cross-Origin Resource Sharing (CORS) might seem irrelevant to API developers initially, as it primarily protects Web users from browser-based attacks. However, APIs consumed by Web applications quickly encounter CORS restrictions, becoming directly relevant for developers.
This guide provides API developers with clear insights into what CORS is, why it matters, how related attacks occur, and best practices for securely managing APIs with CORS.
Web pages often load content or resources from multiple origins. Fonts, analytics scripts, or external APIs are common examples of such cross-origin requests. While helpful, this cross-origin functionality introduces potential security risks.
The Screenshot shows requests originating from the Microsoft homepage to different other domains like: bing.com, clicktale.net and contentsquare.net.
Screenshot: Cross Side Requests from Microsoft.com Origin
A CSRF attack tricks a user's browser into performing actions without their consent, exploiting existing authentication sessions. Consider this banking scenario: A user logs into her bank account but forgets to log out, leaving an active session cookie. Later, while casually browsing the web, the user visits a malicious website that returns (1) hidden JavaScript code (2). This script sends a request to the bank to transfer money into the attacker's account (3). The browser automatically attaches the user's valid session cookie to this request (4). If the session hasn't expired, the bank processes the request, transferring funds to the attacker (5).
Image: CSRF Attack against API
Modern browsers prevent CSRF attacks through the Same-Origin Policy, restricting cross-origin HTTP requests initiated by scripts. This policy ensures scripts can only access resources from the same origin, enhancing security but complicating legitimate API integrations.
Fortunately, there is a mechanism that allows a page to use resources from a different origin. Otherwise, it would not be possible that your API gets used on Web pages from other developers.
The simplest approach is to avoid the cross-origin problem. In a typical Web application, the Web pages and the API is hosted on the same computer. The pages and the API have the same origin therefore CORS does not apply.
Hosting web pages, scripts, and APIs on a single server isn't always practical, especially in large projects where frontend and backend systems are deployed separately. To effectively bypass CORS restrictions in such scenarios, an API gateway can be positioned in front of backend services. From the client's perspective, the gateway consolidates multiple backends into a single, unified host.
Image: API Gateway in front of Web Server and API
However, not all APIs can or should be concealed behind an unfied host, especially when offering services for integration on external Web pages. In such cases, explicitly enabling CORS provides the necessary solution.
CORS enables your API to inform the web browser that it's safe to integrate the API into a web page.Here's how the process works:
Initially, the browser loads a webpage from a server as usual (1). If the page needs to access an API hosted on another server, the browser makes an additional "preflight" request using the OPTIONS method (2). This request asks the API server whether it permits resources to be used by pages originating from a specific domain, such as www.predic8.de. The browser includes information about the origin, requested methods, headers, and possibly credentials (2).
The API server or API gateway evaluates this request and decides whether to allow it (3). It then sends back specific CORS headers indicating permission (4). The browser receives these headers and makes the final determination (5). If allowed, the browser proceeds to make the actual API call (6).
Image: CORS with APIs Step by Step
Before enabling API integration for Web pages, carefully assess what the API does and ensure it is secure for the usage.
API gateways typically provide two straightforward methods to support CORS:
Choose the method that best aligns with your API's specific requirements and security considerations.