🧩 CORS & CSRF 보안 기초 - 요청 보호 기초: CSRF와 CORS 구조

📖 들어가며

이제부터는 웹 보안의 가장 핵심적인 두 가지 주제, CORS와 CSRF를 다룬다.

이 둘은 프레임워크를 떠나 모든 웹 애플리케이션에서 발생할 수 있는 취약점이며,

Spring Security의 기본 원리를 제대로 이해하기 위해서는 필수 개념이다.

이번 파트에서는

• 브라우저 단에서의 요청 보호 메커니즘(CORS)
• 서버 단에서의 위조 방지 토큰 검증(CSRF)
• 그리고 Spring Security 내 실제 구현 구조 까지 단계별로 살펴본다.
  

---

#1. CORS란 무엇인가?

✅ Cross-Origin Resource Sharing (교차 출처 리소스 공유)

브라우저는 서로 다른 출처(origin) 간의 리소스 접근을 기본적으로 차단한다.

이 정책이 바로 Same-Origin Policy(SOP)이며,

CORS는 SOP의 예외를 안전하게 열어주는 명시적 허용 규칙이다.

🌐 출처(Origin)의 구성 요소

구성 요소	예시
프로토콜	http / https
도메인	localhost / example.com
포트번호	8080 / 4200

즉, 다음은 서로 다른 출처이다.

http://localhost:8080   ≠   http://localhost:4200

---

⚙️ 기본 동작

• UI (http://localhost:4200) → Backend (http://localhost:8080) 요청이 다른 출처 간에 이루어지므로, 브라우저는 이를 “의심스러운 요청”으로 판단하고 차단한다.
  

이때 백엔드가 다음과 같은 헤더를 응답으로 반환하면, 브라우저는 요청을 허용한다.

Access-Control-Allow-Origin: http://localhost:4200
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

---

🧭 실제 예시 (Mermaid 구조도)

---

🧱 Spring Security 기반 CORS 설정

http.cors(cors -> cors.configurationSource(request -> {
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowedOrigins(List.of("http://localhost:4200"));
    config.setAllowedMethods(List.of("*"));
    config.setAllowedHeaders(List.of("*"));
    config.setAllowCredentials(true);
    config.setMaxAge(3600L);
    return config;
}));

• preflight 요청(OPTIONS) 시 브라우저가 먼저 백엔드의 정책을 확인
• 허용된 경우 실제 API 호출을 수행
• 헤더는 Access-Control-Allow-* 값으로 자동 주입된다

---

🧩 실무에서 주의할 점

구분	설명
❌ *(별표) 남용	개발 편의는 높지만, 보안상 위험함
✅ 구체적 Origin 명시	필요 출처만 허용 (localhost, 배포 도메인 등)
✅ preflight 캐시	maxAge로 성능 개선 (보통 3600초~24시간)

---

#2. CSRF란 무엇인가?

✅ Cross-Site Request Forgery (사이트 간 요청 위조)

CSRF는 해커가 사용자의 세션을 악용하여,

의도하지 않은 요청을 서버에 보내는 공격이다.

즉, 해커가 사용자 대신 “정상 요청”을 보내도록 속이는 행위이다.

---

📖 공격 시나리오

➡ 브라우저는 동일한 세션 쿠키(JSESSIONID)를 첨부하기 때문에,

서버는 “정상적인 요청”으로 오인하게 된다.

---

⚔️ 방어 원리: CSRF 토큰

Spring Security는 CSRF Token이라는 1회용 인증 토큰을 생성하여

요청 검증 시 “쿠키 값 + 요청 헤더 값”의 일치 여부를 확인한다.

구분	설명
쿠키	XSRF-TOKEN – 백엔드가 생성해 프론트에 전달
요청 헤더	X-XSRF-TOKEN – 프론트에서 쿠키 값을 읽어 헤더에 삽입
검증 방식	두 값이 일치하면 요청 허용, 불일치 시 403 반환

---

💡 검증 플로우

---

🧠 Spring Security 내부 동작 요약

구성 요소	역할
CsrfToken 인터페이스	토큰의 구조 정의
CookieCsrfTokenRepository	쿠키 기반 저장소 구현
CsrfFilter	요청 시 토큰 검증 수행
OncePerRequestFilter	요청당 1회 필터 실행
CsrfTokenRequestAttributeHandler	요청 헤더의 토큰 값을 추출

---

🧱 Spring Security 설정 예시

http.csrf(csrf -> csrf
    .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
    .csrfTokenRequestHandler(new CsrfTokenRequestAttributeHandler())
    .ignoringRequestMatchers("/register", "/contact")
);

http.addFilterAfter(new CsrfCookieFilter(), BasicAuthenticationFilter.class);

• withHttpOnlyFalse() : JS가 쿠키 읽을 수 있도록 설정
• CsrfCookieFilter : 토큰을 지연 생성 후 쿠키 렌더링
• /register, /contact : 공용 API는 CSRF 보호 제외

---

#3. Angular/React UI 측 처리 흐름

// 로그인 성공 시 쿠키 읽기
const xsrf = getCookie('XSRF-TOKEN');
sessionStorage.setItem('XSRF-TOKEN', xsrf!);

// 요청 인터셉터에서 헤더 추가
if (xsrf) {
  req = req.clone({
    headers: req.headers.set('X-XSRF-TOKEN', xsrf),
    withCredentials: true
  });
}

• getCookie() → 쿠키 값 추출
• sessionStorage에 보관
• 이후 모든 API 요청 시 헤더에 자동 포함

---

#4. BCryptPasswordEncoder 디버깅 예시

CSRF 보호와 함께 자주 쓰이는 비밀번호 해싱도 짚고 넘어가자.

BCryptPasswordEncoder encoder = new BCryptPasswordEncoder();
String raw = "EazyBytes@12345";
String encoded = encoder.encode(raw);

System.out.println(encoded);
System.out.println(encoder.matches(raw, encoded)); // true

구분	내용
알고리즘	bcrypt (adaptive hash, salt 자동 추가)
강점	느린 계산으로 무차별 대입 공격 방어
Salt 저장	해시 내부에 포함됨 (비교 시 자동 추출)

---

---

#5. 요약 비교표

항목	CORS	CSRF
공격 대상	브라우저 정책	서버 요청 위조
주체	브라우저 보안 정책	해커의 위조 요청
주요 원인	다른 Origin 간 요청	동일 쿠키의 자동 첨부
방어 방식	Access-Control-Allow-Origin	CSRF Token (쿠키 + 헤더)
Spring Security 설정	http.cors()	http.csrf()
프론트 참여 필요	❌ 없음	✅ 쿠키 읽어 헤더 전송

---

#6. 정리

CORS는 “누가 나에게 접근할 수 있는가”,

CSRF는 “누가 나를 대신해서 행동할 수 있는가”에 대한 문제다.

• CORS = 브라우저가 지켜주는 방화벽
• CSRF = 서버가 검증하는 방패막이

실제 서비스에서는 두 가지를 동시에 고려해야 한다.

Spring Security는 이 두 계층을 모두 제어할 수 있는

가장 강력한 보안 프레임워크 중 하나다.