When cookies first appeared in 1994, they were completely allowed by browsers and their usage depended entirely on what developers had in mind. However, a few years after that, due to concerns about privacy and tracking, web developers were advised to obey some practices that make cookie usage safer. Nowadays, some practices are even required by law.

Here we’ll discuss a simple list of dos and dont’s, or in other words, what makes a cookie a good cookie.

  • No sensitive data should be stored inside cookies. If data such as personal addresses, ID card numbers, bank card numbers, and so on needs to be stored somewhere, cookies aren’t the solution;
  • Developers should keep the cookie existing no longer than it’s required. Using session cookies instead of persistent ones and setting an appropriate expiration date for persistent cookies are practices preventing from keeping data for unnecessarily long periods of time;
  • Cookies used for unsubscription purposes should have an expiration date of at least five years;
  • Inspecting and tracking how cookies are being used on the website or on third party websites. When required (like in California), privacy policy page containing information about cookie usage must be created. Also, developers should be aware of the common practices regarding privacy among third-party sites which use these cookies;
  • When developers implement third-party code (using cookies) onto their website, they need to check the settings whether third-party cookies are allowed. Also, they need to check if these third party cookies are compatible with the privacy policy for the site;
  • If required by law (like in the EU), when first opening the website, users must be informed by a message that this website uses cookies. This message should pop up every time until the user clicks a button to agree with that usage. The “agreement” can be stored as a persistent cookie;
  • Security-related cookie attributes must be set properly:
    • Setting the cookie as HttpOnly prevents its access through JavaScript. Malicious websites and users can inject JavaScript to access the cookies of another site (called Cross-site scripting or XSS) and the HttpOnly flag is a good solution against that;
    • Flagging the cookie with Secure assures that this cookie won’t be transmitted by HTTP protocol but only by HTTPS. However, in order for that to work properly, developers need to check is the SSL certificate is installed properly and the website contains no mixed content (resources loaded through HTTP);
    • Flagging the cookie as SameSite guarantees that this cookie won’t be transmitted to any other website but the website it originates from.

Was this post helpful?