価格をPOSTすることの是非

価格をPOSTすることの是非が議論されているようですが、これ単体を取って脆弱であると判断するのは確かに微妙ですね。
一般的に商品の価格は永久に固定である訳ではなく更新される可能性があります。そういえば、マクドナルドでも価格の改定がありましたね。気付いたのは最近ですけれども。
さて、商品の価格が変動する可能性のあるアプリケーションの実装を検討してみましょう。
ユーザが商品を選択し確認画面に遷移したタイミングでは、価格が100円だっとします。ところが、注文を確定したタイミングでは、200円に値上がりしていました。これをシステム的にどう処理するのが望ましいでしょうか？
200円を請求してしまう仕様としたら、ユーザからのクレームに悩まされるかもしれません。
100円を請求してしまう仕様としたら、システムオーナーからのクレームに悩まされるかもしれません。
クレーム対応に追われたくないと考えた開発者は、「申し訳ございません。価格が変更となりました。」といった画面を表示して、コミット処理は実行しない仕様を採用するかもしれません。
この場合、確認画面から注文の確定までの遷移の中で、価格が変更されていることを検知しなければなりませんが、変更はどうやって検知すればよいでしょうか？
手法はいろいろありそうです。商品の価格が改定される時間が前もって分っているならば、確認画面にアクセスした時間をPOSTしてもよさそうです。時間はどこから持ってくるのがよいでしょうか？DBサーバがよいか？アプリケーションサーバがよいか？時間の同期は大丈夫か？
考えるのが面倒なので確認画面で表示した価格をそのままPOSTするのがシンプルだと提案する人がいるかもしれません。この場合、POSTされた価格とコミット処理実行時の価格に不整合が発生していたら、処理を中断すればよさそうです。仕様は固まりました。自信を持ってリリースしましょう。

開発者はある日、価格をPOSTしているだけの理由で、納品したシステムが脆弱であると騒がれていることを知ります。システムオーナーは説明に来い！と、ものすごい剣幕です。クレーム対応に追われないよう対策を練ったはずがこの有様です。忙しい開発の合間をぬって説明資料を作成しなければなりません・・・
説明を終えて偽脆弱性だということは、なんとか納得してもらえました。しかし、失った時間は戻ってきません。なんだか心臓も痛くなってきましたが、この責任はいったい誰が取ってくれるのでしょうか？

などということを考えると、迂闊に脆弱性の指摘などしない方がよいのでは？と感じることがあります。

#本当に脆弱な場合もあるかもしれません
#もっとしっかりした仕様もあるかと思います

追記
誤解を招いてしまったようなので追記です。
価格がPOSTされるだけで脆弱性と判断するのは早計ですよ。ってことを書いただけです。実体験ではないので、難しい背景とかはありません。
ちなみに、Javascriotなしで戻るボタンを実装した場合にも価格をPOSTする実装になりやすいと思います。