[hotfix] #170 - 크로스사이트 재발급 오류 수정 - #172
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
Walkthrough인증 쿠키의 Changes인증 보안 흐름
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant OriginValidationFilter
participant JwtAuthenticationFilter
Client->>OriginValidationFilter: 보호된 인증 경로 요청 및 Origin 전달
OriginValidationFilter->>OriginValidationFilter: 허용 URL과 Origin 비교
OriginValidationFilter->>JwtAuthenticationFilter: 검증 통과 요청 전달
OriginValidationFilter-->>Client: 검증 실패 시 403 응답
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/java/com/Timo/Timo/global/auth/utils/CookieUtil.java`:
- Line 14: CookieUtil의 SameSite("None") 설정으로 크로스사이트 쿠키 요청이 허용되므로, CSRF가 비활성화된
SecurityConfig에 방어 검증을 추가하세요. logout, withdraw, reissue 상태 변경 엔드포인트에서 CSRF 토큰 검증
또는 신뢰할 수 있는 Origin/Referer 검증을 적용하고, 정상적인 요청 흐름은 유지하세요.
- Line 14: Update the cookie configuration in CookieUtil so SameSite=None is
used only when the configured cookie-secure setting is true. For local HTTP
profiles with cookie-secure=false, apply an appropriate non-None SameSite
policy, while preserving the existing secure production behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 02cfe1d3-5d65-43a5-8eb2-fc8a684fcb8b
📒 Files selected for processing (1)
src/main/java/com/Timo/Timo/global/auth/utils/CookieUtil.java
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/main/java/com/Timo/Timo/global/auth/filter/OriginValidationFilter.java (1)
32-36: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win모바일 앱 등 비브라우저 클라이언트의
Origin부재로 인한 차단 가능성을 확인해 주세요.현재 로직은
origin == null일 경우 즉시 403(Forbidden)을 반환하여 차단합니다.
웹 브라우저 환경에서는SameSite=None설정에 따른 CSRF 공격을 방어하기 위해Origin을 필수로 검증하는 것이 매우 안전하고 적절한 조치입니다.하지만 모바일 앱(iOS, Android)이나 서버 간(S2S) API 호출 등 브라우저가 아닌 클라이언트에서는 기본적으로
Origin헤더를 전송하지 않습니다. 만약 이 API가 모바일 앱에서도 사용된다면 정상적인 토큰 재발급이나 로그아웃 요청이 차단될 위험이 있습니다. 서비스가 웹 전용인지 확인하시고, 만약 다중 클라이언트를 지원해야 한다면 커스텀 헤더 기반의 검증 등 추가적인 CSRF 방어책을 고려해 보세요.추가로,
allowedFrontendUrls환경변수 설정 시 끝에 슬래시(/)가 포함되어 있으면Origin헤더(끝에 슬래시가 없음)와 일치하지 않아 차단될 수 있으므로 설정 값에 주의가 필요합니다.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/java/com/Timo/Timo/global/auth/filter/OriginValidationFilter.java` around lines 32 - 36, Review OriginValidationFilter’s client support and decide whether non-browser clients must access these endpoints; if so, do not reject missing Origin unconditionally, and add an explicitly authenticated alternative such as the project’s approved custom-header validation while preserving CSRF protection for browser requests. Also normalize or validate allowedFrontendUrls entries so trailing slashes do not prevent matching the browser Origin header.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/java/com/Timo/Timo/global/config/SecurityConfig.java`:
- Line 74: Add an originValidationFilterRegistration bean in SecurityConfig that
accepts OriginValidationFilter, wraps it in FilterRegistrationBean, and disables
registration with setEnabled(false). Keep the existing
addFilterBefore(originValidationFilter, JwtAuthenticationFilter.class) ordering
unchanged so the filter runs only within the Spring Security chain.
---
Nitpick comments:
In `@src/main/java/com/Timo/Timo/global/auth/filter/OriginValidationFilter.java`:
- Around line 32-36: Review OriginValidationFilter’s client support and decide
whether non-browser clients must access these endpoints; if so, do not reject
missing Origin unconditionally, and add an explicitly authenticated alternative
such as the project’s approved custom-header validation while preserving CSRF
protection for browser requests. Also normalize or validate allowedFrontendUrls
entries so trailing slashes do not prevent matching the browser Origin header.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: b12b1d3f-91f3-4fa0-bcfc-b733f09900a2
📒 Files selected for processing (2)
src/main/java/com/Timo/Timo/global/auth/filter/OriginValidationFilter.javasrc/main/java/com/Timo/Timo/global/config/SecurityConfig.java
스웨거로는 쿠키 확인과 테스트를 어떻게 해야되는지 몰라서 엄청난 끝없는 403 에러(Swagger의 다중 @CookieValue 조합 버그) 끝에 포스트맨으로 토큰 재발급을 받아서 테스트 결과 화면에 올려놨숩니다.. Swagger의 다중 @CookieValue 조합 버그 |
3 participants
관련 이슈 🛠
작업 내용 요약 ✏️
프로덕션 환경(프론트
timo-client.vercel.app↔ 백엔드api.timo.kr)에서 access token 재발급(/api/v1/auth/reissue)이 401로 실패하는 문제를 수정했습니다. 인증 쿠키의SameSite속성이Strict로 설정되어 있어, 크로스사이트 XHR 요청 시 브라우저가 쿠키를 아예 전송하지 않아 발생한 문제였습니다.주요 변경 사항 🛠️
createCookie,expireCookie두 메서드 모두sameSite를Strict에서None으로 변경트러블 슈팅 ⚽️
refreshToken쿠키가SameSite=Strict인 경우 axios를 통한 백그라운드 재발급 요청(XHR)에는 쿠키가 전송되지 않음을 확인함window.location.href를 통한 풀 페이지 리다이렉트(top-level navigation)라Strict여도 우연히 통과되어, 재발급 단계에서만 문제가 드러났던 것으로 파악됨SameSite=None은Secure=true가 함께 있어야 브라우저가 쿠키를 인정하므로, 배포 환경의cookie-secure설정이true인지, HTTPS로 서비스되고 있는지 별도 확인함SameSite=None전환에 따른 CSRF 노출 우려를 검토함. 현재 CORS 설정에서allowedOrigins를 프론트 도메인으로 한정하고allowCredentials(true)를 사용 중이며, 쿠키에는 이미httpOnly(true)가 적용되어 있어 XSS를 통한 탈취 위험도 낮다고 함,,테스트 결과 📄
스크린샷 📷
리뷰 요구사항 📢
📎 참고 자료 (선택)
Summary by CodeRabbit
요약(릴리스 노트)
버그 수정
secure여부에 따라 동적으로 적용하도록 변경했습니다(쿠키 생성/만료 모두 동일 적용).보안 강화