本文へ移動
職種別 知っておくべき技術ラボ

ホーム / QA / 第4部 非機能のテスト

第4部 非機能のテスト・第11章

セキュリティのテスト

★★☆ 重要5トピック・面接 3問
この分野の深さ（職種別）Web ★★★実務App ★★仕組みSRE ★★仕組みML ★概要Data ★★仕組みQA ★★仕組み情シス ★★★実務EM ★★仕組みPdM ★概要デザイナー ★概要
まとめクイズ面接ではこう聞かれる（3問）

専門の診断に頼る前に、QA の普段のテストで見つけられる脆弱性と、その確かめ方を押さえる。

11.1セキュリティのテストの観点（OWASP Top 10）

用語★★☆ 重要
ひとことで

入力の検証・権限（他人のデータが見えないか）・依存の脆弱性を確かめる。

セキュリティのテストは専門の診断会社に頼むこともありますが、よくある脆弱性（ぜいじゃくせい＝攻撃に使われる弱点）の多くは、QA の普段のテストで見つけられます。

OWASP は Web のセキュリティの情報をまとめている団体で、よくある危険を「OWASP Top 10」として数年ごとに公開しています（2025 年版でも 1 位は「アクセス制御の不備」）。QA が確かめやすい観点の例です。

観点QA の確かめ方の例
アクセス制御の不備URL や API の ID を他人のものに変えて、見られない・変えられないか。一般ユーザーで管理者の API を呼べないか
インジェクション（SQL など）入力欄に ' OR '1'='1 などを入れて、エラーや想定外のデータが出ないか
XSS入力に <script> やタグを入れて、表示時にそのまま動かないか（文字として表示されるか）
認証の不備パスワードの間違いを何度も試せないか、ログアウト後に戻るボタンで見えないか、セッションの期限
設定の不備エラー画面に内部の情報（SQL・スタックトレース）が出ないか、不要な画面が公開されていないか
アクセス制御のテスト：ID を他人のものに変えて送るユーザー A自分の注文は 123サーバー（API）ID を 124（B さんの注文）に変えて送るGET /api/orders/124期待：403 または 404（見られない）200 で B さんのデータが返る → アクセス制御の不備（脆弱性）
いちばん多い脆弱性「アクセス制御の不備」を確かめる基本の手順

面接ではこう答える

セキュリティのテストは専門の診断に頼むこともありますが、よくある脆弱性の多くは QA の普段のテストで見つけられます。観点は OWASP Top 10 が参考になり、特に多いのがアクセス制御の不備、つまり ID を他人のものに変えると見えてしまう問題です。ほかに、SQL インジェクションや XSS、認証の不備、エラー画面に内部の情報が出る設定の不備を確かめます。

QAとの関わり機能のテストに数ケースを足すだけで重大な事故を防げるので、すべての機能のテスト観点に入れておきます。

11.2アクセス制御の不備（他人のデータが見えないか）

用語★★☆ 重要
ひとことで

権限のない人がデータを見たり変えたりできてしまう不備。ID を他人のものに変えて見えてしまう IDOR が代表例。

いちばん多い脆弱性がアクセス制御の不備です。代表例は、URL や API の ID を変えるだけで他人のデータが見えてしまう問題（IDOR と呼ばれます）。2人のテスト用アカウントを用意すれば、QA が普段のテストで確かめられます。

パターン試し方期待
ID の書き換えユーザー A の注文 /orders/101 を、B でログインして開く・API で取る403 か 404。中身が返らない
変更・削除の権限B で A の注文を PUT・DELETE する拒否され、データも変わらない
役割の違い一般ユーザーで管理者の画面・API を直接呼ぶ拒否される（ボタンを隠すだけでは不十分）
一覧・検索検索の条件や user_id の値を変えて送る他人のデータが混ざらない
ファイル添付ファイルや画像の URL を、ログアウトして・別の人で開く見られない（公開してよいものを除く）

