이슈 배경
현재 요청 로깅은 운영 편의보다 정보 유출 리스크가 훨씬 크다.
- 프로덕션 배포 전 가장 먼저 막아야 할 항목이다.
RequestLoggingFilter가 모든 요청의 전체 헤더와 바디를 INFO 로 남긴다.
- 실제 로그에 아래 값이 평문으로 남는 것을 확인:
authorization: Bearer ... (access token)
cookie: refreshToken=..., accessToken=..., JSESSIONID=...
- 요청 바디(사용자 입력) 예:
{"firstChat":"hi"}, {"firstChat":"안녕"}
- 웹소켓 업그레이드(handshake) 요청의 쿠키도 그대로 남는다.
- JWT 시크릿 관리와 별개로, 발급된 토큰 자체가 로그에 평문으로 있어 로그 접근만으로 계정 탈취가 가능하다.
작업 내용 or 논의 내용
- INFO 로그에서 헤더/바디 전체 덤프 제거 →
method / uri / status / 소요시간 / ip / user-agent만 한 줄로 기록
- 헤더 확인이 필요한 디버깅은 DEBUG 레벨에서만, 민감 헤더는 값 전체를 마스킹
Authorization, Cookie, Set-Cookie (+ X-Auth-Token, X-Api-Key 등)
- 쿠키 내부 키(
accessToken/refreshToken)를 개별 파싱하지 말고 헤더 값 통째로 마스킹
- 요청 바디 로깅은 기본 제거 (로그인/회원가입 바디에 비밀번호 포함). 특정 엔드포인트에 꼭 필요하면 DEBUG 플래그 + 필드 allowlist로만 제한
- 웹소켓 handshake 요청에도 동일 정책 적용
finally에서 기록해 예외로 끝난 요청도 상태/시간을 남기기
이슈 배경
현재 요청 로깅은 운영 편의보다 정보 유출 리스크가 훨씬 크다.
RequestLoggingFilter가 모든 요청의 전체 헤더와 바디를 INFO 로 남긴다.authorization: Bearer ...(access token)cookie: refreshToken=..., accessToken=..., JSESSIONID=...{"firstChat":"hi"},{"firstChat":"안녕"}작업 내용 or 논의 내용
method / uri / status / 소요시간 / ip / user-agent만 한 줄로 기록Authorization,Cookie,Set-Cookie(+X-Auth-Token,X-Api-Key등)accessToken/refreshToken)를 개별 파싱하지 말고 헤더 값 통째로 마스킹finally에서 기록해 예외로 끝난 요청도 상태/시간을 남기기