Webアプリケーションの環境的問題を解決するためには，低レイヤーの保護から始めるのはいうまでもない。だが，それだけでは不十分である。レイヤー7，すなわちアプリケーション層のリスクを軽減するためには，そのレイヤーを理解し，強化機能，防御機能が提供する必要がある。そこに位置づけられるのが，WAF（Web Application Firewall）である。WAFは，論理的にはブラウザとWebサーバーの間に置かれるため，Webサーバーが受け取るHTTPリクエストをWAFが逆向きのプロキシとして受け取り，取捨選択を行なうという原理だ。

　数多くのアプライアンスが既に市場に出回っている。Apacheの中にビルトインできるモジュールmod_securityは，オープンソースのWAFだということができる。それぞれで詳細な機能は異なるが，基本的には，リクエストの選別と，出力のフィルタリングにおける効果を期待できる。入力系としては，Webアプリケーションを直接攻撃するワーム，存在しないURLのリクエストやSQL文が含まれる危険なリクエストの破棄，あるいはその場合のエラー出力をWAFが代理で完結してしまえる。

　逆に，Webサーバーからの応答に含まれるCookieやフォームのhiddenフィールドの暗号化，システムエラーのメッセージをフィルタリングすることも可能だ。ワンタイムハッシュを挿入するなどの方法で画面遷移をコントロールできるものもある。付加機能として，SSL通信をビルトインしているものや，リバースプロキシのアーキテクチャを活かしたロードバランシングやキャッシュマネージメントなど，性能向上を図るものもある。実際に，ロードバランサーの置き換えとしてWAFを検討するユーザーも少なくないようだ。

　Webアプリケーションのセキュリティ対策に期待の高いWAFだが，現時点で多くのWAFで出来ないことも理解しておく必要がある。まず，前述の「論理的問題」はこのアプライアンスでは対応できない。WAFが故障や不具合を起こした場合も，無理にサービスを継続すると，危険な状態にさらされることになる。

　WAFを導入しているからと，Webアプリケーションの開発でもちろん手を抜けるわけではない。WAFの機能によるメリットを引き出すには，実際のWebアプリケーションとの整合性をとることが不可欠だ。設定を詳細にすればするほどメリットは大きいが，同時にWebアプリケーションならではの柔軟な機能改善に，逐一追従していかなければならないという側面もある。

　セキュリティ強化を徹底するためにもWAFとは，Webサーバーそのものの負荷軽減と，技術的問題の解決までに若干の時間的猶予を与えるといった位置付けにとどめておくのが妥当ではないかと思う。アプリケーションそのものの改善のためには，論理的問題の見直しとともに，技術的欠陥を見つけ出していかなければならない。ホワイトボックステストを支援するプログラムスキャナなどのツールは，一定の効果をもたらしてくれる。

　インターネットにおけるサービスの多様化が進む時代で，ソフトウエア構築にまつわるエンジニアリングとは，機能要件を満たしつつ，求められる強度に応じた構造設計や実装を追及していかなければならない。もちろん，「漏れのない」セキュリティ対策は望まれるべきものであるが，現実のセキュリティ，安全性とは，それぞれのリスクに対して相対的なものであることを忘れないようにしたい。そのためにも，アプリケーションの構築者は，構築の度に誰のために何を構築しているのか，それに見合うセキュリティ方策はどのようなものなのか，見極めて適用していくことが必要とされるのだ。