Cookies

This document outlines best practices for managing cookies within iFrames, which is essential for maintaining sessions within plugins for the Kizen ecosystem. This guide also covers the basics of cookie domains and explains how partitioned cookies work.

Cookies in iFrames

When working with iFrames, cookies behave differently compared to cookies set directly from a first-party context. When you build a plugin that frames your application into Kizen, your application operates in a third-party context, meaning that the cookies set or accessed within them are subject to stricter privacy and security rules.

Standard attributes like SameSite, Secure, Domain and HttpOnly continue to apply. There is also a Partitioned attribute that can be set in Chromium browsers to allow for cross-site cookies to function securely. See Google’s guide on cookies for a full list of attributes.

Partitioned Cookies

Partitioned cookies are a privacy-enhancing measure where cookies are isolated by the top-level site (i.e., the site that appears in the browser’s address bar). This means that even if a cookie is set in an iFrame, it is partitioned by the top-level domain. Chromium-based browsers currently provide support for partitioned cookies, but browsers without support fall back on the default cookie behavior.

Partitioned cookies can be applied via the Partitioned=true attribute. Its important to also correctly apply the Domain attribute to ensure frontend Javascript code can read the cookies. For example, Domain=.example.com

Partitioning prevents a third-party service embedded via an iFrame from tracking a user across different sites. Each site gets its own isolated instance of the cookie. For cookies using SameSite=None, partitioning will ensure these cookies continue to work in Chromium browsers with Google’s removal of cross-site cookies.

Clearing and Updating Cookies in iFrames

We recommend avoiding manipulating partitioned cookies directly from front-end Javascript, due to differences in browser support. Instead, your application’s server should handle setting, modifying, and deleting cookies, especially if your application expects to be embedded in the Kizen application through a plugin.

Limitations of Clearing Cookies

Chromium browsers do not allow modifying or deleting partitioned cookies from front-end Javascript if your application is framed into a site using a different domain. This means that attempting to clear/update these cookies using JavaScript from within an iFrame will not work as expected, and will differ from other browsers such as Safari.

Recommended Server Approach

Given this limitation, all cookie clearing operations for partitioned cookies should be implemented at the server level. Your API should send a response with the Set-Cookie header that clears the cookie. This typically involves setting the cookie’s value to an empty string, its expiration date to a past date, and match all the attributes applied to the cookie.

Example (Using Node.js/Express):

// This express handler responds with a Set-Cookie header that clears the cookie defined by the parameters
 
app.get('/clear-cookie', (req, res) => { 
  // Set the cookie with an expired date to instruct the browser to clear it 
  res.cookie('myCookie', '', { 
    expires: new Date(0), 
    path: '/', 
    secure: true, 
    httpOnly: true, 
    domain: '.example.com', 
    partitioned: true 
  });

 res.send('Cookie cleared on the server.'); 
});

Browser Support for Partitioned Cookies

The table below summarizes the current support for partitioned cookies across major browsers. If the browser does not support partitioned cookies they will be accessible at top level domains and can also be modified. In time this standard is expected to be adopted by all browsers, as cross-site and third-party cookies are fully phased out.