cookies with missing SameSite attribute create thousands of issues in Chrome/Edge Developer tools

06-08-2021 04:41 PM
New Contributor II

When you sign into ArcGIS Online, some cookies are stored in the browser for the domain Then, when you browse a web page served in a different domain and referencing the ArcGIS API for JavaScript via CDN, those cookies act as third-party cookies and could potentially be added to the hundreds of requests made to get the JavaScript files of the ArcGIS JS API.

Chrome and Chromium browsers (such as Edge) create an issue for every request and cookie with the following message:

Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute
Because a cookie’s SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which prevents the cookie from being sent in a cross-site request. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.
Resolve this issue by updating the attributes of the cookie:
 - Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.
 - Specify SameSite=Strict or SameSite=Lax if the cookie should not be sent in cross-site requests.

The creation of thousands of issues blocks the Developer tools for 1-2 minutes, during which time neither messages appear in the console nor it is possible to refresh the page. Is there any solution for this?

I'm using the ArcGIS API for JavaScript 4.19. Any code referencing the API will reproduce this issue, but you can find an example below.


  <meta charset="utf-8" />
  <meta name="viewport" content="initial-scale=1,maximum-scale=1,user-scalable=no" />
  <title>Sketch widget | Sample | ArcGIS API for JavaScript 4.19</title>

  <link rel="stylesheet" href="" />
  <script src=""></script>

    #viewDiv {
      padding: 0;
      margin: 0;
      height: 100%;
      width: 100%;
    ], (Map, MapView, GraphicsLayer, MapImageLayer, SketchViewModel) => {

      const mapImageLayer = new MapImageLayer({
        url: ""
      const graphicsLayer = new GraphicsLayer();

      const map = new Map({
        layers: [mapImageLayer, graphicsLayer]

      const view = new MapView({
        container: "viewDiv",
        map: map,
        scale: 75000

      view.when(() => {
        const sketch = new SketchViewModel({
          layer: graphicsLayer,
          view: view,
          defaultCreateOptions: { hasZ: false }
        sketch.on("create", evt => {
          if (evt.state === "complete") {

  <div id="viewDiv"></div>


6 Replies
New Contributor III

Esri folks, any advice on this? It is causing me some major issues as well. My load time methods can't be debugged as the debugger is frozen processing the nearly 2000 issues. 

Anyone know of a way to disable the debugger from logging these issues?


New Contributor III

Does anyone have a workaround? This has become a very frustrating problem for me, too. I'm having to wait for 6,000 - 8,000 issues to be logged before my internally hosted application finishes loading. It's a fairly simple 4.19 API application. I really wish we could get ESRI's input on this.

New Contributor II

This is an major issue! ESRI should react asap!

New Contributor II

We ended up hosting everything on our own server.

0 Kudos
New Contributor III

Hi, seems this is a conflict between the cookie set by the JS Api (on Esri's CDN) and the ones set by other Esri pages like documentation etc. Clearing the app site data (in chrome dev tools-> Application), closing the other pages and use another browser (like FF) for documentation solved it for me ...

New Contributor III

Yes, this is the answer/explanation. Thanks for posting.

I also discovered this and should have mentioned it in an update after my original reply. The API is not so much to blame. It's the API documentation pages where you start to accumulate many cookie issues. ESRI should hopefully make adjustments on their side with the documentation, but for now we'll have to use a different browser to avoid getting a high issue count.

On a related note, we also discovered something with our internal facing web server used for hosting the secure JS API web application. If we use the fully qualified name in the application URL it will not have any cookie issues generated from this server. (i.e. "" instead of just "servername/myapplication")