How to fix CORS errors when using Burst Statistics across different domains

If you’re using the Burst tracking endpoint from a different domain (for example, tracking from staging.yoursite.com to analytics.yoursite.com), you may run into an issue caused by CORS. In this article, we’ll explain what CORS is, why it’s important, how it affects Burst Statistics, and how to fix any related errors.

What is CORS?

CORS stands for Cross-Origin Resource Sharing. It’s a security feature built into all modern browsers. By default, browsers block JavaScript from making requests to a different domain than the one the user is currently on.

For example, if your site is running on https://staging.yoursite.com, and it tries to send tracking data to https://analytics.yoursite.com, the browser will check whether the server on analytics.yoursite.com allows requests from that origin.

If the server doesn’t send the correct headers, the browser will block the request, even if the server responds successfully.

When does CORS become a problem?

CORS is only an issue when the Burst tracking endpoint (endpoint.php) is being called from a different domain than where it’s hosted. If your site and the Burst plugin are running on the same domain (e.g. both on www.example.com), then CORS is not relevant.

However, in setups where the plugin is running on a centralized analytics domain, and tracking happens from multiple other domains, CORS must be handled correctly.

This often happens in:

• staging vs. production environments,
• headless or decoupled frontends,
• websites using a subdomain specifically for analytics.

What kind of errors does this cause?

When CORS is not set up properly, you might see errors in the browser’s developer console like:

Access to fetch at 'https://analytics.example.com/wp-content/plugins/burst-pro/endpoint.php'
from origin 'https://staging.example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Or:

OPTIONS https://analytics.example.com/wp-content/plugins/burst-pro/endpoint.php 500 (Internal Server Error)

The second error occurs because browsers often send a preflight request — an OPTIONS request — before the actual POST. If the server doesn’t handle this correctly, it results in a 500 error.

These messages mean that the browser blocked the request, even if the server responded correctly. This happens when CORS headers are missing or incorrect. As a consequence, your tracking will not work correctly.

When to configure Burst for CORS

As of version 2.2.2, Burst Statistics now includes built-in handling for CORS on its tracking endpoint. If you prefer not to allow all origins, you can define a constant in your wp-config.php file to control it:

define( 'BURST_ALLOWED_ORIGINS', 'www.example.com,staging.example.com' );

This is optional. If the constant is not defined, the Burst endpoint will not set any CORS headers, as it is in previous versions.

Summary

• CORS is only relevant when tracking across domains.
• You don’t need to configure anything if Burst is used on the same domain as your website.
• If you use Burst on a separate domain or subdomain, the plugin now supports cross-origin tracking.
• You can optionally restrict CORS using the BURST_ALLOWED_ORIGINS constant.

If you’re still seeing CORS errors or need help setting this up, feel free to reach out to our support team.