How to Prevent fetch and XMLHttpRequest Overrides in CookieYes

Last updated on April 29, 2025

Overview

Certain websites override native browser APIs like fetch and XMLHttpRequest to implement their own custom network logic. Although this may serve specific purposes, it could unintentionally conflict with third-party scripts such as CookieYes, relying on these native methods to function correctly. This often results in the CookieYes banner not loading or rendering correctly.

CookieYes now offers a fallback mechanism, ensuring that the banner continues to operate in such environments. This enables developers to retain the default implementations of fetch and XMLHttpRequest prior to any custom overrides taking place. A small script injected right at the top of the <head> tag could store the untouched versions of both these APIs inside a CookieYes-specific object. CookieYes would use these preserved methods for all critical consent banner-related network requests, ensuring the CMP functions reliably, regardless of modifications made by other scripts on the page. This guide outlines how to implement and use this script, along with integration steps and best practices.

Default Behaviour in CookieYes

CookieYes, by default, relies on the native fetch and XMLHttpRequest methods implemented by the browser itself to load banner data. If other scripts loaded earlier in the page lifecycle override or proxy these methods, they may disrupt CookieYes’s functionality, particularly the consent banner.

To prevent this, it is now possible for developers to inject a configuration snippet that would preserve these native methods before any potential overrides occur explicitly.

How to Preserve Native Functions

Step 1: Insert the custom script at the top of the <head> tag.

Add the following script right of the <head> section before any other third-party or custom scripts. This ensures that the original fetch and XMLHttpRequest functions are saved before any modifications are made.

<script>
  window.ckySettings = window.ckySettings || {};
  window.ckySettings.nativeFunctions = {
    fetch: window.fetch,
    xhr: window.XMLHttpRequest
  };
</script>

Step 2: Ensure the custom script is placed before the CookieYes script

If the CookieYes banner script is already included on your website, make sure that the custom script is placed above it in the <head> section of the HTML. This will ensure that the native fetch and XMLHttpRequest functions are stored before CookieYes initialises.

Example Implementation

Here’s a complete example of how to implement native API preservation on a webpage using CookieYes:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Preserve Native APIs Example</title>

  <!-- Preserve native fetch and XMLHttpRequest -->
  <script>
    window.ckySettings = window.ckySettings || {};
    window.ckySettings.nativeFunctions = {
      fetch: window.fetch,
      xhr: window.XMLHttpRequest
    };
  </script>

  <!-- CookieYes Script -->
  <!-- Start cookieyes banner -->
  <script id="cookieyes" type="text/javascript" src="https://cdn-cookieyes.com/client_data/XXXXXXXXXXXXXXX/script.js"></script>
  <!-- End cookieyes banner -->

  <!-- Example: Other scripts that may override fetch/xhr -->
  <script src="/scripts/custom-logger.js"></script>
  <script src="/scripts/network-interceptor.js"></script>
</head>
<body>
  <!-- Your website content here -->
</body>
</html>

Conclusion

CookieYes ensures continuous consent management and banner rendering in all environments by preserving the state of the native browser APIs before they are overridden. Implementing this configuration helps maintain stability and compatibility, especially in complex websites with extensive custom scripting.

Have more questions?

Reach out to us and we'll answer them.

Contact us