스프링 시큐리티: 스프링 애플리케이션 보안 솔루션
스프링으로 웹 서비스를 만들 때, 로그인·권한 체크·보안 헤더 같은 기능을 직접 구현하면 어떤 문제가 생길까요?
화면과 API가 늘어날수록 "이 경로는 인증을 빼먹었다", "저 경로는 권한 체크를 안 했다" 같은 보안 구멍이 생기기 쉽습니다. 스프링 시큐리티 는 이런 인증·인가·웹 보안 기능을 표준화된 필터 체인으로 묶어, 한 곳에서 일관되게 관리할 수 있도록 돕는 보안 프레임워크입니다.
스프링 시큐리티란
스프링 시큐리티 는 스프링 기반 애플리케이션에서 인증·인가와 주요 웹 보안 기능을 담당하는 보안 프레임워크입니다. 로그인, 권한 체크, 세션·토큰 관리, CSRF 방어 같은 반복적인 보안 로직을 한 번 표준화해 두고 재사용할 수 있게 해줍니다.
스프링 시큐리티가 해주는 것
인증(Authentication)
인증은 "이 사용자가 진짜 누구인지" 확인하는 과정입니다.
스프링 시큐리티는 다양한 인증 방식을 지원하며, 상황에 따라 적절한 방식을 선택할 수 있습니다.
| 인증 방식 | ** 적합한 상황** |
|---|---|
| HTTP Basic | 간단한 내부용 API, 테스트용 환경 등 UI 없이 빠르게 인증만 붙이고 싶을 때 |
| ** 폼 로그인(Form Login)** | 일반적인 웹 애플리케이션, 자체 로그인 화면이 있는 서비스 |
| ** 세션 기반 인증** | 서버 렌더링 웹, 전통적인 MVC 구조 서비스 |
| JWT 기반 토큰 인증 | REST API, SPA·모바일 클라이언트처럼 stateless하게 인증하고 싶을 때 |
| OAuth2 / 소셜 로그인 | "구글로 로그인", "카카오로 로그인" 같은 소셜 로그인이 필요한 서비스 |
| Remember-me 인증 | 자주 방문하는 서비스에서 브라우저를 껐다 켜도 로그인 유지하고 싶을 때 |
인가(Authorization)
인가는 "이 사용자가 어디까지 접근할 수 있는지" 결정하는 단계입니다.
| ** 인가 방식** | ** 적용 대상** |
|---|---|
| URL 기반 인가 | "/admin/**", "/mypage/**" 처럼 경로별 접근 제한 |
| ** 메서드 기반 인가** | 서비스·컨트롤러 메서드 단위로 권한을 걸고 싶을 때 |
공통 보안 공격 방어
웹 애플리케이션은 CSRF, 세션 고정, 클릭재킹 같은 공격에 노출될 수 있습니다. 스프링 시큐리티는 이를 기본적으로 방어합니다.
| 공격 종류 | 어떤 공격인가 | 스프링 시큐리티의 방어 방법 |
|---|---|---|
| CSRF | 로그인된 사용자를 속여 원치 않는 요청을 보내게 하는 공격 | CSRF 토큰을 발급하고, 상태 변경 요청마다 토큰 검증을 강제 |
| ** 세션 고정** | 공격자가 미리 만든 세션 ID를 피해자에게 심어 세션을 가로채는 공격 | 로그인 시 세션 ID를 새로 발급하여 기존 ID를 무효화 |
| ** 클릭재킹** | 보이지 않는 iframe 안에 페이지를 넣어 사용자 클릭을 유도하는 공격 | X-Frame-Options 헤더로 iframe 삽입 차단 |
스프링 시큐리티의 동작 구조
스프링 시큐리티가 요청을 처리하는 과정을 이해하려면, 먼저 서블릿 컨테이너의 필터 체인 구조를 알아야 합니다.
서블릿 기반 요청 처리 흐름
- 클라이언트에서 HTTP 요청이 들어오면, 서블릿 컨테이너는 이 요청을 ** 필터 체인 **에 먼저 통과시킵니다.
- 이 필터 체인 안에 스프링이 등록한 DelegatingFilterProxy(위임 필터 프록시)가 있습니다.
- DelegatingFilterProxy를 통해 요청은 스프링이 빈으로 등록한 여러 필터를 거친 뒤 DispatcherServlet 으로 전달됩니다.
이 구조가 중요한 이유는, 스프링 시큐리티의 모든 보안 처리가 DispatcherServlet에 도달하기 이전 에 필터 레이어에서 이루어지기 때문입니다.
스프링 시큐리티 필터 아키텍처
스프링 시큐리티에서는 DelegatingFilterProxy가 FilterChainProxy 로 요청 처리를 위임합니다.
FilterChainProxy는 내부에 여러 개의 SecurityFilterChain 을 가지고 있고, 현재 요청의 URL 패턴에 맞는 체인을 골라 그 안에 정의된 필터들을 순서대로 실행합니다.
정리하면 흐름은 다음과 같습니다.
- DelegatingFilterProxy 가 요청을 받아 FilterChainProxy 로 넘긴다.
- FilterChainProxy 가 URL 패턴에 맞는 SecurityFilterChain 을 선택한다.
- 선택된 SecurityFilterChain 안의 필터들이 인증 → 인가 → CSRF → 세션 관리 등을 순서대로 처리한다.
주의할 점
spring-boot-starter-security를 추가하면 모든 경로가 잠긴다
의존성만 추가하면 기본 Security 설정이 활성화되어, 모든 HTTP 요청에 인증이 필요해집니다. /actuator나 /h2-console 같은 개발용 경로도 막히므로, 처음에 의도치 않은 접근 차단을 경험할 수 있습니다. SecurityFilterChain 빈을 등록해서 허용할 경로를 명시적으로 열어줘야 합니다.
SecurityFilterChain과 WebSecurityConfigurerAdapter를 혼용하면 안 된다
Spring Security 5.7+에서 WebSecurityConfigurerAdapter는 deprecated입니다. SecurityFilterChain 빈 방식으로 통일해야 합니다. 둘을 섞으면 설정이 충돌하여 의도하지 않은 보안 규칙이 적용될 수 있습니다.
정리
| 항목 | 설명 |
|---|---|
| 스프링 시큐리티 | 스프링 기반 애플리케이션의 인증·인가·웹 보안을 담당하는 보안 프레임워크 |
| 인증 | "누구인지" 확인 — 폼 로그인, JWT, OAuth2 등 다양한 방식 지원 |
| 인가 | "어디까지 접근 가능한지" 결정 — URL 기반, 메서드 기반 |
| 핵심 구조 | DelegatingFilterProxy → FilterChainProxy → SecurityFilterChain |
| 동작 시점 | DispatcherServlet 이전, 서블릿 필터 체인 단계에서 처리 |
| 기본 보안 방어 | CSRF 토큰 검증, 세션 고정 방어, 클릭재킹 방어 등 기본 활성화 |