Chrome 80 breaks PunchOut
Update: Google is delaying the change to the SameSite cookies until the week of February 17th, 2020. Additional information is available here.
Google is scheduled to release Chrome version 80 on February 4th, 2020 which includes changes to the way cookies work. Many PunchOut sites will stop working in Chrome 80 until eProcurement systems and PunchOut sites are updated.
Background
Cookies are the de facto standard for managing sessions on websites. Typically, when a user logs in to a website, a cookie is set in the user’s browser that contains a random unique identifier of 30+ characters. This is known as a session ID. Subsequent requests sent by the user’s browser to the website include the session ID as a method of proving to the website who the user is. Cookies are the feature in browsers that facilitates storing the session ID and sending it to the browser with each request. PunchOut sites typically use cookies to keep track of which user is logged in and what items are in their shopping cart.
Unfortunately, hackers have found ways to intercept session ID cookies that effectively allow them to impersonate a logged in user on a website. The changes to Chrome 80 are intended to make intercepting cookies more difficult thus making the internet more secure. However, these changes also have the side-effect of breaking functionality that is core to how PunchOut works.
PunchOut and Frames
Many eProcurement systems that support PunchOut wrap PunchOut sites in a frame. The primary reason for doing this is to give the end-users a consistent way to return to the eProcurement system. A small banner can be displayed above the PunchOut site content with a "Return to eProcurement system" link. Without the banner, users would need to rely on using the back button or bringing back a cart to return to the eProcurement system. This is a shortcoming of the cXML PunchOut/OCI RoundTrip standards that Ariba itself addresses by using a frame.
A secondary benefit of the frame is that it allows the eProcurement system to send "ping requests" back to itself to extend the user’s session. Without the ping requests, the user’s session will eventually expire and they will no longer be logged in when they return their shopping cart from the PunchOut site.
PunchOut sites displayed in frames typically need to set cookies to keep track of the user’s session. These cookies are known as 3rd-party cookies because they are not set by the parent URL (the URL for the eProcurement system). Chrome 80 will block 3rd-party cookies that don’t include a "SameSite=None" attribute and are marked "Secure". The majority of PunchOut sites do not set these attributes on their cookies so they will no longer work inside of frames.
The two options for resolving this issue are for the eProcurement system to stop embedding PunchOut sites in frames or for the supplier to update their cookies to include the "SameSite=None" and "Secure" attributes.
In recently circulating emails, Ariba is asking their PunchOut suppliers to update their cookies. This suggests that Ariba does not plan on removing the frame. It will be interesting to see how many of Ariba’s thousands of PunchOut suppliers make this change within a reasonable time frame.
PunchOut and Sessions
In addition to the frame issue, Chrome 80 will also start blocking non-compliant cookies set by the eProcurement system when the shopping cart is posted back.
cXML and OCI shopping carts are sent from the PunchOut site to the eProcurement system via an HTML <form> tag that includes hidden input fields containing the shopping cart data. The form tag submits the data to the eProcurement system in the user’s browser via an HTTP(S) POST request. When the eProcurement system receives the HTTP(S) POST request, it needs to determine which user the cart is coming back for and import the shopping cart items into the user’s requisition/active cart. Typically the user’s session cookie for the eProcurement system is present so the user is automatically recognized based on the cookie. If the cookie doesn’t include the "SameSite=None" and "Secure", it’s no longer going to be included with the shopping cart HTTP POST request. This may result in the user seeing a login screen when they are expecting to see their imported cart.
Note: The cXML BuyerCookie element is not a reliable method for authenticating users because the value is shared with the supplier. More information regarding this is available here.
Where do we go from here?
Many eProcurement systems and PunchOut sites will need to make changes to ensure compatibility with Chrome 80. The simple fix is to add the "SameSite=None"/"Secure" attributes to all cookies and force all traffic to HTTPS. Unfortunately, this is not as simple as it sounds. Certain browsers will completely ignore cookies that have the aforementioned attributes. Patching legacy ERP systems that are hosted on premise may be the biggest challenge. PunchOutCommerce has developed a remediation guide that provides different strategies for resolving these issues here.
While many companies will scramble to get out patches in the short-term, the real question is how do we prevent things from getting to this point in the future? Why are so many PunchOut sites relying on browser features that are considered so insecure that the browser with the majority of the market share was willing to take the features away in a single release? Why doesn’t cXML or OCI address the need to add a uniform return link to the top of every PunchOut site? Why doesn’t cXML include something to keep eProcurement sessions alive while users shop on PunchOut sites?
The fact that it has gotten to this point really highlights how neglected the cXML standard has been under SAP’s control. As the major browser vendors continue to innovate and improve security, cXML remains largely unchanged. The official cXML website doesn’t even contain a mention of the upcoming changes to Chrome.
There are options for moving cXML forward without SAP. If competing eProcurement vendors, PunchOut eCommerce vendors, and suppliers could join together, informal standards could be agreed upon to improve PunchOut.