A Retailer’s Journey in Protecting Against Web Supply Chain Attacks

This guest blog was contributed by Ronny Ong, Technical Architect at ReadingGlasses.com.

From opening our first Reading Glasses boutique store in 1987 to launching in 2000 what is now the world’s largest online store for designer reading glasses and reading sunglasses, we’ve always been dedicated to innovating and delivering the very best shopping experience to our customers.

Today, ReadingGlasses.com customers can browse thousands of products in seconds, using our state-of-the-art product search. We’re able to offer our online customers the same level of service enjoyed by our in-store customers for decades, with ease and flexibility of selection across everything from color to frame material, lens type or favorite brands. Our standard shipping is free every day (both ways), but we realize this may not be enough because we don’t have a big name recognized by everyone.

Among the ways we try to reassure new shoppers is by accepting a wide range of checkout/payment options including Amazon Payments, Apple Pay/Google Pay, and PayPal. Any customer who might be reluctant to submit their credit card number to us can choose to go through any of these third parties that they already trust (subject to availability based on various factors such as device/browser type). But there’s a catch: We must maintain connections between our site and multiple third parties, not just for these payment providers but also other vendors who help us optimize our site performance. Some sites don’t bother to make sure their external connections are totally secure on an ongoing basis, but we consider it our responsibility.

During recent years, most major online retailers strengthened their defenses against common hacking methods which were widely used by criminals in the past. Unfortunately, this merely caused many of those criminals to seek out new methods. Whereas their old methods typically tried to exploit holes on the server side (e.g. firewall bugs, SQL database injection, weak passwords for administrator logins, etc.), their newer methods are now starting to target the browser side by injecting malicious JavaScript or other browser-side code, often indirectly (without needing to compromise the retailer’s own servers/network at all, instead going thru one of the retailer’s third party “partners” or sometimes thru a phony browser add-in/toolbar that the shopper was tricked into installing).