CODEWITHSUNDEEP
server-sideclient-side
Vikram Khemlani
Vikram Khemlani

Reputation: 635

How to validate a request body with price

According to

Calculate price on frontend insecure?

Prices should always be validated on the backend as http requests can be modified. Basically, In my marketplace, a user can buy something and in that request body, it contains what he bought, and their prices, the subtotal as well as the corresponding catalog id for that item. However, it seems everything could be manipulated. If I were to validate the subtotal by traversing through all the items in his order, they could have been modified so this isn't accurate. If I were to look up the actual prices in the catalog based on the id, these catalog ids in the request body could have also been modified, pointing to the wrong catalog item. How could I therefore validate a price based on a users request body which contains the items and their prices, the subtotal and the catalog (database) id for each item?

Also if I'm using SSL, can't I then calculate price on the front end?

Upvotes: 1

Views: 355

Answers (1)

FrancescoMM
FrancescoMM

Reputation: 2960

The whole cart should stay on the server, the client displays the cart and asks for confirmation. Prices can also be calculated on the client, but they must be calculated again on the server later.

You should not loose tracks of the cart data (i.e. sending it to the user and waiting for it to come back) as you cannot trust it anymore, after. You must save cart/order data on the server and send the client an id of the saved cart data along with the data itself to display (prices, etc..). Then the user sends back confirmation and the id, not the whole data. With the id you recover cart/order info on the server, with prices and all, so the prices never come from the user.

Anything the user sends you can be changed by him if he is technical enough.

Use of encription does not help, encription avoids changes to data happening during the travel between the source (client) and the destination (server). It does not guarantee the client itself is trustworty or the data is right. The forgery happens in the client, before encription takes place (a user can manipulate url data or POST data as he wishes, altering the prices, before they get encrypted).

Also, encription usually guarantees the server owner is the right one (the server has a cerrificate) to the client, it does not not guarantee the user or client software is trustworty, so users using modified browsers are totally legit and cannot in any way be distinguished.

Upvotes: 1

Related Questions