내 서비스를 지키는 3중 방어막: CSRF 방어 기술 총정리

보안은 단일 장벽이 아닌 ‘다중 방어(Defense in Depth)’가 핵심입니다. 특히 사용자의 권한을 도용하는 CSRF 공격을 막기 위해서는 브라우저, 서버, 그리고 세션 관리 차원에서의 복합적인 대응이 필요합니다.

1. 브라우저의 첫 번째 방어선: SameSite 쿠키

SameSite는 쿠키의 속성 중 하나로, 다른 사이트에서 발생한 요청에 쿠키를 포함할지 여부를 브라우저가 결정하게 합니다.

동작 원리: CSRF 공격은 브라우저가 쿠키를 자동으로 전송한다는 점을 악용합니다. SameSite 설정을 통해 이 자동 전송을 제어할 수 있습니다.
세 가지 설정값:
- Strict: 동일한 도메인에서 발생한 요청에만 쿠키를 보냅니다. 가장 안전하지만 사용자 편의성(다른 사이트 링크 클릭 시 로그인 풀림 등)이 낮아질 수 있습니다.
- Lax (현재 크롬 등 주요 브라우저의 기본값): 대체로 안전합니다. ‘안전한’ 요청(GET 방식의 링크 클릭 등)에만 쿠키를 허용합니다.
- None: 모든 요청에 쿠키를 보냅니다. 반드시 Secure 속성(HTTPS)과 함께 사용해야 합니다.

서버와 클라이언트가 ‘비밀 암호’를 공유하는 방식입니다.

동작 원리:
1. 사용자가 로그인하거나 폼(Form)을 요청할 때, 서버는 임의의 난수 토큰을 생성하여 사용자의 세션에 저장하고 클라이언트에게 전달합니다.
2. 클라이언트는 데이터 수정 요청(POST, PUT 등)을 보낼 때 이 토큰을 HTTP 헤더나 파라미터에 포함합니다.
3. 서버는 요청에 포함된 토큰과 세션에 저장된 토큰이 일치하는지 확인합니다.
핵심: 공격자는 사용자의 쿠키는 가질 수 있을지 몰라도, 서버가 발행한 고유한 토큰값은 알 수 없으므로 요청을 위조할 수 없습니다.

서버가 요청을 받았을 때, “이 요청이 정말 우리 사이트에서 보낸 것이 맞는가?”를 HTTP 헤더 정보를 통해 확인하는 방법입니다.

Origin 헤더: 요청이 시작된 도메인(프로토콜, 호스트, 포트) 정보를 담고 있습니다. (예: https://ci2u.com)
Referer 헤더: 요청이 발생하기 직전의 페이지 URL 정보를 담고 있습니다. (어떤 페이지를 거쳐 왔는가?)
검증 방법: 서버 측 미들웨어에서 request.headers['origin'] 값을 확인하여, 허용된 우리 서비스의 도메인이 아니면 요청을 즉시 차단(403 Forbidden)합니다.
특징: 구현이 매우 간단하여 1차적인 방어선으로 훌륭합니다.

어느 하나만 선택하는 것이 아니라, 상황에 맞게 조합하는 것이 베스트 프랙티스입니다.

웹 보안은 공격자보다 한 발 앞서 나가는 준비성에서 시작됩니다.

[함께 읽어볼 만한 주제]

전문가 코멘트: 보안은 ‘창과 방패의 싸움’입니다. SameSite가 기본값이 된 요즘에도 교묘한 우회 공격은 존재합니다. 따라서 CSRF 토큰과 같은 서버 측 검증을 반드시 병행하시길 권장합니다.