Zenn
🛡️

PlaywrightのE2Eテストは攻撃判定されないのか？ AWS WAFと共存するための実践的セキュリティ対策

に公開
AWS
Test
Security
WAF
Playwright
tech

はじめに

Playwrightを導入して、ローカル環境（localhost）でのE2Eテストは完璧！「さあ、ステージング環境で本格的にテストするぞ！」と意気込んだ矢先、CI/CDからのテストが失敗。ログを見ると、どうやらアクセスが拒否されている...。

こんな経験はありませんか？

これは、E2Eテストの自動化ツールが、意図せずセキュリティシステムに「攻撃」と見なされてしまう、非常によくあるパターンです。本記事では、Playwrightを使ったE2Eテストで直面しがちな、以下の2つのセキュリティ課題に焦点を当て、その原因と具体的な解決策を、特にAWS環境を例にとって解説します。

  1. テストコードの認証情報をどう安全に管理するか？
  2. AWS WAFなどのセキュリティシステムに攻撃と誤検知されずにテストを実行するには？

Playwrightの導入方法ではなく、その先の「安定運用」を見据えたセキュリティとインフラ連携の考え方を共有します。

なぜテストが「攻撃」と見なされるのか？ - WAFの気持ち-

まず、なぜ私たちの忠実なテストロボットが「攻撃者」の濡れ衣を着せられてしまうのでしょうか。原因は、AWS WAF (Web Application Firewall) のようなセキュリティシステムの振る舞いにあります。

WAFは、Webアプリケーションを保護する優秀な「セキュリティガード」です。このガードマンは、以下のような不審な動きを常に監視しています。

  • 異常なアクセス速度: 人間では不可能な速さでの画面遷移やクリック。
  • 機械的な反復動作: 毎回寸分の狂いもなく、同じ手順・同じ間隔での操作。
  • 短時間での大量リクエスト: 特定のページ（特にログイン画面など）への集中的なアクセス。

Playwrightによるテストは、まさにこれらの特徴に合致しやすいため、WAFから「ボットによるブルートフォース攻撃や、システムの脆弱性を探るスキャン行為ではないか？」と疑われ、アクセスをブロックされてしまう可能性があります。

課題①：テストコードの認証情報をどう守るか？

ステージング環境以降のテストでは、必ずログイン処理が必要になります。ここで最初のセキュリティ課題に直面します。

アンチパターン：コードへの認証情報のハードコーディング

最もやってはいけないのが、テストコードにIDやパスワードを直接書き込むことです。

アンチパターン（危険な例）
// 絶対やっちゃダメ
await page.GetByLabel("パスワード").FillAsync("my-super-secret-password-123");

このコードがGitリポジトリにコミットされた瞬間、認証情報は漏洩リスクに晒されます。

解決策：シークレット管理サービスと環境変数の活用

安全な認証情報管理の鍵は、**「コードと認証情報の分離」**です。AWS環境では、AWS Secrets Manager や AWS Systems Manager Parameter Store を利用するのがベストプラクティスです。

安全な認証情報の流れ


この構成により、ソースコードには一切の秘密情報が含まれなくなり、安全性が飛躍的に向上します。

安全なパターン
string password = Environment.GetEnvironmentVariable("STAGING_PASSWORD");
await page.GetByLabel("パスワード").FillAsync(password);

課題②：AWS WAFにブロックされずにテストを実行するには？

認証情報の問題が解決したら、次はいよいよWAFとの共存です。テストであることをWAFに正しく伝え、攻撃ではないと認識してもらう必要があります。これには、インフラ担当者との連携が不可欠です。

解決策A：IPアドレスのホワイトリスト登録（最有力）

これは、WAFに「このIPアドレスからのアクセスは、安全な身内（テスト）なので、チェックを素通りさせてください」とお願いする、最も一般的で分かりやすい方法です。

アクション:
インフラ担当者に、テストを実行するCI/CDランナーや開発拠点のグローバルIPアドレスを伝え、WAFの許可リスト（IPセーフリスト）への登録を依頼します。

解決策B：カスタムヘッダーによるリクエスト除外

IPアドレスが固定できない動的な環境（例: 開発者各自の自宅回線）などでは、別の方法が有効です。それは、関係者だけが知る「合言葉（カスタムヘッダー）」をリクエストに含める方法です。

アクション:

  1. インフラ担当者へ: 「X-Internal-Test: [秘密の値]のようなヘッダーを持つリクエストは、検査対象から除外する」というルールをWAFに設定してもらいます。
  2. 開発者側: Playwrightのコードで、全てのリクエストにそのカスタムヘッダーを付与する設定を追加します。

余談

これは余談ですが、AWS WAFには、「1分間に同一IPアドレスから100回以上のリクエストが来たら、そのIPをブロックする」といった設定が簡単にできます。

AWS WAFの公式ドキュメントによると、レートベースのルールは「継続的な5分間の期間」で単一の送信元IPアドレスからのリクエスト数を追跡します。例えば「5分間に100リクエスト」というルールを設定した場合、Playwrightで多くのテストケースを含むスイートを実行すると、このしきい値には容易に到達してしまいます。
これはまさに、E2Eテストが意図せずDDoS攻撃と誤認されてしまう典型的なメカニズムなのです。
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-rule-statement-type-rate-based.html

まとめ：安全なE2Eテスト環境構築のチェックリスト

PlaywrightによるE2Eテストを、安全かつ安定的に運用するための要点は以下の通りです。
✅ 認証情報はコードに書かない: gitに認証情報をコミットするのは絶対に避ける。
✅ シークレット管理サービスを使う: AWS Secrets Managerなどを活用し、認証情報は環境変数経由で受け渡す。
✅ インフラ担当者と早期に連携する: 「テストを自動化したい」という段階で、WAFの存在や設定について相談を始める。
✅ WAFの対策を講じる: まずは「IPアドレスのホワイトリスト登録」を検討する。それが難しい場合は「カスタムヘッダー」方式を検討する。
✅ 初回実行時はログを確認する: 対策後、実際にテストを流してみて、WAFのログで意図通りにリクエストが許可されているかを確認する。

E2Eテストの自動化は、開発プロセスを効率化する強力な武器ですが、それはアプリケーションやインフラ全体の一部です。セキュリティとインフラを考慮に入れることで、初めてその価値を最大限に発揮できます。この記事が、皆さんの安全なテスト環境構築の一助となれば幸いです。

Discussion