ポートフォリオに関する現段階での面接対策
現在開発中のポートフォリオに関して、面接で聞かれる可能性のある認証周りの内容をまとめてみました。
まず押さえる：このアプリの認証の仕組み
一言で言うと 「ログイン成功 → サーバー側セッションにユーザー情報を保存 → 各画面でセッションを確認」 です。
認証フロー（概要）
実装の要点
| 項目 | このアプリでの実装 |
|---|---|
| パスワード保存 | 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 列の定義 |