조용한 개발 노트

Token은 편리하지만 통제하기 어렵다현대 시스템에서 Token은 거의 기본 선택이다.세션 저장소가 필요 없다수평 확장이 쉽다서비스 간 전달이 간단하다이 편의성 때문에 Token은 빠르게 확산된다.하지만 Token은 구조적으로 유출에 취약하고 회수에 불리하다.Bearer Token의 본질적 문제Bearer Token의 의미는 단순하다.이 Token을 가진 자는 누구든 주체로 인정된다즉, Token 자체가 신원 증명이다.이 구조에는 중요한 전제가 숨어 있다.Token은 절대 유출되지 않는다Token은 위조되지 않는다현실에서 이 전제는 거의 항상 깨진다.Token은 어디서 유출되는가Token 유출은 해킹만으로 발생하지 않는다.브라우저 저장소로그 출력프록시 헤더클라이언트 코드Token은 시스템 전반을 이동한다..

보안 사고는 대부분 신원 확인 실패에서 시작된다많은 보안 사고는 이렇게 설명된다.인증이 뚫렸다토큰이 유출됐다권한이 잘못 설정됐다하지만 이 설명들은 모두 하나의 질문으로 수렴한다.시스템은 누구를 믿었는가Identity는 이 질문에 대한 시스템의 공식적인 답이다.Identity는 계정이 아니다Identity를 사용자 계정으로만 이해하면 보안 설계는 즉시 한계를 드러낸다.현대 시스템에서 Identity는 다음을 모두 포함한다.사람서비스프로세스자동화된 작업즉, Identity는 행위를 수행하는 주체 전체를 의미한다.Identity는 무엇을 증명하는가Identity의 핵심 역할은 단순하다.지금 이 요청의 주체가 누구인가이 질문에 답하지 못하면, 그 이후의 모든 보안 판단은 의미를 잃는다.권한 검사는 Identit..

이 글은 Spring Security 공식 문서(Test)와 Spring Test 공식 문서를 기반으로, Spring Security가 적용된 애플리케이션을 테스트 코드에서 어떻게 검증해야 하는지를 설계 관점에서 정리합니다.보안 테스트는 “어떻게 통과시키는가”가 아니라, “무엇을 검증해야 하는가”가 핵심입니다.들어가며Spring Security를 붙인 이후, 테스트에서 가장 자주 마주치는 상황은 이것입니다.모든 요청이 401 또는 403으로 실패한다테스트를 위해 보안을 꺼버리고 싶어진다@WithMockUser를 아무 데나 붙이게 된다이 반응은 자연스럽지만, 그대로 따라가면 보안 테스트는 무의미해집니다.1. 보안 테스트의 목적부터 다시 정의하자보안 테스트에서 가장 먼저 정리해야 할 질문은 이것입니다.이 테..

이 글은 Spring Security 공식 문서를 기반으로 진행한 1~9편 내용을 하나의 판단 프레임으로 정리한 마무리 편입니다.Spring Security는 “어떻게 설정하는가”보다 어디까지 맡기고, 어디서 멈출 것인가가 훨씬 중요합니다. 이 글의 목적은 그 경계를 명확히 하는 것입니다.들어가며지금까지 이 시리즈에서는 반복해서 같은 질문을 던졌습니다.이 요청은 어디에서 통제되어야 하는가?보안은 기능인가, 경계인가?프레임워크가 책임져야 할 범위는 어디까지인가?10편에서는 이 질문들을 한 번에 판단할 수 있는 기준으로 정리합니다.1. Spring Security가 잘 맞는 문제 영역Spring Security는 다음 전제를 만족할 때 가장 강력합니다.HTTP 요청 경계를 명확히 보호하고 싶다인증과 인가를 ..

이 글은 Spring Security 공식 문서를 기반으로, 실무에서 반복적으로 등장하고, 결국 장애나 보안 취약점으로 이어졌던 Spring Security 안티 패턴들을 정리합니다.이 안티 패턴들의 공통점은 하나입니다. 처음에는 합리적으로 보였다는 것입니다.안티 패턴 1. permitAll로 시작해서 permitAll로 끝나는 구조Spring Security를 처음 붙일 때 가장 흔한 출발점입니다.http .authorizeHttpRequests(auth -> auth .anyRequest().permitAll() );이 설정은 “일단 서비스가 동작하게 만드는” 데는 효과적입니다. 하지만 이 상태가 오래 유지되면 문제가 됩니다.보안 규칙이 존재하지 않는다보안은 Method Security에..

