조용한 개발 노트

브라우저에서 API를 호출하다 보면, 서버 로직과는 무관하게 요청이 차단되는 상황을 자주 마주한다.콘솔에는 다음과 같은 메시지가 출력된다.“Blocked by CORS policy”이 문제는 Spring 코드의 버그가 아니라, 브라우저 보안 정책과 HTTP 응답 설계의 문제다.이 글에서는 Same-Origin Policy가 무엇인지, CORS는 왜 필요한지, 그리고 Spring Web에서 이 문제를 어디서 해결해야 하는지 정리한다.1. Same-Origin Policy란 무엇인가?Same-Origin Policy는 브라우저가 기본적으로 적용하는 보안 정책이다.여기서 Origin은 다음 세 가지 요소의 조합이다.프로토콜 (http / https)호스트 (도메인)포트이 세 가지 중 하나라도 다르면, 브라우저..

웹 애플리케이션에서는 모든 요청에 공통으로 적용해야 하는 로직이 존재한다.인증 및 인가요청/응답 로깅트랜잭션 경계 설정요청 컨텍스트 초기화Spring Web MVC는 이러한 횡단 관심사를 처리하기 위해 Filter와 Interceptor라는 두 가지 확장 지점을 제공한다.이 글에서는 두 컴포넌트의 역할과 차이를 정리하고, 어떤 경우에 무엇을 선택해야 하는지 기준을 잡아본다.1. Filter의 위치와 역할Filter는 서블릿 컨테이너 레벨에서 동작하는 컴포넌트다.HTTP 요청이 DispatcherServlet에 도달하기 전에, 또는 응답이 클라이언트로 나가기 전에 Filter 체인을 거친다.DispatcherServlet 이전 단계에서 실행ServletRequest / ServletResponse 기반Sp..

30편에서는 Spring Security 설정과 요청 흐름을 한 장 요약으로 정리했습니다.이번 글에서는 그 요약을 실제 운영 상황에 적용해,장애가 발생했을 때 어디부터 확인해야 하는가를 사례 중심으로 정리해보겠습니다.이 글의 목적은 “설정을 많이 아는 것”이 아니라, 문제 발생 시 추적 경로를 바로 떠올리는 것입니다.사례 1. 특정 시점부터 모든 요청이 401로 떨어진다증상정상 동작하던 API가 갑자기 전부 401컨트롤러 로그가 전혀 남지 않음1차 판단MVC 진입 전 차단Security Filter Chain 문제확인 포인트Authorization 헤더 유무JWT 만료(exp) 시각JWT 검증 키 변경 여부자주 발생하는 원인Access Token 만료 시간 단축 후 클라이언트 미반영서명 키 로테이션 후 ..

21편부터 29편까지 우리는 Spring Security를요청 흐름Filter Chain 구조JWT 인증성능과 운영보안 이벤트 설계관점에서 단계적으로 정리했습니다.이번 글에서는 이 내용을“실무에서 바로 참고할 수 있는 한 장 요약”형태로 정리합니다.1. Spring Security의 위치 요약Client → Security Filter Chain → DispatcherServlet → Spring MVC핵심은 이것입니다.Security는 MVC 이전에 동작Filter 기반 구조컨트롤러와 분리된 보안2. Security Filter Chain 핵심 구성구성 요소역할실무 포인트DelegatingFilterProxy서블릿 ↔ Security 연결시작 지점SecurityContextPersistenc..

26편에서는 Refresh Token의 필요성과 설계 이유를, 28편에서는 대규모 트래픽 환경에서의 Security 성능 포인트를 정리했습니다.이번 글에서는 보안을 “기능”이 아니라운영과 감사의 관점에서 바라보며, 어떤 보안 이벤트를, 언제, 어떻게 기록해야 하는지를 구조적으로 정리해보겠습니다.1. 왜 보안 이벤트 설계가 필요한가보안 사고는 보통 이렇게 시작합니다.이상한 로그인 알림토큰이 갑자기 무효화됨특정 계정에서 반복된 401/403이때 가장 먼저 드는 질문은:“무슨 일이 언제 어디서 일어났지?”입니다.이 질문에 답하려면, 보안 이벤트가 사전에 잘 정의되고 기록되어 있어야 합니다.2. 반드시 기록해야 할 보안 이벤트실무 기준으로 다음 이벤트들은 반드시 기록 대상으로 삼는 것이 좋습니다.로그인 성공로그..