ID が連番だと推測されやすいですが、推測しにくい ID でも、サーバーで「この人のデータか」を確かめていなければ不備です。サーバー側で拒否されるかを API で確かめるのがポイントです。

面接ではこう答える

アクセス制御の不備は、権限のない人がデータを見たり変えたりできてしまう脆弱性で、OWASP Top 10 でも1位です。代表例は、URL や API の ID を他人のものに変えるだけで見えてしまう問題です。テストでは2人のアカウントを用意し、一方のデータの ID をもう一方で開いたり変更したりして、サーバー側で拒否されるかを API で確かめます。ボタンを隠すだけでは防げていない、というのが大事な点です。

QAとの関わり権限やユーザーごとのデータがあるすべての機能で、テストケースに必ず入れる観点です。

11.3SQL インジェクションと XSS

用語★★☆ 重要
ひとことで

入力が命令として扱われる脆弱性。SQL インジェクションは入力が SQL の一部に、XSS は入力が画面のスクリプトとして動く。

どちらも「入力が、データではなく命令として扱われてしまう」脆弱性です。SQL インジェクションは入力が SQL の一部になり、XSS（クロスサイトスクリプティング）は入力が画面の HTML や JavaScript として動きます。

文字列をつなげる（危険）SELECT * FROM usersWHERE name = '＋入力＋'入力：' OR '1'='1→ 条件が常に真になり全員分プレースホルダー（安全）SELECT * FROM usersWHERE name = ?入力は「値」として渡す→ ただの文字として検索される
SQL インジェクションが起きる仕組みと防ぎ方
試す入力の例問題のサイン
SQL インジェクション'・' OR '1'='1SQL のエラーが画面に出る、余分なデータが出る
XSS<b>太字</b>・<script>alert(1)</script>文字ではなく太字になる・ダイアログが出る

入力した画面だけでなく、その値が表示されるすべての場所（一覧・管理画面・メール・CSV の出力）で確かめます。試すのは必ず検証環境で、本番や他社のサイトでは行いません。

下のラボで、SQL インジェクションがどう起きるかを実際に試せます。

面接ではこう答える

SQL インジェクションと XSS は、どちらも入力がデータではなく命令として扱われてしまう脆弱性です。SQL インジェクションは、入力を SQL の文字列につなげていると起き、プレースホルダーで値として渡せば防げます。XSS は、入力をそのまま画面に出すと、タグやスクリプトとして動いてしまうものです。テストでは記号やタグを入力し、入力した画面だけでなく表示されるすべての場所で文字として扱われるかを確かめます。

QAとの関わり入力欄のある機能のテストに、エラー推測の一部として数ケース足すだけで確かめられます。

別のページで開く →

DBラボを読み込んでいます…

11.4認証とセッションのテスト

★★☆ 重要

ログインまわりは攻撃の入り口になりやすい所です。機能のテストと一緒に、次の観点を確かめます。

観点確かめること
パスワードの総当たり何度も間違えると、待ち時間・ロック・追加の確認がかかる（仕様どおりか）
エラーの文言「メールアドレスが登録されていません」のように、登録の有無が分かってしまわないか
ログアウトログアウト後に戻るボタンで個人の画面が見えない。古いセッションの Cookie が使えない
セッションの期限一定時間で切れる。パスワード変更後に他の端末のセッションが切れる（仕様による）
パスワードの再設定リンクの期限・1回しか使えない・他人のメールアドレスで使えない
Cookie の属性セッションの Cookie に Secure・HttpOnly が付いている

Cookie とセッションで起きる不具合

11.5診断ツール（DAST・SAST・依存の検査）

用語★★☆ 重要
ひとことで

動くアプリに攻撃のようなリクエストを送る DAST、コードを読む SAST、使っているライブラリの既知の脆弱性を調べる依存の検査がある。

