Rogier Lankhorst

@keeleon This is due to a security configuration by your server, we don’t have any control over that within Burst.

I don’t know much about Mod Security, so I’ve checked with AI what possible solutions there are for such an issue. Let me know if this is helpful!

————-

This is a well-known ModSecurity/JSON parsing conflict. The error “Cannot add scalar value without an associated key” means ModSecurity’s request body processor is trying to parse the JSON payload sent by Burst Statistics to /wp-json/burst/v1/track/, but the JSON structure contains array-style or scalar values at the root level that confuse the parser.

The cleanest fix is a targeted rule that overrides the body processor for that specific URI, keeping all other rules intact.

Option 1: Switch the body processor to URLENCODED for that endpoint (recommended)

Add this to your custom ModSecurity rules file (e.g. /etc/modsecurity/custom-rules.conf or inside a .conf file in your modsecurity.d/ directory):

apache

SecRule REQUEST_URI "@beginsWith /wp-json/burst/v1/track" \
    "id:9009001,\
    phase:1,\
    pass,\
    nolog,\
    ctl:requestBodyProcessor=URLENCODED"

This tells ModSecurity to treat the body as plain URL-encoded data instead of trying to parse it as JSON, so no parsing error occurs and the request goes through. All other rules keep running.

Option 2: Disable request body inspection for that URI only

If option 1 doesn’t fully resolve it:

apache

SecRule REQUEST_URI "@beginsWith /wp-json/burst/v1/track" \
    "id:9009001,\
    phase:1,\
    pass,\
    nolog,\
    ctl:requestBodyAccess=Off"

This turns off body inspection entirely for that endpoint. Slightly broader, but still highly targeted since it only applies to that one URI.

If you deactivate WordFence, does it resolve the issue?

Can you share a link to this site so I can take a look? If there’s an issue with tracking I should be able to see what the problem is from the front-end.

Hi @krysztofiakpatrice,

Good to hear you like Burst Statistics! We don’t have a default lifetime license offer on our website, but we can always discuss. As we’re not allowed to discuss premium plugins on this forum, please contact us directly at support(at)burst-statistics.com.

Awesome! Glad it’s been resolved!

Can you copy the console errors in the browser, by right clicking on the screen, then click “inspect element”, “console”, then copy the errors you see there (instructions for Chrome).

This should tell us more.

@lekkerbezig I’ve done some tests, but with default WordPress user roles there’s nothing in itself that prevents tracking. Possibly the templates for logged-in pages do not have the correct WordPress hooks required for the scripts to hook into. But hard to say without knowing the setup in more detail.

What is your setup? If I can recreate your configuration I can probably tell you more.

@slavomir12 thanks for the information! Interesting. I suspect this is because AdGuard just blocks anything that has ‘burst’ included in the javascript source. Because anything on our site loads over a domain with ‘burst’ in it, all resources are blocked.

Same goes for the back-end scripts. These load over the burst-statistics plugin directory, which apparently gets flagged.

I don’t think there’s anything we can do to fix such brute force blocking.