27편에서는 JWT 인증을 실무에서 어떻게 설계해야 하는지를 패턴과 실수 중심으로 정리했습니다.이번 글에서는 그 설계를“트래픽이 많아졌을 때 어디서 병목이 생기고, 무엇을 줄여야 하는가”라는 관점에서 살펴보겠습니다.보안은 강화할수록 성능 비용이 증가합니다. 이 글의 목표는 보안을 유지하면서도 병목을 만들지 않는 지점을 명확히 짚는 것입니다.1. Security 성능 병목은 어디서 생길까대규모 트래픽 환경에서 Security로 인한 병목은 대부분 다음 지점에서 발생합니다.토큰 검증 비용Security Filter Chain 과도한 실행인증/인가 판단의 반복외부 시스템(인증 서버, DB) 의존즉,요청마다 수행되는 작업의 “개수와 비용”이 핵심입니다.2. Access Token 검증 비용 줄이기JWT 기반 인..

26편에서는 Stateless 인증 환경에서 Refresh Token이 왜 필요한지를 보안·운영·UX 관점에서 정리했습니다.이번 글에서는 그 개념을 실무 설계 패턴으로 구체화하고, 현장에서 자주 발생하는 실수 사례를 함께 정리해보겠습니다.1. 실무에서 가장 많이 쓰는 JWT 기본 패턴실무에서 가장 안정적으로 쓰이는 기본 패턴은 다음과 같습니다.Access Token: 짧은 만료(5~15분)Refresh Token: 긴 만료(2주~1개월)Access Token → Authorization 헤더Refresh Token → HttpOnly 쿠키이 패턴의 핵심은탈취 가능성이 높은 토큰과 보호가 필요한 토큰을 분리하는 것입니다.2. 패턴 #1 – Refresh Token Rotation가장 권장되는 보안 패턴입니..

25편에서는 Security · MVC 실무 설정에서 자주 발생하는 실수들을 요청 흐름 기준으로 정리했습니다.이번 글에서는 JWT 기반 Stateless 인증 환경에서 항상 함께 등장하는 질문을 다뤄보겠습니다.Access Token만 쓰면 안 될까? 왜 굳이 Refresh Token이 필요할까?이 질문의 답은 편의성이 아니라 보안과 운영의 균형에 있습니다.1. Stateless 인증의 기본 전제JWT 기반 인증은서버가 인증 상태를 저장하지 않는다는 전제를 가집니다.즉,요청마다 토큰을 보내고요청마다 토큰을 검증합니다.이 구조는서버 확장에 유리하고세션 동기화가 필요 없으며클라우드 환경에 적합하지만, 토큰이 유출되면 바로 위험해진다는 단점도 함께 가집니다.2. Access Token만 사용할 때의 문제만약 A..

24편에서는 Security · MVC · Exception을 요청 기준으로 하나의 흐름으로 통합 정리했습니다.이번 글에서는 그 흐름을 바탕으로, 실무에서 가장 자주 발생하는 Security · MVC 설정 실수를증상원인해결 방법순서로 정리해보겠습니다.실수 #1. 토큰이 있는데도 401이 나온다증상Authorization 헤더에 JWT가 있음하지만 항상 401 Unauthorized원인JWT 인증 필터가 Security Filter Chain에 등록되지 않음필터 순서가 AuthorizationFilter 뒤에 위치Bearer prefix 누락 또는 형식 오류해결JWT 인증 필터가 SecurityContextPersistenceFilter 이후에 위치하는지 확인AuthorizationFilter 이전에 인..

12편부터 23편까지 우리는 Spring MVC 요청 흐름 위에DispatcherServletHandlerMapping / HandlerAdapterArgumentResolver / ValidationHttpMessageConverterExceptionResolverSpring Security Filter ChainJWT 인증 흐름을 하나씩 분리해서 살펴봤습니다.이번 글에서는 이 모든 요소를“요청 하나가 들어왔을 때 실제로 어떤 경로를 타는가”라는 관점에서 하나의 흐름으로 통합해보겠습니다.1. 전체 요청 흐름 한 줄 요약Client → Security Filter Chain → DispatcherServlet → HandlerMapping → HandlerAdapter ..