Webサービス開発時のチェックリスト
皆さま、こんにちは。株式会社ホロラボの秋猫です。
弊社はこれまで XR 系の技術開発に注力してまいりましたが、PoC の先を見据えて実用性を追求するため、新たに Web 開発分野にも力を入れております。私自身もその挑戦の一貫として Web エンジニアとして入社いたしました。
さらに、組織の急速な拡大に伴い、開発の効率化と品質向上を実現するためのガイドライン策定にも取り組んでおります。そこで今回は、私が担当した Web 開発およびクラウドインフラサービスを活用した開発・運用に関するチェックリストをご紹介いたします。
- Webサービス開発時のチェックリスト[本記事]
- クラウドインフラサービスを利用時のチェックリスト
チェックリストの方針と注意点
本チェックリストは、実際に活用される事を最優先に設計しています。具体的には以下の点に留意しながら作成しております。
-
実用性の重視
現場で実際に使用されることを前提に網羅性や詳細さに偏りすぎず、読みやすさと実践的な内容のバランスを取っています。 -
更新負荷の軽減
あまりに細かい情報を盛り込むと頻繁な更新が必要になり、結果として古い情報が残ってしまう恐れがあります。そのため、あくまで調査や検討のきっかけとなる内容に留めています。 -
継続的な改善
チームメンバーの成長や頂いたフィードバックを反映しながら、チェックリストは定期的に更新・改善を進めてまいります。 -
必須項目と推奨項目の区分
実際のリスト内は「必須」と「推奨」に分かれておりますが、プロジェクトの背景により必須とした項目が対象外となる場合もございます。
1. 認証・認可
1.1 ログイン機能
- パスワード認証の場合、ソルトを使用したハッシュ化を実装している
- パスワードのハッシュ化にはbcryptなどの適切なアルゴリズムを使用している
- アカウントロックアウト機能を実装している
- ログイン試行回数に制限を設けている(例:10回/時間)
- パスワードリセット機能は安全な方式で実装されている
- 多要素認証のオプションを提供している
1.2 パスワードポリシー
- 最小文字数(8文字以上)を設定している
- 文字種の組み合わせを許可している(大文字、小文字、数字、記号)
- 一般的な弱いパスワードをブロックしている
1.3 セッション管理
- セッションIDは十分な長さと複雑さを持っている
- 予測不可能にする
- セッションIDをURLに含めていない
- HTTPS通信で利用するCookieの属性を適切に設定している
- HttpOnly 属性を設定している
- SameSite 属性を Lax または Strict に設定している
- Secure 属性を設定している
- Domain 属性を適切に設定している
- 以下のいずれかのセッションハイジャック対策を実装している
- ログイン成功後に新しいセッションを開始している
- ログイン成功後に既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認している
- セッションIDをログイン前には発行せず、ログイン成功後に発行している
1.4 アクセス制御
- 認可の確認を全てのエンドポイントで実施している
- 重要な操作には再認証を要求している
- アクセス権限の変更履歴が記録されている
1.5 監視
- アクセスログは適切に保存している
- 不正アクセスの試行を検知しアラートを設定している
2. 入力値の検証とデータ処理
2.1 XSS対策
- 全ての出力にエスケープ処理を行っている
- ユーザ入力を HTML 出力時にサニタイズを行っている
- URL を出力する時は https:// で始まる URL のみを許可する
- <script> の要素の内容を動的に生成しない
- スタイルシートを任意のサイトから取り込めるようにしない
- クライアント側でも入力値検証を実装している
- Content-Security-Policy (CSP)を適切に設定している
2.2 SQLインジェクション対策
- 入力値のバリデーションを実装している
- SQL文の組み立ては全てプレースホルダで実装している
- SQL文の組み立てを文字列連結により行う場合は適切なエスケープ処理を行い実装している
- エラーメッセージにデータベース情報を含めていない
2.3 その他のインジェクション対策
- CSRF対策を実装している
- OSコマンドインジェクション対策を実装している
- HTTPヘッダ・インジェクション対策を実装している
- メールヘッダインジェクション対策を実装している
2.4 ファイル操作
- アップロードされるファイルの種類を制限している
- ファイルサイズの上限を設定している
- ファイル名を安全な形式に変換している
- ユーザが予想して任意のデータを取得できない
- / 等の区切り文字を含ませたディレクトリ操作させない
- ディレクトリページをアクセス不可にしている
3. 通信セキュリティ
3.1 HTTPS/TLS設定
- 全ての通信でHTTPSを使用している
- 適切なTLSバージョン(1.2以上)を使用している
- 証明書の有効性を確認している
3.2 HTTPヘッダセキュリティ
- Strict Transport Security を適切に設定している
- X-Frame-Optionsを適切に設定している
- X-Content-Type-Optionsを nosniff に設定している
- Referrer-Policyを適切に設定している
- Cache-Controlを適切に設定している
3.3 CORS設定
- Access-Control-Allow-Originを適切に設定している
- 必要最小限のHTTPメソッドのみを許可している
- プリフライトリクエストを適切に処理している
4. インフラストラクチャ
4.1 サーバー設定
- 不要なサービスを停止している
- 最新のセキュリティパッチを適用している
- ファイアウォールを適切に設定している
- 管理用ポートへのアクセスを制限している
- 不要なサービスやポートを無効化している
4.2 データベースセキュリティ
- デフォルトパスワードを変更している
- データベースアカウントを用途ごとに作成し、アクセス権限を最小限に設定している
- 定期的なバックアップを実施している
5. 依存関係の管理
- 使用しているライブラリを定期的に更新している
- 既知の脆弱性が報告されているライブラリを使用していない
- 定期的に脆弱性データベースをチェックしている
- CVE など
- 新たな脆弱性が発見された時の対応フローを確定している
推奨資料
-
IPA の情報は日本語で書かれた一番網羅的な資料なので一度目を通しておくのを推奨します。
-
一部の情報は古く、現在はより良い対策があったりするものもあるので下記の各種サイトも補足的に参照して下さい。
-
OWASP は、Web アプリケーションのセキュリティを向上させる為のオープンなコミュニティで様々なガイドラインやリソースを提供しています。
-
OWASP Top10 は、OWASP が提供する Web アプリケーション・セキュリティに関する最も重大な 10 のリスクについてのガイドラインで、世界中の開発者やセキュリティの専門家に参照されている資料です。
-
API Security Top 10 は同様に API に焦点を絞ったリストです。
Discussion