조용한 개발 노트

이 글은 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 공식 문서를 기반으로, Method Security가 무엇인지보다 언제 사용해야 하고, 언제 사용하면 안 되는지를 설계 관점에서 정리합니다.Method Security는 강력하지만, 무분별하게 사용하면 보안 규칙과 비즈니스 로직의 경계를 무너뜨립니다.들어가며Spring Security를 어느 정도 사용하다 보면 자연스럽게 이런 코드가 등장합니다.@PreAuthorize("hasRole('ADMIN')")public void deleteUser(Long userId) { ... }처음엔 매우 좋아 보입니다.보안 로직이 선언적으로 보인다if문이 사라진다컨트롤러가 깔끔해진다하지만 이 애노테이션은 언제든 남용될 수 있는 도구이기도 합니다.1. Method Security는 ..

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

이 글은 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 ...

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