Enabling CORS for integration with other apps

  • Last updated: May 17, 2022

  • Read time: 3 Minutes

If you want to integrate Burp Suite Enterprise Edition with a third-party application, or an application that you've developed yourself, it probably needs access to your sites and scan data. This can be achieved using our GraphQL API. However, in the case of web applications that rely on JavaScript running in the user's browser, you first need to enable cross-origin resource sharing (CORS) between Burp Suite Enterprise Edition and the other application. This is simply a case of adding its origin to a whitelist.

Once you've whitelisted the origin on which your other application is running, its client-side JavaScript will have access to the full functionality exposed by Burp Suite Enterprise Edition's GraphQL API. This allows you to develop more powerful integrated applications that can fetch the relevant data, create and edit sites, and launch new scans directly from the browser using AJAX.


Even if you're integrating Burp Suite Enterprise Edition with your CI/CD system using our native plugins, you will still need to whitelist your Jenkins or TeamCity URL in order to use the "Burp site-driven scan" option.

How to whitelist an application for CORS in Burp Suite Enterprise Edition

You can whitelist an application for CORS from the Burp Suite Enterprise Edition network settings page.

  1. Log in to Burp Suite Enterprise Edition as an administrator.
  2. From the settings menu, go to the "Network" page.
  3. In the "Allowed Origins for GraphQL API" section, enter the origin on which the other application is running. Note that this should include URL scheme, domain name, and port. You can whitelist as many origins as you want, each separated by a new line. For example:

    https://third-party-app.com:8082 https://custom-app.your-company.net:8083
  4. Double-check your entries and click "Save".
  5. Test your external application to make sure that it now works as expected. If you still run into CORS-related issues, examine the Origin header of the associated request and compare this to the URLs that you have in the whitelist. There should be no discrepancies.


The origin of incoming requests refers only to the URL scheme, domain name, and port. In other words, you can whitelist all cross-origin requests from https://example.com:8080 but you cannot restrict this to specific subdirectories such as https://example.com:8080/my-app. For more granular control, you need to deploy your application to a dedicated subdomain: https://your-app.example.com:8080

Why do I need to do this?

The same-origin policy aims to prevent scripts running on one website from accessing and interacting with data on another website. This is an important security mechanism. If we didn't enforce the same-origin policy, arbitrary external websites would potentially be able to access sensitive data from your Enterprise server.

However, in some cases, you may want to enable cross-origin resource sharing (CORS) between Burp Suite Enterprise Edition and a trusted application. For exactly this scenario, we've created a whitelisting function. Client-side JavaScript in your application will only be allowed to access your data if the value of the Origin header in the corresponding HTTP request matches an origin that you have explicitly whitelisted.

Read more

For more information about CORS, the same-origin policy, and the related security implications, please refer to the corresponding topic on our Web Security Academy.

Cross-origin resource sharing