上のコメントにあげたケースは、処理を最後まで走らせずに例外をあげた結果、サービスにDoS脆弱性が発生していた、と理解すべき事象だと思います。「例外の粒度」的な観点ていうのはないんでしょうか。粒度というかスコープというのか。消え去るのなら問題ないんでしょうけど、現実には広告を含め該当tweet以降のHTMLがすべて消えちゃったから問題になったわけで。いうのはさておき、「例外の粒度」という観点は同意です。編集したり削除したりすることもできなくなるので、できるだけ小さな規模での「書き換え」(つまりサニタイズ)が望ましいと僕は考えます。現実には入力値検証を完了する前にDB更新を始めることはないでしょうから、脆弱性の話とはずれる気がしますが、大規模な環境だと「きれいに「なかったことにする」」のが難しいことは多いと思います(ただ、そのような回収もれのゴミはユーザーからは見えないようにするべきですが)。ありがとうございます。前から気になっていました。言う前提がないと、(セキュリティはさておいたとしても)入力値検証を絶対やりなさいと言う動機付けという点で柔い気がしたものですから上記のような具合に、私のウォールで豪華メンバーに参入いただき、楽しいディスカッションとなりました。先のTwitterライクなサービスの場合で言うと、以下のような対処案が考えられます。1.例外を発生させる(元々の仕様)表示時に異常データがあれば処理を打ち切り、ファイルクローズなど必要な後始末の後プログラムを終了する。この方法だと、先述のように、関係ないユーザまで被害を受けるので、よくありません。2.当該のツイートのみ表示しない異常なデータを含むツイートの単位で表示しないという方法です。前項よりはよいですが、UIから異常ツイートを削除するのが不便であり、画面上も不自然な表示になる可能性があります。3.異常データのみを削除するか、他の文字(「〓」など)に書き換えて表示する(狭義の)サニタイズです。異常データの影響はもっとも軽微になります。はせがわさんから指摘されていた「例外の粒度」はもっとも細かくなりますが、粒度が細かいことが好ましい例と言えます。まとめ結論は以下の通りです。処理が始まる前のチェック処理では、厳格なチェック処理と即座の停止をして良い(利用者に適切なメッセージを表示する前提で)処理(更新、表示など)が始まってから異常が発覚した場合は、後々の影響を考えた軟着陸をする必要があるその際にサニタイズが有効な場合もあるサニタイズというと「サニタイズ言うなキャンペーン」を連想してしまい、「サニタイズは絶対にやってはいけない」と考える人もおられるような気がしますが、私たちはその段階をそろそろ卒業しなければならないように思います。「サニタイズ言うなキャンペーン」は、本質的な脆弱性対処を考える上で、いったん「サニタイズ」という用語を使わないで考えてみようという問いかけだったと理解していますが、本質的な脆弱性対処をした上でさらに例外時の処理にまで配慮する場合は、サニタイズが有効な場合もあるということです。上記はクローズドな場の議論でしたので、奥一穂さんとはせがわようすけさんに引用のご許可をいただきました。快諾いただきまして、ありがとうございます。