Webサービスを本番公開した後に脆弱性が見つかった、という経験はありませんか。SQLインジェクションやXSSを修正する度に「なぜリリース前に気づけなかったのか」と悔やんだ現場担当者は少なくないはずです。
開発とリリースのサイクルが短くなった今、セキュリティテストを後回しにするコストはますます高くなっています。
この記事では、Webアプリケーションを実際に動かしながら脆弱性を検出する手法「DAST（Dynamic Application Security Testing）」について、仕組み・代表ツール・中小企業でも取り入れやすい実践手順まで、現場目線で解説します。
DAST（動的アプリケーションセキュリティテスト）とは？
DAST（Dynamic Application Security Testing）は、稼働中のWebアプリケーションに対して外部から擬似攻撃リクエストを送り、脆弱性を検出するテスト手法です。「外から叩いて壊れないか確認する」イメージです。
アプリケーションのソースコードにはアクセスせず、実際のHTTPリクエスト・レスポンスを観察することで、ランタイム（実行時）に初めて表面化する脆弱性を見つけ出すのが特徴です。
検出対象となる主な脆弱性は以下のとおりです。
・SQLインジェクション: 不正なSQL文をフォームやURLパラメータ経由で注入し、データベース操作を試みる攻撃
・XSS（クロスサイトスクリプティング）: 悪意あるスクリプトをページに埋め込み、閲覧者のブラウザで実行させる攻撃
・認証・セッション管理の不備: セッションIDの予測可能性や固定化など、認証周りの弱点
・セキュリティ設定ミス: デフォルトの管理画面公開や不要なHTTPメソッドの許可など
・開かれた不要なエンドポイント: 削除し忘れたデバッグ用APIや管理機能
これらはOWASP Top 10でも上位に挙がるリスクであり、実際の攻撃者が最初に試みる攻撃手法でもあります。
なぜDASTが重要なのか
「コードレビューをしているから大丈夫」「テスト環境で動作確認している」という声をよく聞きます。しかし、静的なコードレビューや機能テストだけでは発見できない脆弱性が存在します。
たとえば、フレームワークのバージョンアップで意図しない挙動が変わったケース、インフラ設定とアプリ設定の組み合わせで生じる脆弱性、外部ライブラリが変わったことで引き起こされるランタイムの問題などは、実際にリクエストを送らないと気づけません。
また、Webアプリケーションへの攻撃は増加し続けています。IPAが発表している「情報セキュリティ10大脅威」でもWebアプリへの攻撃は毎年上位にランクインしており、攻撃者は自動スキャンツールを使って無差別に脆弱なサイトを探しています。
攻撃者が使うのと同じ視点でスキャンするDASTは、「実際に攻撃されたらどうなるか」を事前に確認できる、防御側にとって非常に価値の高い手法です。
SAST・IASTとの違い：3つのテスト手法を整理する
アプリケーションセキュリティテストには、DASTのほかにSAST（静的解析）とIAST（インタラクティブ解析）があります。それぞれの特徴を整理すると、以下のようになります。
| 手法 | フルネーム | 対象 | 検出タイミング | 主な特徴 |
|---|---|---|---|---|
| SAST | Static Application Security Testing | ソースコード・バイナリ | 開発中～ビルド時 | コードを読んで問題箇所を特定。実行不要で早期発見が得意 |
| DAST | Dynamic Application Security Testing | 稼働中のWebアプリ | テスト環境～本番前 | 実際のリクエストで検証。ランタイム固有の問題を発見できる |
| IAST | Interactive Application Security Testing | 稼働中のアプリ（内部センサー付き） | テスト実行中（リアルタイム） | アプリ内部にエージェントを埋め込み、より精度の高い検出が可能 |
SASTは「書いたコードに問題がないか」を開発中に確認するのに向いており、DASTは「動いているアプリに攻撃が刺さらないか」を確認するのに向いています。どちらか一方で十分ということはなく、組み合わせて使うことで防御の穴を減らせます。
予算や体制に限りがある中小企業であれば、まずDASTから始めるのが現実的です。ソースコードの共有が不要で、テスト環境のURLさえあれば動かせるためです。
DASTの仕組みと検出の流れ
DASTツールは大きく3つのフェーズで動作します。
1. クロールフェーズ（サイト構造の把握）
まずテスト対象のWebアプリをクローラーが巡回し、URLやフォーム、APIエンドポイントを自動的に列挙します。ここで見落としがあると、その後のスキャン精度にも影響します。
SPA（シングルページアプリケーション）やJavaScriptが多用されたサイトでは、従来のHTMLクローラーでは見つけられないURLが多く、認証が必要なエリアも自動クロールの難所になります。
2. スキャンフェーズ（攻撃リクエストの送信）
列挙したエンドポイントに対して、あらかじめ定義されたペイロード（悪意ある入力値のパターン）を順番に送り込みます。レスポンスのHTTPステータスコード・本文・ヘッダーを解析し、脆弱性の兆候がないかチェックします。
たとえばSQLインジェクション検査では、`’ OR ‘1’=’1` のような文字列をパラメータに入れ、エラーメッセージや通常と異なるレスポンスが返ってくるかを確認します。
3. レポートフェーズ（結果の出力）
スキャン完了後、検出された脆弱性を一覧にしたレポートが出力されます。脆弱性名・リスク評価（High/Medium/Low）・該当URL・再現手順などが記載されており、開発者が修正作業に入れる形式になっています。
レポートを受け取った後は、開発チームと優先度を協議し、Critical・High を優先して修正する流れになります。セキュリティリスクアセスメントの考え方を使って優先度を判断すると効率的です。
代表的なDASTツールを比較する
1. OWASP ZAP（Zed Attack Proxy）
OWASPが開発するオープンソースのDASTツールです。無償で使えるため、予算の限られた組織でも導入しやすいのが最大の強みです。
GUIで操作できるプロキシモードと、コマンドラインで自動スキャンを実行するCIモードの両方に対応しています。GitHubのActionsなどCI/CDパイプラインへの組み込みもサポートしています。
スキャン精度はEnterprise製品に比べると劣る面もありますが、基本的なOWASP Top 10カバレッジは備えており、導入ハードルが低い点で中小企業や個人学習にも向いています。
2. Burp Suite（Community Edition / Professional）
PortSwiggerが開発するWebセキュリティテストの定番ツールです。無償のCommunity Editionから有償のProfessional Editionまであります。
プロキシとして動作しながら通信をインターセプト（傍受・改ざん）できる機能が強力で、ペネトレーションテストの現場でも広く使われています。
Community Editionではスキャン機能が制限されていますが、手動での通信改ざんやリクエスト解析には十分使えます。本格的な自動スキャンが必要な場合はProfessional Edition（年間契約）が必要です。
3. Nikto
オープンソースのWebサーバースキャナです。WebサーバーやCMSの既知の脆弱性・危険な設定ファイル・デフォルトパスワードなどを素早く検出することに特化しています。
インストールが簡単で、コマンド1行でスキャンを開始できる手軽さが魅力です。ただし、アプリケーションロジックの脆弱性（認証・認可の不備など）の検出は得意ではありません。まず「明らかなサーバー設定ミス」がないか確認する用途に向いています。
4. 商用DAST製品
Invicti（旧Netsparker）、Tenable Web App Scanning、HCL AppScanなどの商用製品は、スキャン精度・レポート品質・サポート体制が充実しています。予算があれば検討する価値があります。
中小企業でも今日からできること
「DAST導入のハードルが高い」と感じている方に向けて、現実的なステップを紹介します。
1. まずOWASP ZAPで試してみる
OWASP ZAPをローカルにインストールし、自社のステージング環境（テスト環境）に向けてスキャンを実行します。本番環境への直接スキャンは、意図しない負荷やデータ破壊のリスクがあるため推奨しません。
スキャン前に対象システムの管理者に通知し、ステージング環境であることを確認してから実施してください。外部サービス（外部のECやSaaSなど）をスキャンすることは法的問題になる場合があります。必ず自社が管理する環境のみを対象にしてください（詳細は不正アクセス禁止法等、法律の専門家にご確認ください）。
2. 検出した脆弱性をトリアージする
スキャン結果には、High（高リスク）からInformational（参考情報）まで様々な深刻度のアラートが含まれます。まずHighとMediumに絞り込み、本当に修正が必要かを開発者と一緒に確認します。
DASTツールは誤検知（False Positive）も含まれるため、アラートをそのまま全件修正しようとすると工数が肥大化します。OWASP Top 10に関連する項目を優先するのが実践的です。
3. 定期スキャンをルーティン化する
四半期に1回、あるいはリリース前のたびにDASTスキャンを実施するサイクルを作ります。CI/CDパイプラインにZAPを組み込めれば理想的ですが、まずは手動での定期実施から始めるだけでも意味があります。
スキャン結果はスプレッドシートでよいので記録し、前回と比較することで「新たに追加された脆弱性」を追いやすくなります。
4. WAFと組み合わせて防御を多層化する
DASTで発見した脆弱性を修正するのが根本対策ですが、すぐに修正できない場合はWAF（Webアプリケーションファイアウォール）でリスクを一時的に緩和する方法も有効です。修正が完了したらWAFルールも見直すことを忘れずに。
また、APIセキュリティの観点から、REST APIエンドポイントも必ずスキャン対象に含めるよう意識してください。現代のWebアプリはAPIが攻撃の入口になるケースが増えています。
よくある誤解と注意点
【誤解1】DASTは本番環境に直接使うもの
DASTは擬似的な攻撃リクエストを大量に送るため、本番環境に直接使用するとパフォーマンス影響やデータ汚染のリスクがあります。原則としてステージング環境（本番と同等の設定をした検証環境）で実施してください。
本番に対してスキャンする場合は、夜間の低トラフィック帯に絞り、スキャン速度を抑えた設定で慎重に行う必要があります。
【誤解2】DASTで全ての脆弱性が見つかる
DASTは非常に有効ですが、万能ではありません。アプリケーション内部のビジネスロジックの問題（特定のユーザー権限での操作順序による不正など）は、DASTの自動スキャンでは検出が難しいケースがあります。
「DASTを通ったから安全」という思い込みは禁物です。SASTや手動レビュー、場合によってはペネトレーションテストとの組み合わせで、より網羅的な検証を行うことが重要です。
【誤解3】スキャンさえすれば終わり
スキャンで発見した脆弱性を修正し、再度スキャンして修正を確認するまでが一連のサイクルです。「スキャンしてレポートを保存しておいた」だけでは、脆弱性が残ったままになります。
修正確認のための「再スキャン（Rescan）」を必ずセットで行う習慣をつけてください。
本記事のまとめ
DAST（動的アプリケーションセキュリティテスト）の要点をまとめます。
| ポイント | 内容 |
|---|---|
| DASTeの定義 | 稼働中のWebアプリに擬似攻撃リクエストを送り、脆弱性を検出するテスト手法 |
| SASTとの違い | SASTはコード解析（開発中）、DASTはランタイム検証（テスト～リリース前） |
| 主な検出対象 | SQLインジェクション、XSS、認証不備、セキュリティ設定ミスなど |
| 無償ツールの筆頭 | OWASP ZAP（無料・CI/CD対応・中小企業に最適） |
| 実施環境 | 必ずステージング環境で実施。本番直接スキャンは要注意 |
| 次のステップ | スキャン→修正→再スキャンのサイクルを定期的に繰り返す |
Webアプリの脆弱性は「リリース後に見つかると修正コストが跳ね上がる」のが現実です。開発プロセスにDASTを組み込み、攻撃者に先んじて弱点を把握する習慣を作っていきましょう。
セキュリティバイデザインの考え方と組み合わせることで、「脆弱性を作り込まない開発」と「作り込んでしまった脆弱性を早期発見する」両輪の体制が整います。
Linuxサーバー側のセキュリティ強化については、姉妹サイトLinuxMaster.JPで詳しく解説しています。Webアプリとサーバー両面からの対策を合わせて参照ください。
PR
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版（徳丸浩／SBクリエイティブ）
SQLインジェクションからXSS・認証不備まで、Webアプリの脆弱性を体系的に学べる国内屈指の実践書。DASTで検出した脆弱性の「なぜ起きるか・どう直すか」を深掘りするのに最適です。
