반응형

security-design 3

8편. CSRF - 왜 기본이 켜져 있고, 언제 꺼야 하는가

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

6편. Method Security - @PreAuthorize는 언제 써야 하는가

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

4편. UserDetailsService와 인증 정보의 경계 - 왜 엔티티를 직접 쓰면 안 되는가

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

반응형