ポートフォリオに関する現段階での面接対策

現在開発中のポートフォリオに関して、面接で聞かれる可能性のある認証周りの内容をまとめてみました。

まず押さえる：このアプリの認証の仕組み

一言で言うと 「ログイン成功 → サーバー側セッションにユーザー情報を保存 → 各画面でセッションを確認」 です。

認証フロー（概要）

実装の要点

項目	このアプリでの実装
パスワード保存	BCrypt ハッシュ（平文は DB に保存しない）
ログイン状態の保持	HttpSession（`loginUserEmail`, `loginUserName`）
保護	各 Controller で手動チェック → なければ `/login` へ
ログアウト	`session.invalidate()`
Spring Security	フル導入はしていない（`BCryptPasswordEncoder` のみ利用）

聞かれやすいテーマ（想定 Q&A）

1. 「認証方式は何？なぜそれ？」

答えの骨子:

セッションベース認証（サーバーがログイン状態を覚える）
ブラウザは JSESSIONID の Cookie を送る
学習段階では分かりやすく、Spring MVC の流れ（Controller → Session → DB）を自分で書ける

JWT との違い（聞かれたら）:

セッション: 状態をサーバー側が持つ。ログアウトで即無効化しやすい
JWT: トークンをクライアントが持つ。API / SPA 向き。今回の Thymeleaf サーバー描画とは相性が違う

2. 「パスワードはどう守っている？」

答えの骨子:

登録時: BCryptPasswordEncoder.encode() でハッシュ化 → password_hash 列に保存
ログイン時: matches(入力, DBのハッシュ) で照合
平文パスワードは保存・ログ出力しない

深掘り:

BCrypt は ソルト付き・計算コストが高い ので総当たりに強い
DB が漏れても、元のパスワードは復元しにくい

3. 「ログイン失敗時、なぜ『メールかパスワードが違う』とだけ出す？」

答えの骨子:

ユーザー不存在 / パスワード不一致を 同じメッセージ にしている
「このメールは登録されていない」と分かると、アカウントの存在が推測される（ユーザー列挙）のを防ぐ意図

正直に言える注意点:

新規登録では「メール重複」エラーが出るので、登録画面経由ではメールの存在が分かる 点はトレードオフ

4. 「未ログインで /top や /profile/edit に直接アクセスしたら？」

答えの骨子:

TopController, ProfileEditController などで session.getAttribute("loginUserEmail") を確認
null なら redirect:/login
スキル編集でも同様（ログアウト後に /skill/edit → ログインへ、は既に確認済み）

自分で確認しておくとよい点:

GET と POST の両方でガードしているか（POST だけ抜けていると穴になる）
プロフィール更新の POST も、セッション未設定時の動きを一度確認しておく

5. 「Spring Security を使っていないのは問題？」

正直な答え:

今は Security の一部（BCrypt）だけ 使っている
URL 保護・CSRF・セッション固定対策などは フレームワーク任せではなく、自分で書いた部分と未対応部分がある

本番なら:

spring-boot-starter-security で Filter チェーン に任せる
ログイン必須 URL を @PreAuthorize や authorizeHttpRequests で一括設定
重複した if (session == null) を減らせる

言い方の例:

学習目的でセッションの流れを理解した。本番規模なら Spring Security に寄せる。

6. 「CSRF 対策は？」（かなり聞かれやすい）

現状:

Spring Security 未導入のため、標準の CSRF トークン保護は入っていない
フォームは method="post" のみ

答え方:

「現段階では未実装。悪意あるサイトからログイン中ユーザーの POST を送られる CSRF リスクがある」
「Spring Security 導入時に Thymeleaf 連携の CSRF トークンを有効にする」

知っておく用語: CSRF = ログイン済みユーザーのブラウザから、知らないうちに POST される攻撃

7. 「セッション Cookie は安全？」

Render（HTTPS）前提で話すと:

本番 HTTPS なら Cookie に Secure（HTTPS のみ送信）を付けるのが望ましい
HttpOnly（JavaScript から読めない）で XSS による Cookie 盗難を抑える
Spring Security / サーバー設定で調整する話

言い方の例:

HTTPS 上で動かしている。Cookie 属性の細かい設定は Spring Security 導入時に見直す。

8. 「ログアウトはどう効く？」

答え:

POST /logout → session.invalidate() でサーバー側セッションを破棄
以降 JSESSIONID は無効 → 保護ページは /login へ

確認: ログアウト後にブラウザバックで画面が見える場合、キャッシュ表示 のことがある。再読み込みや直接 URL ではログインへ行く、を自分で試しておく。

9. 「新規登録後、なぜいきなり TOP？」

答え:

登録成功後に そのままセッションをセット して redirect:/top（再ログイン不要の UX）
パスワードは登録時点で BCrypt 化してから保存

10. 「他ユーザーのデータを書き換えられない？」

答え:

プロフィール更新は セッションの email で findByEmail → 自分の行だけ 更新
URL に userId を渡していないので、ID すり替え攻撃の面は小さい

深掘りで聞かれたら:

将来 userId を URL に載せるなら、「ログイン中ユーザーと一致するか」を必ずサーバーで確認（認可 authorization）

ポートフォリオ提出前の「自分用チェックリスト」

口頭説明 + デモで見せられると印象が良い。

確認	期待する動き
未ログインで `/top`	`/login` へ
未ログインで `/profile/edit`	`/login` へ
ログアウト後	保護 URL は使えない
誤パスワード	同じエラーメッセージ
DB の `password_hash`	`$2a$...` のような BCrypt 文字列
本番 URL	HTTPS（Render のデフォルト）

伝える言い方（例）

認証は セッションベース で、パスワードは BCrypt でハッシュ保存しています。保護が必要な URL は Controller でセッションを確認しています。Spring Security は BCrypt 部分だけ使い、Filter による一括保護や CSRF は 意図的に簡略化している（または今後の改善点） です。本番ポートフォリオとしては、Spring Security 導入と CSRF、Cookie 属性の hardened、環境変数での秘密情報管理（DB・AWS キー）を次のステップにしたいです。

「全部完璧」と言うより、選んだ理由 + 知っているリスク + 次にやること の3点セットが信頼される。

覚えておくとよい用語（短く）

用語	意味
認証（Authentication）	「あなたは誰か」— ログイン
認可（Authorization）	「何をしてよいか」— 他人のデータを触れない等
セッション	サーバーがログイン状態を覚える仕組み
ハッシュ	一方向変換。パスワード保存用
CSRF	ログイン中ユーザーの意図しない POST
ユーザー列挙	存在するメールアドレスを推測されること

関連ファイル（説明時の参照用）

ファイル	役割
`LoginController.java`	ログイン・ログアウト、BCrypt 照合、セッション保存
`UserRegistrationController.java`	新規登録、登録後の自動ログイン
`UserRegistrationService.java`	パスワードの BCrypt 化、DB 保存
`TopController.java`	セッション確認 → 未ログインなら redirect
`ProfileEditController.java`	プロフィール編集のセッション確認
`V1__create_users.sql`	`password_hash` 列の定義