OWASP ESAPIは、JSPページを保護するための推奨方法です。
OWASP ESAPIがしばらく更新されていないことに気づきました（ 2016年のマイナーアップデート、2013年以前 ）。 XSS防止のためにユーザー入力をエスケープして検証するために、より保守されたフレームワークのユーティリティを使用するなど、それを使用するより良い代替策はありますか？考える<cout .../>またはStruts 2または任意のフレームワークがコードを出力およびエスケープする独自の方法。または、セキュリティの観点から、常にOWASPを使用する方が好ましいですか？考え？
OWASP ESAPIは、フラグシップまたはアクティブなプロジェクトとは見なされなくなりました。 Java実装のプロジェクトオーナーであるKevin Wall氏 2014年に戻って彼自身は認めた プロジェクトは死にかけていると述べた：
できないからです。私は、壁に書かれた文字を見ることができます。 （Punの意図。）ESAPIに対して行われている申し立てはすべて、次のようになっています。
・2011年7月以降、マイナーポイントリリースは1つのみ。
・164の未解決の問題（クリティカルにマークされた4、高にマークされた11を含む）。
・依存関係が多すぎます。ほぼ3年間約束されていたにもかかわらず、これまで対処されたことがないものです。
・まだ古いOWASP形式のWikiページ。
・GitHubのESAPI 3.0およびGoogle CodeのJavaのESAPI 2.xのライフサインが最小限であること。他のプログラミング言語での実装の生命兆候。 [注：追跡していなかったため、SalesForceを割り引いています。]
・ESAPI for Javaの場合、すべてがシングルトンであり、モックテストなどのいくつかのことをすべて不可能にしてしまう、高度なアーキテクチャ。そのため、部分的には、80％未満のテストコードカバレッジ。
・JavadocおよびESAPI暗号ドキュメント以外の重要なユーザードキュメントがない。
・ESAPIハッカソンへの残念な参加。
ESAPIを使用する必要がありますか？ のKevin Wallの別の言い訳
新しいプロジェクトを開始する場合、または既存のプロジェクトを初めて保護する場合は、ESAPIを検討する前にbeforeを検討する必要があります。代替：
- 出力エンコーディング：OWASP Java Encoder Project
- 一般的なHTMLサニタイズ：OWASP Java HTML Sanitizer
- 検証：JSR-303/JSR-349 Bean検証
- 強力な暗号化：Keyczar
- 認証/承認：Apache Shiro
- CSRF保護：OWASP CSRFGuardプロジェクトまたはOWASP CSRFProtectorプロジェクト
これはESAPIが停止していることを示唆するものではなく、ほとんどのF500企業が自社のエンタープライズソフトウェアに望んでいるほど十分に維持されていないという事実を認めるものであることに注意してください。
IMOのオプションがある場合は、Springなどのフレームワークを利用する必要があります。これには、多くのセキュリティ問題に対処する機能があります（認証のためのSpring Security、CSRFなど）。出力についても、多くの最新のフレームワーク/ライブラリがエンコードを処理します。例えば。 JSPの場合は、JSTLを使用します。HTMLエンコーディング用のタグライブラリがあります。リッチクライアントを開発している場合、ReactなどのフレームワークはデフォルトでHTMLエンコードします。
ESAPIが有用である1つのシナリオは、セキュリティが不足しているレガシーアプリケーションを改造する場合です。それでも、ESAPIには十分なオープンな問題/脆弱性があり、一時停止する必要があります。それは悲しい状況であり、ケビン・ウォールは少し苦いものとして遭遇します：
最初に尋ねる質問は、プロジェクトですでにESAPIを使用していますか？使用している場合、それに多くの権利を持っていますか？その場合、「ESAPIを使用する必要がありますか？」おそらく「はい」です。あなたが尋ねるべき2番目の質問です。私がそれを使用している場合、なぜ私は何らかの形でそれに貢献していないのですか？しかし、そこには行きません。