※※※ミドルウェアを中心に、ウェブ関連の研究開発に携わっている者による雑文です※※※ウェブの脆弱性は、ウェブアプリケーションのバグに起因するものと、ウェブブラウザのバグに起因するものの2者に大別することができる。ウェブアプリケーションを開発/提供する仕事に従事している者には、この前者、すなわち、ウェブアプリケーションのバグに起因する脆弱性を最小限に抑え込むことを求められる注1。いって、脆弱性がないことを保障するのは難しい。「ウェブアプリケーションにバグがあっても脆弱性とはならない(あるいは被害が限定される)ような設計」を採用するのが現実的だと考えられる。OSにおける、プロセス間のメモリ分離やuserIDに基づいたファイルへのアクセス制御を考えてみると、OSがセキュリティを「強制」するため、アプリケーション側で不正なコードが実行されても脆弱性とならない、もしくは、影響を小さく抑え込むことができるようになっていることがわかる。自動エスケープ対応のテンプレートエンジンXslate等注2といったものを挙げることができる。ソルトつきハッシュで満足する前に考えるべきこと等の手法が知られている。これらの対策をひとつ選択し、あるいは組み合わせて使うことで、コーディングミスがあったとしても脆弱性が発現しない(もしくは発現する可能性が低い)アプリケーションを実現することができる。この種の技術には多かれ少なかれ、アプリケーション側のコードに不自由を強いるという側面がある。Injection対策のいずれもが現実的でないウェブアプリケーションも多いだろう。SQLにおける条件節の漏れによる情報漏洩のように、本質的に対策が難しい注3問題も存在する。以上のように、共通モジュール(あるいは下位レイヤ)でアクセス方法を「強制」する仕組みを用いることで、脆弱性への耐性を高めるという情報工学における一般的なアプローチは、ウェブ技術においても有効であり、積極的に使用すべきである注4。一方で、述べたように、今後の発展が期待される分野も存在する注5。後者については、一義的にはウェブブラウザベンダーが対応すべき問題である。最新のテンプレートエンジン事情を良く知らないので列挙はしません。APIベースのアプローチについても本稿では割愛します。ウェブアプリケーションにおいては、アクセス制限とアクセスを単一のクエリで記述することを求められることが多いため。