コードを書くプルリクエスト検証環境本番SASTコードを読んで検査依存の検査既知の脆弱性DAST動くアプリに送る診断・監視定期的に
診断ツールを使う場所（例）
  • 動的な診断（DAST）：動いているアプリに攻撃のようなリクエストを送って調べる。ZAP（旧 OWASP ZAP） や Burp Suite が代表的です。必ず検証環境で、許可を得て行います。
  • 静的な診断（SAST）：ソースコードを読んで危ない書き方を見つける。
  • 依存ライブラリの検査：使っているライブラリに既知の脆弱性がないかを調べる（Dependabot など）。

ツールは誤検知も見逃しもあるので、結果をそのまま報告せず、本当に問題か確かめます。

面接ではこう答える

セキュリティの診断ツールは主に3種類です。DAST は動いているアプリに攻撃のようなリクエストを送って調べるもので、ZAP や Burp Suite が代表的です。SAST はソースコードを読んで危ない書き方を見つけるもの、依存の検査は使っているライブラリに既知の脆弱性がないかを調べるものです。どれも誤検知と見逃しがあるので、結果は本当に問題かを確かめてから報告します。

QAとの関わりCI に組み込む検査を選ぶとき、診断の結果を開発者と一緒に仕分けるときに使います。

この章のまとめ

🖨 まとめシート（印刷・PDF）
  • OWASP Top 10 を参考に、QA が普段のテストで確かめられる観点を持つ
  • アクセス制御の不備は2つのアカウントで API から確かめる
  • 診断ツールの種類と、結果の仕分け

この章のクイズ

面接ではこう聞かれる

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1SQL インジェクションや XSS は、QA としてどう確かめますか？

模範回答

SQL インジェクションは、入力した文字が SQL の一部として実行されてしまう脆弱性です。入力欄や API の値に ' OR '1'='1 のような文字を入れて、SQL のエラーが画面に出ないか、本来見えないデータが出ないかを確かめます。XSS は、入力した文字が HTML やスクリプトとして画面で動いてしまう脆弱性で、<script> やタグを入れて、表示するときに文字のまま出るかを確かめます。

ただし、手で試せるのは入口の確認で、すべての入力欄を網羅するのは難しいので、OWASP ZAP などの診断ツールも合わせて使います。ツールは必ず検証環境で、許可を得て流します。また、根本の対策は開発側の「プレースホルダーを使う」「出力時にエスケープする」なので、見つけたら同じ書き方が他にないかも開発者と確認します。

深掘りされたら

  • 画面では入力の文字数が制限されているときは、どう試しますか？

見られているポイント仕組みの理解・確かめ方・ツールと許可・根本対策の把握

Q2一般ユーザーが他人の注文を見られないことを、どう確かめますか？

模範回答

テスト用のアカウントを2つ用意し、A で注文を作ってその注文の ID を控えます。B でログインして、その ID の画面を URL で直接開き、API も直接呼んで、403 か 404 になり中身が返らないことを確かめます。

見るだけでなく、変更や削除の API も B から呼んで拒否されること、一覧や検索の条件を書き換えても A の注文が混ざらないことも確かめます。ボタンが表示されないことではなく、サーバー側で拒否されることを確かめるのがポイントで、重要なので API の自動テストにも入れます。

深掘りされたら

  • ID が推測しにくい文字列なら、テストは要りませんか？

見られているポイントアクセス制御の不備の確かめ方（サーバー側での拒否）

Q3診断ツールが大量の警告を出しました。どう扱いますか？

模範回答

そのまま全部を開発者に渡すのではなく、仕分けます。まず重大度の高いものから、本当に再現するか、実際に攻撃に使えるかを確かめます。ツールには誤検知があるので、再現できないものは理由を残して除きます。

本物の問題は、影響（個人情報に届くか、誰が悪用できるか）で優先度を付けて報告し、直す期限を決めます。同じ原因の警告はまとめ、繰り返し出る種類は、書き方のルールや CI の検査で再発を防ぐよう提案します。判断に迷うものはセキュリティの担当者に相談します。

深掘りされたら

  • ツールで見つからない脆弱性には、どんなものがありますか？

見られているポイント誤検知の仕分けと優先順位付け