이 글은 Spring Security 공식 문서를 기반으로, CSRF가 무엇인지보다 왜 Spring Security가 CSRF를 기본으로 켜두는지, 그리고 언제 꺼야 하고 언제 꺼서는 안 되는지를 판단 기준 중심으로 정리합니다.들어가며Spring Security 설정을 처음 보면 많은 개발자들이 이렇게 시작합니다.http.csrf(csrf -> csrf.disable());이 코드는 “일단 돌아가게 만들기”에는 효과적입니다. 하지만 CSRF를 끄는 순간, 애플리케이션은 다른 종류의 공격 표면을 갖게 됩니다.CSRF는 기능이 아니라, 브라우저 환경에서의 기본 안전장치입니다.1. CSRF는 어떤 문제를 막는가CSRF는 Cross-Site Request Forgery의 약자입니다. 핵심은 이것입니다.사용자가 ..

이 글은 Spring Security 공식 문서를 기반으로, 인증이 끝난 후 생성된 Authentication이 어디에 저장되고, 어떻게 전파되는지를 SecurityContext 중심으로 설명합니다.SecurityContext를 이해하지 못하면, 비동기 처리, 멀티스레드 환경, 배치 작업에서 보안 이슈를 피할 수 없습니다.들어가며Spring Security를 사용하다 보면 한 번쯤은 이런 코드를 보게 됩니다.Authentication authentication = SecurityContextHolder.getContext().getAuthentication();이 코드는 단순해 보이지만, 그 뒤에는 중요한 질문이 숨어 있습니다.이 Authentication은 어디에서 온 것일까?이 질문에 답하는 것..

이 글은 Spring Security 공식 문서를 기반으로, 인증(Authentication) 과정에서 등장하는 UserDetailsService와 도메인 사용자 엔티티 사이의 경계를 정리합니다.이 경계를 명확히 이해하지 못하면, 보안 로직이 비즈니스 코드로 새어나가고, Spring Security는 점점 통제 불가능한 프레임워크가 됩니다.들어가며Spring Security를 실무에 적용하다 보면 아주 자연스럽게 이런 고민에 도달합니다.이미 User 엔티티가 있는데 굳이 UserDetails가 필요할까?엔티티에 UserDetails를 구현하면 편하지 않을까?어차피 인증할 때 DB에서 사용자 조회하는 거 아닌가?이 질문들은 모두 합리적으로 보이지만, Spring Security 공식 문서의 관점에서는 위험..

이 글은 Spring Security 공식 문서를 기반으로, “로그인”을 화면이나 API 기능이 아니라 Spring Security의 핵심 개념인 Authentication으로 다시 정의합니다.2편에서 SecurityFilterChain이 요청을 어떻게 보호하는지 봤다면, 이번 편에서는 그 체인 안에서 인증(Authentication)이 실제로 무엇인지를 구조적으로 설명합니다.들어가며Spring Security를 처음 쓰면 “로그인”이 이렇게 느껴집니다.아이디/비밀번호를 받아서DB에서 확인하고세션이나 토큰을 발급한다하지만 Spring Security에서 인증의 본질은 다릅니다.이 요청이 누구의 요청인지, 그리고 그 근거가 무엇인지Spring Security는 이 사실을 Authentication 객체 하..

이 글은 Spring Security 공식 문서를 기반으로, Spring Security의 핵심 구조인 SecurityFilterChain을 중심으로 요청이 실제로 어떻게 보호되는지를 설명합니다.1편에서 “왜 Spring Security가 이렇게 복잡해졌는가”를 다뤘다면, 이번 편에서는 그 복잡함이 실제 요청 흐름에서 어떤 의미를 가지는지를 확인합니다.들어가며Spring Security를 설정하다 보면 다음과 같은 코드를 가장 먼저 만나게 됩니다.@BeanSecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth -> auth ...