ECサイトにおける価格の改竄の対策として、「購入確定処理で、クライアントからPOSTされてくる商品IDをキーに商品マスタテーブルを検索して、検索した結果の価格で購入処理を行なう」というような趣旨の対策が書いてあるのを見たことがあります。
これは悪意あるユーザによる価格改竄の対策として正しいわけですが、私は別の問題で少々引っかかるものを感じてしまいます。
私が「引っかかるところ」について、以下で少し書いてみます。
運営者による価格変更
購入確定処理の直前には、購入確認画面がユーザに提示されているはずです。
┏━━━━━━━━━━┓ ┃ ＜購入確認画面＞ ┃ ┃ ┃ ┃ みかん 1個 100円 ┃ ┃ ---------------- ┃ ┃ 合計 100円 ┃ ┃ ┃ ┃上記を購入しますか？┃ ┃ ┃ ┃ [購入確定] [戻る] ┃ ┗━━━━━━━━━━┛
この画面でユーザは「購入確定」ボタンを押下する訳ですが、購入確認画面が表示されてから、購入確定ボタンが押下されるまでには、何十秒だか何分だかの間があります。
そのタイムラグの間に、たまたまサイトの運営者が商品情報のメンテナンスを行ない、みかんの価格を100円から200円に値上げしてしまったとしたら、何が起こるでしょうか？
ユーザは100円のみかんを買ったつもりなのに、実際にユーザに請求される金額は200円になってしまうかもしれません。
誤請求が起こるシステム
上記で「かもしれません」と書いたのは、そうなるかならないかは、サイトの設計に依存するからです。
そうなるのは、冒頭に書いたような価格改竄の防止手法を採用しており、なおかつ商品情報メンテナンスの際に、商品マスタ上の既存レコードを、商品IDを変えることなく単純にUPDATE処理するシステムです。
そのようなシステムは、別の言い方をすると「商品情報の安全なメンテナンスができないシステム」ということになります。
まとめ
厳密な処理が要求されるシステムにおいては、「価格改竄の防止」と「商品情報の安全なメンテナンス」の両方を達成する必要があると思われます。後者に関しては、冒頭に記述した方法では達成できない場合があるため、注意が必要です。
両方を達成するための方法には、様々なものがあります。個々の方法について詳述はしませんが、一番簡単なのは、購入確定処理において、hiddenの価格等の商品情報とデータベース内の情報を突き合せる方法でしょう。
突き合せた結果が一致しない場合は、ユーザがhiddenの情報を改竄したか、サイト運営者が商品情報を変更したかのどちらか（もしくは両方）であり、何らかのエラー処理を行なえばよいことになります。
なお、この方法は、不一致の原因の切り分けすらできない原始的なものです。実際のサイトの多くでは、もう少しエレガントな方法を用いていると思います。
補足
一応確認しておくと、「価格改竄の防止」と「商品情報の安全なメンテナンス」は別個の問題です。従って、冒頭に記述したような価格改竄の防止策が、後者の問題を解決しないからといって、価格改竄の防止策として間違っているということではありません。
また、全てのサイトが両方の問題にシステム的な対処をする必要があるということでもありません（レアケースであったり、運用である程度カバーできるため）。そのサイトの特性に応じて、どちらかのみ対処したり、両方とも対処しないという選択をすることもあるでしょう。
