From Chrome 62, Google have announced that they will start marking sites that accept form data over HTTP as "not secure". As an operator of an ecommerce site, this will probably affect you.
Their blog has provided an example of how this will look:
As a reminder, all sensitive data on your SuiteCommerce site must be sent over a HTTPS connection, secured with a security certificate. Doing so encrypts the data, making it very difficult for nefarious individuals to intercept a user's personal details (such as their address, password and card data).
By, default, only the account and checkout section of our sites are encrypted over HTTPS, with the shopping section being served over HTTP. This is fine. At no point in the shopping application should (or is) sensitive personal data sent over HTTP. However, it is still possible to have forms in the shopping application that are used to collect non-sensitive data. The most common example is the newsletter signup form. So what can you do?
Well, I think there are three ways forward:
- Do nothing — when the user goes to enter form data, they will warned that it's insecure
- Remove insecure forms — at no point offer forms in the shopping application, and only collect data in secure sections of the site
- Offer HTTPS throughout the site — secure the entire site so there are no insecure forms
The problem with number 1 is this could be worrying to customers. While you and I understand that there's minimal risk to submitting non-sensitive data over HTTP, a layperson will see "not secure" and potentially panic and either not complete the action, or leave the site entirely. This could cost you business.
Number 2 isn't feasible either. While it would work something like newsletter signup, the biggest problem is that this change also affects your search box. Yes, if someone starts a keyword search on an insecure page, Chrome is going to flag that.
The third option is what we recommend. This is what we call a secure shopping domain and it's been available since Elbrus, but it can patched to the modern versions of SCA (Vinson, Mont Blanc and Denali) and pre-Denali SCA sites.
I've provided a link to the documentation above, and the instructions are detailed and clear about what you need to do: as you'll already have a security certificate, it will not take long to make the switch over to full-site HTTPS.
Posted on Thu, September 21, 2017
by Steve Goldberg filed under