조용한 개발 노트

이 글은 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) 이후 단계인 인가(Authorization)가 어디에서, 어떤 기준으로 판단되어야 하는지를 정리합니다.인가를 잘못 설계하면, 보안은 코드 전반으로 퍼지고 비즈니스 로직과 섞여 유지보수가 불가능해집니다.들어가며실무에서 가장 흔히 보는 인가 코드는 다음과 같습니다.if (!user.hasRole("ADMIN")) { throw new AccessDeniedException();}이 코드는 얼핏 문제 없어 보이지만, Spring Security 관점에서는 가장 피해야 할 인가 방식입니다.이 편에서는권한은 무엇인가어디에서 판단되어야 하는가어디까지 프레임워크에 맡겨야 하는가를 하나씩 짚어봅니다.1. Authoriz..

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

이 글은 Spring Security 공식 문서를 기반으로, 많은 개발자들이 처음에 갖게 되는 질문인 “Spring Security는 왜 이렇게 복잡한가?”에 답하는 것으로 시작합니다.이 시리즈의 목적은 설정 방법을 나열하는 것이 아니라, Spring Security가 어떤 문제를 풀기 위해 지금의 구조를 가지게 되었는지를 설계 관점에서 이해하는 데 있습니다.들어가며Spring Security를 처음 접하면 대부분 이런 인상을 받습니다.설정이 많다개념이 어렵다어디서 막히는지 알기 힘들다그래서 흔히 이런 선택을 합니다.일단 복사해서 쓴다보안은 프레임워크가 알아서 해주겠지라고 생각한다필요한 부분만 permitAll로 열어둔다하지만 Spring Security는 “편하게 쓰라고 만들어진 프레임워크”가 아닙니다..