조용한 개발 노트

이 글은 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의 약자입니다. 핵심은 이것입니다.사용자가 ..