localstorage security for ecommerce

[tarponjargon]

Hi - this is not really an issue, more just a question. I apologize if this is the incorrect forum.

I'm scratching the surface of using ember for e-commerce and came across this nice addon. I am concerned about the security/integrity of the e-commerce app (and data) being on the client side. For example, could a determined miscreant tamper with localstorage to change the price of an item to $0.01? I'm not super intimate with localstorage but I assume that's possible.

What do you guys do to secure against this type of thing? I assume this plugin is in production on your client sites. Any help appreciated!

[bcardarella]

Perhaps I am not following, but don't most major e-commerce providers store cart information in localstorage?

[tarponjargon]

Hi Brian, thanks for responding. I'm new to the idea of localstorage (I've always persisted to the back end only), but speaking about amazon specifically, yes, they use localstorage - and alot of it. I don't know what for exactly. But they also set a bunch of cookies which leads me to believe some data is also persisted on the back end.

I think my larger question and concern, and it is likely a very newb one, is:

If the item data (with prices) and the app itself (containing price and discount logic) is sitting there in the client's browser, how can you ensure that when the user goes to the transaction phase, that the order itself hasn't been manipulated? Especially if using a client-side-integrated payment processor like Stripe or Braintree.

Is it common practice to "validate" prices/discounts/order totals against the back end via the API at various stages? Or does all that logic still need to happen on the back end (for safety)?

I apologize if this is "left field" question - it may just belie a complete misunderstanding of the technology! :D

[ejthan]

Hi, I there are different ways to solve this problem... You could refresh the prices on every visit on the cart route or you could refresh the prices after saving the cart to the backend (This is only a solution if the user is not paying with a credit-card - B2B).

Mostly it is useful to refresh the prices as often as possible to ensure that price changes made on the backend are also visible on the client.

[tarponjargon]

OK, thanks for answering. By refresh the prices, do you mean set up the cart model such that ember-data (assuming that's what I'm using) hits the API's "/cart" endpoint (with the ids of cart items) each time that route is hit? I assume so, but I just want to be clear.

If it is the case, any promotion logic affecting prices and order totals (i.e. "get 10% Father's Day items with coupon code XYZ") would need to happen on the back end. In other words, don't build discount logic into ember if your source of truth for prices is the back end. Is that correct?

If so, I'm thinking a cookie-based session may be necessary, so that the server knows to always send back prices that reflect any discount.

Sorry if this is rudimentary! I just want to be sure I'm approaching this correctly.

[ejthan]

Yes we are building the prices on the backend. In our case there are 10-15 different calculations (Discounts, Project-Discounts, etc...) as the ERP-System is the master for this.

We are resolving the prices and the items separately.

1. Load items (maybe the cart is very old and the item is not available anymore)
2. If the item is still available the price is resolved async -> bad performance because of the 10-15 different calculations.

The localstorage is only used if the user is not already registered. For registered users we have to persist the cart to the backend.

Sorry for my english it is bad! (coming from Switzerland)

[tarponjargon]

Cool - thanks so much. That's good info. I was also thinking prices might need to be async-loaded! Anyway, couple last questions:

1. Are you using ember-data (like with a 'cart' model)?
2. Are you persisting the cart to the back end with cookies or a different method?