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 July 1, 2021

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: You must have the pzCanManageSecurityPolicies security privilege, which is included in the PegaRULES:SecurityAdministrator role, to create or modify CORS policies.
  1. In the Dev Studio header, click Create Security Cross Origin Resource Sharing.
  2. In the Short description field on the Cross Origin Resource Sharing form, 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 intend to protect.
  4. Click Create and open.
  5. On the Policy Definition tab of the Cross Origin Resource Sharing form, select the Allow credentials check box to indicate that credentials are permitted in requests to the endpoint.
  6. For the Allowed origins option, 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 a match is found for the origin header of the request. Wildcard characters are supported, as in the examples shown below.
    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, 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