Links may not function; however, this content may be relevant to outdated versions of the product.
Defining cross-origin resource sharing (CORS) policies
Cross-origin resource sharing (CORS) policies define a method that enables a browser and server to interact and determine whether it is safe to allow a cross-origin request. For example, a client using a Pega Marketing application running in a browser, may see advertisements from third-parties, and if they click one of these advertisements, the CORS policy will record that the advertisement was viewed or clicked on.
Using CORS policies results in reduced costs and implementation times while providing increased security as other systems or websites interact with your application.
To configure a CORS policy, you complete two main tasks:
- Define the CORS policy for a REST service by specifying the allowed origins, allowed headers, exposed headers, allowed methods, credential usage, and preflight expiration time.
- Map the CORS policy to an endpoint (URL or path) for the REST service that you want to protect.
- Creating a cross-origin resource sharing (CORS) policy
By creating a cross-origin resource sharing (CORS) policy and subsequently mapping it to an application REST endpoint (path or URL), you control whether and how other systems or websites (origins) can access that resource.
- Mapping an endpoint to a cross-origin resource sharing (CORS) policy
The purpose of a CORS policy is to enable cross-domain requests. In Pega Platform, CORS policies can only be associated with REST services. When setting up cross-origin resource sharing (CORS) policies, you must map to a REST endpoint to specify which CORS policies apply to it. By doing so, you define which domains are allowed to access these resources within your Pega application.
Previous topic Testing a custom application header Next topic Creating a cross-origin resource sharing (CORS) policy