Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Creating a cross-origin resource sharing policy

Updated on March 15, 2022

By creating a cross-origin resource sharing (CORS) policy and subsequently mapping it to an application endpoint (path or URL) for an API or service, you control whether and how other systems or websites (origins) are permitted to access that resource.

Before you begin: To create or modify CORS policies you must have the pzCanManageSecurityPolicies security privilege, which the PegaRULES:SecurityAdministrator role includes.
  1. In the header of Dev Studio, click Create Security Cross Origin Resource Sharing.
  2. On the Cross Origin Resource Sharing form, in the Short description field, enter a description of the CORS policy.
  3. In the Policy name field, enter a name for the CORS policy. You might name the policy for an endpoint, or for the API or REST service that you want to protect.
  4. Click Create and open.
  5. On the Cross Origin Resource Sharing form, on the Policy Definition tab, select the Allow credentials check box to indicate that requests to the endpoint can include credentials.
  6. In the Allowed origins field, enter a comma-separated list of domains (origins) that are allowed to make a request against the API or REST service.
    At run time, the system evaluates all origins that you specify for this setting until it finds a match for the origin header of the request. Wildcard characters are also supported.
    For example:
    • www.abc.com – Allows requests from the host that you specify.
    • *.abc.com – Allows requests from any site hosted in the abc.com domain.
    • * – Allows requests from any website. Use this value only if you want to give public access to the API or REST service.
    • Null (blank) – Does not allow any access requests.
  7. In the Maximum age field, enter a number to specify how long, in seconds, the results of a preflight request can be cached.
    This is the time period between two consecutive preflight requests, within which you do not want the web browser to send a new preflight request. A longer period reduces the frequency of browser preflight OPTIONS method call requests.
    For example: A web browser sends a preflight request to the GET /cases service 300 seconds after accessing the GET /assignments service.
    • If you set the maximum age to 400, the browser does not send another preflight request for the GET /cases service.
    • If you set the maximum age to 200, the browser sends a preflight request for the GET /cases service.
  8. In the Allowed methods section, select one or more check boxes to specify which request methods are allowed: GET, POST, PUT, PATCH, or DELETE.
  9. In the Allowed headers section, enter a comma-separated list of the request header values that the origin domain is allowed to use for a CORS request.
    The authorization and content-type headers are required for Pega Platform applications.

    The default value is: authorization, content-type

  10. In the Exposed headers section, enter a comma-separated list of response headers that clients of this API or service can access.
  11. Click Save.
What to do next: After you create a CORS policy, you must map the CORS policy to an endpoint to determine where the policy is applied.
  • Previous topic Defining cross-origin resource sharing policies
  • Next topic Mapping an endpoint to a cross-origin resource sharing policy

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us