The secure JavaScript cart
One of the first questions we hear about our client-side JavaScript SDK is: “Is it secure?”. Unlike many JavaScript platforms, the short answer to that question is, ‘yes’. As moltin becomes the backbone of an online business, we know that security has to be our #1 priority, and the purpose of this post is to bust the myths, describe our approach and explain the security measures that we have in place.
So you want to use a JavaScript shopping cart…
In the past, pure client-side JavaScript shopping carts have been insecure because they are easily manipulated in a browser’s console, you should never trust the client. A simple “hack” could be changing the price of an item and making it cheaper or free to purchase. Whilst some of these carts state they provide validation, this is unfortunately carried out client-side. If this is not validated securely server-side before the checkout process begins, you open your site up to being easily exploited and causing administration headaches — disputes with banks and payment gateways are never fun. On the surface, these JavaScript carts seem like a quick win but you’ll end up writing more of your own code to validate data coming from your JS cart.
Other frontend-driven carts state they carry out “Crawl back verification” — where they crawl specific pages/domains and validate prices that are defined inside your HTML. Whilst this approach can work, in practice, this process can slow down your checkout response times. It also raises the question about what happens for JavaScript-powered applications that are not crawlable?
Separating concerns
So — how can you create a secure, feature-rich eCommerce storefront using only client-side JavaScript without writing your own validation layer?
With moltin. Our API allows us to separate the backend data storage, validation and logic processing from the frontend entirely. The client (or even your own server!) doesn’t need to do any heavy lifting and simply makes requests to the backend to request data (get the cart contents) or carry out actions (add this to my cart, checkout etc..).
This doesn’t just stop at carts though. moltin also provides features and functionality found in traditional eCommerce platforms including inventory (products, categories, collections), promotions, the checkout process to convert carts to orders, payment aggregation, custom data schemas and more. A great example of what can be achieved with our set of APIs is Black Crows which is built with AngularJS. Everything on their site is powered by moltin behind the scenes, including the navigation, pages, localization, products, carts, checkout and payment aggregation.
Benefits
There are many other benefits of using the moltin API but we’ve outlined a few below that lend themselves well to JavaScript and frontend development workflows.
Rapid development
The time it takes to build production applications and create functional prototypes is drastically reduced as the process is reduced down from managing a whole platform or rolling your own down to simply data-binding API responses inside your HTML and triggering requests to make actions.
Design freedom
No longer bound by technology choices and limitations, designers and developers can create dynamic customer journeys and scalable shopping experiences.
Framework agnostic
The API-based approach ensures the solution fits into any technology stack and your personal toolkit seamlessly. Our JavaScript SDK is framework agnostic and can work with vanilla JS, Angular, React, Ember, Vue, Node and whatever JS framework is the flavor of the month! It doesn’t stop there though, moltin is language agnostic too if you wanted to use a service side (Node, PHP, GO etc..) or mobile language (Swift/Java) too!
Control & Limitations
moltin currently provides two API keys, the client ID, and the client secret.
At this point it should be noted: never share your client secret with anyone, it’s a secret for a reason, and that reason is it provides full read/write access to your data via the client credentials grant type!
Our client-side JavaScript SDK implements the implicit grant type. This limits the available actions to those that are non-destructive and restricts the features you can implement on the frontend. For example, you can’t create, update, delete on most resources except carts and POSTing checkout/payment but you can read some resources. See the handy table in our API reference for a full breakdown of available read/write access for each resource.
A simple example of what this means is that a product price can not be tampered with on the client-side as the product is defined on the moltin backend and adding items to the cart is validated on our backend. Carts are stored on moltin and only a reference ID is stored client-side to access this cart.
With that said, some users may not be worried about a price being altered. A good example would be a donate button. In this scenario, we would suggest using custom cart items where you can set a title and price from the client-side. Once a cart containing a custom item is transformed into an order during the checkout stage the custom order item/s would not have a moltin product ID attribute to mark it as custom so you can’t fake a defined “real” moltin product.
Cart IDs in moltin are special as you can define your own reference. By default, the JS SDK generates a 32-bit random alpha-numeric string to avoid collisions and makes them close to impossible to guess correctly. These are unique to each moltin store and the reference is stored in a mcart cookie for your site.
You can also set many of the readable resources (products, categories, collections etc.) to “live” or “draft”. Using the implicit grant type will result in only “live” results being returned from the API and another way for you to control what data is available to client-side applications.
A word on OAuth 2
Another question we hear is ‘why have you even bothered with the authentication process in the first place if you are simply trading a public key for an access token?’ The reason is simple, you can re-generate your public key in case of a security breach and also controllably revoke access for specific access tokens immediately.
On PCI Compliance
If you implement a pure JavaScript checkout with moltin no card details ever touch your servers. Instead, this data is securely passed via HTTPS from the client’s machine to the moltin API which is level 2 PCI compliant. From there, and depending on the specific payment gateway, the moltin application transparently sends this data to your chosen payment gateway and automatically stores responses in a transaction log (success/declined etc.). This also enables our application to update order statuses, assign stock levels, trigger events and other rules. At no point do we store card details against an order or transaction log.
Secure communication
Even without an SSL certificate installed, we make sure all of your data pass through HTTPS encryption, even when there’s no green lock pad next to your URL.
moltin’s SDK functionality is injected directly through JavaScript into your application. Even though the data appears on your domain and website, all of the information submitted is directly sent to moltin, which is already equipped with an SSL certificate.
Having said that, you technically do not need your own SSL certificate for moltin to work, but, we strongly recommend you install one.
There are a few reasons why we recommend this. Modern browsers such as Chrome and Firefox give HTTPS and SSL enabled sites priority, which can ultimately positively impact on your search engine results and rankings over a standard HTTP site.
During checkout, having a certificate installed will also make your customers feel more secure. Finally, this also protects your website from certain man-in-the-middle attacks.
Conclusions and the future
With the right approach and some basic knowledge, it is possible to create a secure, feature-rich eCommerce storefront using only client-side JavaScript with moltin’s API and SDK. We also hope we’ve armed the developers reading this with help to avoid some of the common pitfalls we see with JavaScript powered (and validated) eCommerce sites.
Why does this matter, anyway?
Here at moltin, we believe in modern methodologies and tooling to truly empower developers and businesses.
As we progress towards our goal of giving all developers control and access to the infrastructure layer for commerce, we realize just how important JavaScript development is in that story and our users should have the power to shape that for the benefit of all.
Helpful resources
To find out how easy it is to create a JavaScript website with eCommerce functionality, check out our JS quick start guide or one of our example applications.
If you’re ready to dive in feet first and build your own JavaScript eCommerce application, sign up for free and find out more on the moltin JS page.
