セキュリティおよびAPIチェックリスト
本章ではTQS-S/W認証のセキュリティおよびAPI領域に対する詳細チェックリストを定義します。セキュリティチェックリストは認証/認可、暗号化、入力検証、脆弱性防御を検証し、APIチェックリストはRESTful設計規則、ドキュメント化、エラー処理を検証します。各項目の分類は必須(O)、推奨(R)、任意(S)に区分され、検証方法を併せて明示します。
32.5.1. セキュリティ
セキュリティチェックリストはプロジェクトのセキュリティ実装レベルを検証します。通信暗号化、認証/認可、入力検証、依存関係セキュリティ、シークレット管理等、ソフトウェアセキュリティの核心領域を含みます。
| 番号 | 項目 | 分類 | 検証方法 |
|---|---|---|---|
| 1 | TLS 1.2以上を使用して通信を暗号化する | O | サーバー設定確認 |
| 2 | パスワードをBCryptハッシュで保存する | O | コードレビュー |
| 3 | Spring Securityを適用する | O | pom.xml依存関係および設定ファイル確認 |
| 4 | Bean Validationを適用して入力値を検証する | O | コードレビュー |
| 5 | v-htmlディレクティブを使用しない（やむを得ない場合はDOMPurify適用） | O | コード検索 |
| 6 | SQLパラメータバインディングを使用する（文字列連結未使用） | O | コードレビュー |
| 7 | ソースコード内にシークレットをハードコーディングしない（APIキー、パスワード等） | O | コード検索 |
| 8 | OWASP Dependency-Checkを適用して依存関係セキュリティをスキャンする | R | pom.xmlプラグイン確認 |
| 9 | CORS (Cross-Origin Resource Sharing)ポリシーを明示的に設定する | O | Spring Security設定確認 |
| 10 | CSRF (Cross-Site Request Forgery)防御を実装する | O | Spring Security設定確認 |
| 11 | セキュリティヘッダーを設定する（X-Frame-Options、X-Content-Type-Options、X-XSS-Protection） | R | レスポンスヘッダー確認 |
| 12 | セッションまたはトークンに有効期限ポリシーを適用する | O | 設定ファイルおよびコード確認 |
| 13 | 入力値の長さ制限を適用する | O | Bean Validationアノテーション確認 |
| 14 | 認可失敗時に適切なHTTPステータスコード（403）を返却する | O | コードレビュー |
| 15 | ログに機密情報（パスワード、トークン等）を出力しない | O | コード検索 |
セキュリティ領域はTQS認証において最も厳格に検証される分野です。セキュリティ項目の未充足はプロジェクトの完全性に直接的な脅威となるため、必須項目を必ず充足しなければなりません。TLS (Transport Layer Security)の適用、パスワードハッシュ、SQLパラメータバインディングは基本セキュリティ要件です。
32.5.1.1. セキュリティ検証詳細基準
セキュリティ項目の検証は以下の詳細基準を適用します。
- TLS 1.2以上の適用有無は本番環境（prod）のサーバー設定を基準に検証します。開発環境ではHTTPを許可することができます。
- BCryptハッシュのcost factorは10以上を推奨します。
- CORS設定はワイルドカード（
*）を使用せず、許可ドメインを明示的に列挙しなければなりません。 - CSRF防御はSPA構造でトークンベース認証を使用する場合、Spring SecurityのCSRF設定を適切に構成しなければなりません。
32.5.2. API設計
API設計チェックリストはRESTful APIの設計規則、ドキュメント化レベル、エラー処理標準を検証します。
| 番号 | 項目 | 分類 | 検証方法 |
|---|---|---|---|
| 16 | RESTful URLネーミング規則を遵守する（名詞形、複数形、kebab-case） | O | APIエンドポイントリスト確認 |
| 17 | 標準エラーレスポンス形式を適用する（エラーコード、メッセージ、タイムスタンプ） | O | APIレスポンス構造確認 |
| 18 | SpringDoc (Swagger UI)を適用してAPIをドキュメント化する | O | pom.xml依存関係およびSwagger UIアクセス確認 |
| 19 | 日付および時刻形式にISO 8601を使用する | O | APIリクエスト/レスポンスサンプル確認 |
| 20 | ページネーション標準を適用する（page、size、totalElements、totalPages） | O | APIレスポンス構造確認 |
| 21 | APIバージョニング戦略を適用する（URLパスまたはヘッダー方式） | R | APIエンドポイントリスト確認 |
| 22 | リクエストおよびレスポンス例をAPIドキュメントに含める | R | Swagger UI確認 |
| 23 | Rate Limitingを適用してAPI呼び出しを制限する | R | 設定ファイルまたはコード確認 |
| 24 | HTTPメソッドを正しく使用する（GET 照会、POST 作成、PUT 更新、DELETE 削除） | O | APIエンドポイントリスト確認 |
| 25 | 適切なHTTPステータスコードを返却する（200、201、204、400、404、500等） | O | APIレスポンス確認 |
API設計領域は外部システムとの相互運用性と開発者体験を決定する核心要素です。RESTful規則の一貫した適用とSpringDocを通じたAPIドキュメント化は必須要件です。
32.5.2.1. API設計検証詳細基準
API設計項目の検証は以下の詳細基準を適用します。
- RESTful URLはリソースを名詞形複数名称で表現しなければなりません（例：
/api/users、/api/products）。 - URLパスに動詞を使用しません（例：
/api/getUsers未使用）。 - 標準エラーレスポンスには最低限
code、message、timestampフィールドを含めなければなりません。 - ISO 8601日付形式は
yyyy-MM-dd'T'HH:mm:ss.SSSZパターンに従います。 - ページネーションレスポンスには
page、size、totalElements、totalPagesフィールドを含めなければなりません。
32.5.3. 項目要約
セキュリティおよびAPIチェックリストの全項目数と分類別分布は以下のとおりです。
| 領域 | 必須(O) | 推奨(R) | 任意(S) | 合計 |
|---|---|---|---|---|
| セキュリティ | 12 | 3 | 0 | 15 |
| API設計 | 7 | 3 | 0 | 10 |
| 合計 | 19 | 6 | 0 | 25 |
セキュリティおよびAPIチェックリストは合計25項目で構成されます。必須項目19個を全て充足しなければ基本認証を取得できず、推奨項目6個の充足率に応じて優秀または最優秀認証等級が決定されます。
セキュリティ領域の必須項目比率が80%と他の領域より高い理由は、セキュリティ脆弱性がサービス全体の信頼性に致命的な影響を及ぼすためです。
32.5.4. セキュリティ検証時の留意事項
セキュリティチェックリストの検証時に以下の事項に留意しなければなりません。
- セキュリティ項目は自動検証と手動レビューを併用して検証します。ツールで検出可能な項目（シークレットのハードコーディング、SQL文字列連結等）は自動検証を優先適用します。
- OWASP Dependency-Checkスキャン結果、CVSS (Common Vulnerability Scoring System) 7以上の脆弱性が発見された場合、当該脆弱性の解消または対応方針を提示しなければなりません。
- セキュリティヘッダー設定は本番環境（prod）のレスポンスヘッダーを基準に検証します。開発環境（local/dev）ではデバッグ利便性のため一部ヘッダーを無効化することができます。
- シークレット管理は環境変数または外部シークレット管理ツールを通じて実施しなければならず、
.envファイルが.gitignoreに含まれているか確認します。
32.5.5. API検証時の留意事項
APIチェックリストの検証時に以下の事項に留意しなければなりません。
- APIドキュメント化はSpringDocが自動生成したSwagger UIを基準に検証します。別途の手書きドキュメントは認めません。
- Rate Limitingの適用有無は本番環境（prod）の設定を基準に検証します。開発環境ではRate Limitingを無効化することができます。
- APIバージョニングはURLパス方式（
/api/v1/）とヘッダー方式の両方を許可します。プロジェクト内で1つの方式を一貫して適用しなければなりません。 - ページネーション標準はリスト照会APIに限り適用します。単件照会APIには適用しません。