top of page
IMG_0546.JPG

脆弱性診断企業の中の人が「OWASP TOP10 2025」を徹底予想:2025/03/06

  • 執筆者の写真: 晋次 宮田
    晋次 宮田
  • 2025年3月6日
  • 読了時間: 4分

2024年の年末にOWASPが、データ収集を開始したのは記憶に新しいです。(セキュリティ関連以外の人には意味不明だとは思いますが。)

世界中の開発者やセキュリティエンジニアが、発表されたら一応は見るであろう「OWASP TOP10 2025」。果たして次回はどんな脅威がランクインするのか?ちょっと予想してみたいと思います。



OWASP TOP10 2025はいつ発表される?


前述の通り、OWASPはすでに2025年版リリースに向けてデータ収集を開始しています。ここから推測すると、2025年中頃にドラフト版が公開され、業界のフィードバックを経て2025年後半には正式リリースとなるかもしれません。もしかしたらもっと早いかもという噂もあります。



「2025年のOWASP TOP10」予測リスト


1. 「アクセス制御の不備」– 不動の最重要脆弱性

前回(2021年)1位に君臨したアクセス制御の不備は2025年も引き続きトップ候補でしょう。診断の経験上やっぱりこれが一番の脅威です。

追加開発が多い、ビジネス的にイケてるアプリケーション程アクセス制御のコントールに漏れがあります。これはツールでは制御しづらいので、ある意味しょうがないと思っています。

API経由の不正アクセスやBOLA(Broken Object Level Authorization)など、認可プロセスのミスが致命的な情報漏洩を引き起こしています。開発段階から入念なアクセス制御の設計が必要です。


2. 「ソフトウェアサプライチェーンのリスク」– CI/CDパイプラインの落とし穴

SolarWinds事件以来、CI/CDパイプラインやサードパーティライブラリの脆弱性を狙った攻撃が急増しています。コード署名や依存関係の厳密な管理が必須になってくるでしょう。


3. 「クラウドセキュリティ設定ミス」– うっかり公開

ちょっとした設定ミスが重大インシデントを引き起こすケースが増えています。デフォルト設定の確認やIaC(Infrastructure as Code)の定期的なレビューが必須ですね。


4. 「インジェクション攻撃」– 長年の強敵、まだまだ健在

なんだかんだ無くならないインジェクション攻撃。診断してても見つかります。SQL、OSコマンドインジェクションなど、ユーザー入力のバリデーション不足を狙う攻撃は、正直攻撃しやすいので続くでしょう。フレームワークを使っていてもかいくぐる方法が出てくるなど、インジェクションが趣味なハッカーが一定数居る領域です。


5. 「識別・認証の不備」– 多要素認証が救う世界

多要素認証(MFA)を導入しないことによるリスクはましていると感じます。MFAを導入しているアプリと、そうでないアプリならやはり未導入のアプリを狙うのが筋です。

認証不備は即セキュリティインシデントにつながるので、SSOやOAuthの適切な設定も定期的に見直したほうが良いでしょう。


6. 「脆弱なコンポーネントの利用」– とりあえず更新しときましょう

Log4Shellなど依存関係に潜む脆弱性は定期的に発見されています。DependabotやAWS Inspectorの導入はやっておきましょう。


7. 「安全でない設計」– セキュリティは設計段階から

2021年に新設されたこのカテゴリは、重要性が増すでしょう。アーキテクチャ設計時の脅威モデリングを行わないことが致命的な脆弱性の根源になります。釈迦に説法ですが、シフトレフト(Shift Left)の概念の徹底ですね。


8. 「セキュリティログ監視の不備」– 攻撃を見逃さないために

当然ですが、攻撃を早いタイミングで検知できないと、被害が拡大してしまいます。リアルタイム監視・ログ分析体制は、ベンチャーには辛い投資ですが、売りが立ってきたら要検討アイテムかと思います。


9. 「サーバサイドリクエストフォージェリ(SSRF)」

クラウドインフラを狙ったSSRF攻撃は増える傾向です。内部リソースへのアクセス管理を厳密に設定しましょう。


10. 「暗号化の不備」– データ保護の要は依然として暗号化

TLSや適切な鍵管理を怠ると、機微情報が簡単に漏洩します。量子コンピュータ時代を見据えたポスト量子暗号(PQC)の採用も徐々に検討されるでしょう。


結果:前回と一緒

すいません、前回と一緒の項目になりました。一個一個考えるとなんか落とせる項目がなかったです。まぁTOP10から消えたとしても脅威として消えるわけじゃないので!(言い訳)

疲れて後半雑かもしれませんが、このぐらい短いほうが読みやすいかと。では!



書き手


名前:Shindy Miyata

 
 
bottom of page