Skip to main content

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

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Understanding Cross-Site Request Forgery (CSRF)

Updated on July 1, 2021

Cross-Site Request Forgery (CSRF) is an attack that forces a user to execute unwanted actions on a web application in which the user is currently authenticated. CSRF specifically targets state-changing requests, not data theft, because the attacker cannot see the response to the forged request. With a little help of social engineering (sending a link in email or chat), an attacker can trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force users to perform state-changing requests including transferring funds or changing their email address. If the victim is an administrative account, CSRF can compromise the entire web application.

Mitigating CSRF attacks

Pega Platform uses session tokens to mitigate the risk of CSRF attacks. Each user session is assigned one or more unique tokens. These tokens are made available to the browser for inclusion in the URL of all requests. Each request is examined for a valid token and is rejected, if either no token or an invalid one is provided. Exceptions can be configured based on the values of the HTTP Referrer header contained in the request.

Cross-site request forgery settings

To obtain the values to include in the cross-site request forgery (CSRF) mitigation lists, enable CSRF mitigation, and then perform a detailed test of the application. You can capture the requests that fail because of the CSRF protection. From the requests, identify the activities, streams, and referrer headers, and add them to these settings. For more information, see Configuring CSRF protection.

Use the Cross-Site Request Forgery landing page to modify these settings, the information settings is defined in the table below:

PurposeDefaultSecureSecurity Implications
Security/CSRF/mitigationfalsetrueEnables the CSRF mitigation feature.
Security/CSRF/secured/ActivitiesblankSpecify a comma-delimited list of activities to secure.A request for an activity in this list must include a valid CSRF token.
Security/CSRF/securedStreamsblankSpecify a comma-delimited list of streams to secure.A request for a stream in this list must include a valid CSRF token.
Security/CSRF/validReferersblankSpecify a comma-delimited list of valid referrers for incoming requests.If CSRF token and activity/stream validations fail, the referrer header is validated against this list. The request fails if the referrer header is not on the list.
Security/CSRF/secureallfalsetrueIndicates that all activities and streams must include a valid CSRF token, with no exceptions.
XML/AllowDocTypesfalsefalsePrevents parsing of DOCTYPE declarations in XML. Protects against XML External Entity attacks (XXE).
  • Enabling and configuring Cross-Site Request Forgery settings

    Configure cross-site request forgery settings (CSRF) to prevent users from unintentionally making changes because of a CSRF attack. You can set validation for activities and streams, add host names to an allow list, and specify host names that you want checked for a CSRF token.

  • Previous topic Mitigating common security vulnerabilities
  • Next topic Enabling and configuring Cross-Site Request Forgery settings

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. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us