502. 크로스 사이트 요청 위조 (CSRF) 방어 - Anti-CSRF 토큰 발급, SameSite 쿠키 속성

핵심 인사이트 (3줄 요약)

1. 본질: 크로스 사이트 요청 위조(CSRF)는 해커가 코드를 훔치는 게 아니라, 사용자가 은행 사이트에 로그인해 있는(세션이 살아있는) 찰나의 순간을 노려, 해커의 사기 사이트에서 "내 계좌로 100만 원 송금해!"라는 보이지 않는 버튼을 강제로 밟게 속여 사용자 지갑을 합법적(?)으로 털어먹는 가장 비열한 낚시(Phishing) 공격이다.
2. 가치: 아무리 튼튼한 방화벽과 비밀번호 암호화를 발라놔도, 서버는 "어? 정상 로그인한 고객의 쿠키가 담겨서 온 정상적인 송금 요청이네? 승인!"이라며 바보같이 돈을 내어준다. 이를 막기 위해 서버가 요청(Request)의 출처(Origin)를 미친 듯이 의심하고, 내가 발급한 1회용 비밀 암구호(Anti-CSRF 토큰)가 없으면 100% 튕겨내버리는 방어 아키텍처를 구축한다.
3. 융합: 백엔드가 발행하는 Anti-CSRF Token의 전통적 방패와 더불어, 최근에는 웹 생태계 인프라 자체가 진화하여 브라우저가 "남의 집에서 날아온 쿠키는 서버에 절대 안 보내!"라고 강제 차단하는 SameSite 쿠키 속성이 융합되며 CSRF라는 해킹 기법을 역사 속으로 멸종시켜 가고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: CSRF(Cross-Site Request Forgery)는 번역하면 '다른 사이트에서 위조된 요청'이다. 사용자가 네이버(정상)에 로그인해서 쿠키가 살아있는 상태다. 이때 해커가 보낸 "100만 원 당첨 쿠폰!" 링크(다른 사이트)를 멍청하게 클릭했다. 그 링크 안에는 숨겨진 자바스크립트로 <form action="네이버 비밀번호 변경" ... submit()> 이라는 투명한 폼이 0.1초 만에 실행된다. 웹 브라우저는 멍청하게도 "오, 네이버로 가는 요청이네? 그럼 내 배 속에 있는 네이버 로그인 쿠키도 같이 담아서 쏴줘야지!" 하며 해커의 조종(위조)대로 공격을 완수해 버린다.

• 필요성: 개발자가 아무리 권한 체크(인가) 로직을 짜놔도 소용없다. 왜? 해커가 찌른 게 아니라 **"정상 로그인한 권한 100%의 고객 브라우저"**가 직접 찌른 요청이기 때문이다. 서버 입장에서는 진짜 고객이 마우스 클릭한 건지, 해커의 낚시 사이트에서 투명 버튼을 밟은 건지(Forged) 구분할 눈알이 없다. 이 "눈뜬장님" 상태인 웹 프로토콜(HTTP)의 태생적인 한계, 즉 **"어느 사이트에서 날아오든 도메인만 맞으면 쿠키를 무조건 자동으로 태워 보내는 브라우저의 멍청한 친절함"**을 박살 내고 시스템의 무결성을 지키기 위해 CSRF 방어 메커니즘이 절대적으로 필요하다.

• 💡 비유: CSRF는 **'최면에 걸려 통장 비밀번호를 넘겨주는 은행 고객'**과 같습니다. 은행원(서버) 앞에는 진짜 고객(사용자)이 신분증(쿠키)을 들고 앉아 있습니다. 그래서 은행원은 아무 의심을 안 합니다. 그런데 고객의 어깨 뒤에서 최면술사(해커 사이트)가 투명 실을 매달아 고객의 입을 조종(위조된 요청)하여 "내 돈 100만 원을 최면술사 통장으로 이체해 주시오"라고 말하게 시킵니다. 은행원은 고객이 진짜로 자기 의지로 말한 건지, 최면에 걸려 헛소리하는 건지 구별할 수 없어 그냥 이체해 주고 맙니다(방어 붕괴).

• 등장 배경 및 발전 과정:

  1. 쿠키의 자동 탑승 맹점 (과거): HTTP는 원래 상태가 없는(Stateless) 놈이라 편하게 쓰라고 넷스케이프가 '쿠키(Cookie)'를 만들었다. 브라우저는 목적지 주소만 맞으면 묻지도 따지지도 않고 쿠키를 배달시켰고, 해커들은 이 맹점을 파고들어 CSRF의 황금기를 열었다.
  2. Anti-CSRF 토큰의 발명 (2000년대): 개발자들이 "이건 브라우저 탓이야!"라며 분노했고, 결국 폼(Form)을 그릴 때마다 해커는 절대 모르는 '1회용 비밀 난수(Token)'를 숨겨서 같이 던지게 하는 애플리케이션 레벨의 노가다 방패를 발명했다.
  3. 브라우저의 반성과 SameSite 국룰화 (현재): 2020년, 마침내 구글 크롬(Chrome)을 필두로 웹 인프라 진영이 각성했다. "야, 남의 사이트에서 날아갈 때는 아예 쿠키를 안 태워 보낼게(SameSite=Lax 기본값 적용)!"라며 브라우저 엔진 레벨에서 선을 그어버림으로써 CSRF 해킹 자체가 물리적으로 불가능한 시대로 패러다임이 이동했다.

• 📢 섹션 요약 비유: CSRF 방어는 **'경매장의 번호표(토큰) 확인'**입니다. 경매사(서버)가 물건을 팝니다. 갑자기 누군가 손을 듭니다(요청). 옛날엔 얼굴(쿠키)만 보고 낙찰시켰습니다(CSRF 털림). 지금은 손을 들었을 때 **"오늘 입장할 때 제가 몰래 나눠드린 1회용 비밀 번호표(Anti-CSRF 토큰)를 보여주세요!"**라고 검사합니다. 밖에서 창문으로 손만 뻗은 도둑(해커 사이트)은 번호표가 없으니 바로 경비원한테 쫓겨나는 완벽한 검문입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 전통의 절대 방패: Anti-CSRF Token (Synchronizer Token Pattern)

해커가 절대 예측할 수 없는 '랜덤한 암구호'를 1회용으로 쓰는 흑마법이다.

[ 1. 정상 서버가 화면을 줄 때 (GET) ]
  - 서버는 폼(Form) HTML을 만들면서 무작위 쓰레기값(토큰 `abc123xyz`)을 
    `<input type="hidden" name="csrf_token" value="abc123xyz">` 에 몰래 숨겨서 준다.
  - 서버 메모리(Session)에도 똑같이 `abc123xyz`를 저장해 둔다.

[ 2. 해커의 공격 시도 (POST) ]
  - 해커의 사기 사이트에서 "100만원 이체!" 폼을 강제로 날린다. 쿠키는 자동으로 날아간다.
  - 하지만 해커는 서버가 방금 만든 저 랜덤 '토큰 값'이 뭔지 절대 알 수 없다.

[ 3. 서버의 수문장 필터 (Verify) 💥 핵심 ]
  - 패킷이 서버 입구(Interceptor)에 도착한다. 쿠키가 있어서 로그인 패스는 됨.
  - 하지만 서버: "잠깐! 네 패킷 안에 숨겨진 `csrf_token` 값이 없거나, 
    내 메모리에 적어둔 `abc123xyz`랑 다르네? 넌 밖에서 온 가짜 사기꾼이야! 차단(403)!"

• 원리: 프레임워크(Spring Security 등)가 알아서 1번과 3번 로직을 0.01초 만에 튕겨낸다. 해커는 브라우저 쿠키는 훔쳐 탈 수 있어도(브라우저가 자동으로 해주니까), 서버가 폼(Form) 안에 숨겨둔 1회용 토큰 텍스트 값 자체를 남의 사이트에서 읽어낼 수 없기 때문에(SOP 정책으로 방어됨) CSRF가 100% 무력화된다.

2. 차세대 인프라 방패: SameSite 쿠키 속성

개발자가 토큰을 빼먹는 실수를 막기 위해, 아예 브라우저(크롬, 사파리)가 총대를 메고 나선 혁명.

• 원리: 서버가 로그인 완료 쿠키를 내릴 때, 꼬리표를 하나 더 단다. Set-Cookie: session_id=123; HttpOnly; SameSite=Lax

• 마법의 효과:

  • SameSite=Strict: 극단적 철벽. 네이버(A)에서 네이버(A)를 누를 때만 쿠키가 간다. 티스토리(해커 B)에서 네이버 링크를 누르면 절대 네이버 쿠키를 안 태워준다. (너무 빡빡해서 링크 타고 들어오면 다 로그아웃되어 있어 UX가 박살 남)
  • SameSite=Lax 💥 (현대 브라우저의 디폴트 정답): 평범한 링크 클릭(GET)으로 네이버 들어갈 때는 쿠키를 태워줘서 로그인 유지시켜 줌. 하지만 돈을 빼가거나 글을 지우는 파괴적 행위(POST 요청)를 외부(해커 B)에서 쏠 때는 쿠키 탑승을 강제로 거부하고 텅 빈 깡통으로 날려버림. 해커의 폼(Form) 제출 공격이 쿠키(신분증) 없이 도착하므로 서버에서 1초 컷으로 박살 남.

• 📢 섹션 요약 비유: 토큰(Token) 방어는 클럽 안에서 웨이터(서버)가 주문을 받을 때마다 **'오늘의 암구호'**를 묻는 깐깐한 방식입니다. SameSite 방어는 아예 클럽 문지기(크롬 브라우저)가 손님 이마에 **'다른 클럽 출신 바코드'**를 찍어버리는 겁니다. 다른 클럽에서 온 손님이 비싼 양주를 시키려 하면 "너 우리 식구 아니잖아!"라며 지갑(쿠키) 자체를 아예 못 열게 인프라 적으로 차단해 버리는 신세계입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 쌍둥이 빌런 비교: XSS (스크립트) vs CSRF (위조 요청)

OWASP 면접에서 100% 물어보는 개념 분리표. (둘은 공격 대상이 정반대다)

과목 융합 관점

• 프론트엔드 / 마이크로서비스 (JWT와 무상태 아키텍처의 혁명): 과거 쿠키(Cookie) 기반 모놀리식 시절에는 CSRF 토큰을 다느라 코드가 지저분했다. 하지만 현대 SPA(React)와 MSA가 만나며 Stateless(무상태) JWT 토큰 시대가 왔다. JWT 토큰을 브라우저의 쿠키(Cookie)가 아니라 로컬 스토리지(Local Storage)나 변수에 담아두고, API 쏠 때마다 Authorization: Bearer <토큰> 헤더로 명시적으로 쏴준다. 브라우저가 자동으로 태워 보내는(Cookie) 기능 자체를 안 쓰니까, 해커의 낚시 사이트에서 폼(Form)을 날려봤자 토큰이 안 따라간다! 즉, 토큰 헤더 방식의 진화가 CSRF라는 공격 자체를 무의미한 석기시대 뼈다귀로 만들며 아키텍처를 영구 구원해 냈다.

• 클린 아키텍처 (GET / POST의 명확한 역할 분리): CSRF 방어의 근간에는 REST API의 설계 철학이 숨어있다. "조회(GET)는 1만 번 찔러도 내 돈이나 DB의 상태가 1도 변하지 않는 안전함(멱등성, Idempotency)을 지녀야 한다." 멍청한 개발자가 <a href="/deleteUser?id=1">삭제</a> 처럼 파괴적 행위(삭제)를 GET 방식으로 짜버리면, 해커가 그냥 게시판에 이미지 태그 <img src="/deleteUser?id=1"> 만 딱 1줄 적어놔도 게시판 읽은 수만 명이 연쇄 탈퇴당하는 지옥이 열린다. 아키텍트는 "파괴적 행위는 무조건 POST/DELETE(명시적 상태 변경)로만 짜라!"고 규약을 박아야 브라우저(SameSite=Lax)가 그 POST 요청을 귀신같이 막아내며 융합 시너지를 낼 수 있다.

• 📢 섹션 요약 비유: XSS는 도둑이 내 눈에 환각(스크립트)을 쏴서 나를 기절시키고 내 지갑을 빼가는 강도질입니다. CSRF는 도둑이 환각은 안 쓰지만 내 손에 투명 실(위조 요청)을 매달아서, 내 손으로 직접 은행 창구에 송금표를 내밀게 만드는 뻔뻔한 사기극입니다. 도둑이 내 지갑을 털든 은행을 털든 털리는 건 똑같으므로, 1+1 세트로 무조건 둘 다 막아내야(토큰 + 이스케이프) 합니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — SOP(동일 출처 정책)를 맹신한 주니어의 대형 참사: 주니어 개발자가 React로 프론트엔드를 짜면서 "브라우저는 SOP(Same-Origin Policy) 덕분에 해커 도메인에서 우리 API 못 찌르니까 안전해! CSRF 방어 필터 다 끌게요!"라며 스프링 시큐리티의 .csrf().disable() 옵션을 켜버렸다. 1주일 뒤 회원 정보가 싹 다 털렸다. 해커는 데이터를 "읽어(Read)" 오려는 게 아니라, 은행 서버에 "돈 보내!(Write/POST)"라는 폼(Form) 편지만 딱 날리고(Fire and Forget) 브라우저를 닫아버린 것이다.

   • 아키텍트의 해결책: SOP의 한계와 CSRF의 본질적 비대칭성 망각이다. 브라우저의 SOP는 "남의 집 데이터를 훔쳐보는 것(Read/Fetch)"은 엄격히 차단(CORS 에러)하지만, HTML 기본 기능인 <form action="POST">을 통해 "남의 집으로 편지 뭉치를 냅다 던지는 행위(Write)"는 100% 쿨하게 허용한다. 해커는 응답값(성공 여부)은 궁금하지 않다. 던진 편지(송금 명령)가 서버에 꽂히기만 하면 끝이다. 아키텍트는 "SOP가 CSRF를 막아준다는 착각은 자살행위다. 폼(Form) 통신을 열어뒀다면 무조건 CSRF 토큰(Spring Security 활성화)을 강제로 발라라"라고 뒤통수를 후려쳐야 한다.

2. 시나리오 — 로드 밸런서 3대 증설 후 CSRF 토큰 터짐 현상 (세션 불일치): 쇼핑몰 장사가 잘돼서 서버(WAS)를 3대로 찢고 L4 스위치를 뒀다. 그런데 고객들이 결제 버튼만 누르면 3번에 2번꼴로 "CSRF 토큰 불일치 (403 Error)"가 뜨며 다 튕겨 나갔다. 원인은 간단했다. 사용자가 로그인(GET)할 때 발급받은 CSRF 토큰은 1번 서버 메모리(Session)에 저장됐는데, 결제 버튼(POST)을 누를 때 L4가 트래픽을 2번 서버로 날려버렸다. 2번 서버는 자기 메모리에 그 토큰이 없으니 얄짤없이 해커 취급하며 쳐낸 것이다.

   • 아키텍트의 해결책: 모놀리식 상태(Stateful) 기반 토큰 아키텍처의 분산 환경 붕괴다. 스케일 아웃(Scale-out) 시대에 서버 로컬 세션에 토큰을 저장하는 건 바보짓이다. 아키텍트는 2가지 처방을 내린다. 1) L4 설정에 **스티키 세션(Sticky Session)**을 걸어 들어온 놈은 죽을 때까지 1번 서버로만 묶어두거나, 2) 근본적으로 로컬 세션을 찢어버리고 외부 **Redis(인메모리 글로벌 저장소)**로 세션 클러스터링(Session Clustering)을 구축하여 3대 서버가 1개의 뇌(토큰 리스트)를 공유하게 아키텍처 뼈대를 완전히 뜯어고쳐야 이 오탐 지옥을 돌파할 수 있다.

도입 체크리스트

• 기술적: Double Submit Cookie (더블 서밋 쿠키) 패턴을 아는가? Redis 세션 클러스터링을 구축할 돈도, 시간도 없는 스타트업에 서버가 5대다. 토큰을 저장(Stateful)할 공간이 없다! 아키텍트는 꼼수(Stateless CSRF 방어)를 쓴다. 서버는 토큰을 만들어서 1개는 쿠키(Set-Cookie)에, 1개는 화면의 폼 숨김 값(<input hidden>)으로 클라이언트에 던진다. 서버 메모리엔 안 남긴다. 결제 요청이 들어오면 서버는 뇌(메모리)를 뒤지지 않고, 방금 패킷으로 날아온 쿠키값과 폼 값이 '서로 쌍둥이처럼 일치하는가?'만 0.01초 만에 비교하고 통과시킨다. 해커는 남의 쿠키는 태워 보낼 수 있어도, 폼의 숨겨진 값은 훔칠 수 없기에(SOP 방어) 완벽하게 속임수가 컷오프(Cut-off)되는 미친 가성비의 아키텍처다.
• 비즈니스적: 현재 개발 환경이 React/Vue 등 100% 클라이언트 렌더링(CSR)인가? 낡은 JSP나 Thymeleaf로 폼 화면을 서버가 빚어 내려주면 CSRF 토큰을 심어주는 게 필수다. 하지만 요즘 유행인 React + JWT 헤더 통신 백엔드 API 서버를 짤 땐 얘기가 다르다. 브라우저가 폼을 자동 발송할 일 자체가 없고, 쿠키(JSESSIONID)를 안 쓰면 CSRF 해킹은 원천적으로 성립조차 하지 않는 귀신(유령)이 된다. 아키텍트는 쓸데없이 최신 API 서버에 무거운 CSRF 필터를 덕지덕지 켜놓아 403 에러 디버깅 지옥을 만들지 말고, httpBasic().disable().csrf().disable() 로 쿨하게 꺼버리는 맥락 인지적 최적화 능력을 보여야 한다.

안티패턴

• "Referer 헤더 검사로 퉁치기" (값싼 꼼수의 파멸): 개발자가 토큰 달기 귀찮으니까 "요청이 날아왔을 때, HTTP 패킷 헤더에 적힌 출발지 주소(Referer: naver.com)가 우리 도메인이 맞는지 if문으로 한 줄 치면 100% 막는 거 아님?" 이라며 안티패턴을 짠다. 해커는 코웃음을 친다. 기업이나 프록시 서버 보안 설정 탓에 개인정보 보호를 이유로 Referer 헤더를 싹 다 지우고 빈칸으로 보내는 정상 사용자(착한 고객)가 수두룩하다. 결국 정상 고객 30%가 403 에러를 맞고 결제를 못 해 회사가 파산하거나, 꼼수 필터링을 조작하는 해커에게 그대로 뒤통수를 맞는다. "보안은 헤더라는 텍스트 쪼가리(조작 가능)에 의존하지 않고, 변조 불가능한 암호학적 토큰이라는 강력한 심장으로 틀어막아야 한다."

• 📢 섹션 요약 비유: Referer 헤더로 검사하는 것은 클럽 입구에서 **'주민등록증 얼굴 사진 대신, 네가 입고 온 옷(헤더) 브랜드로 어른인지 검사하는 꼴'**입니다. 해커(미성년자)가 가짜 어른 명품 옷(조작된 헤더)을 입고 오면 그냥 통과됩니다. 게다가 진짜 어른인데 가난해서 상표 없는 옷(Referer 삭제)을 입고 오면 억울하게 입구컷을 당합니다. 위조가 100% 불가능한 고유의 전자 팔찌(Anti-CSRF 토큰)만을 진실의 척도로 삼아야 합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 브라우저 엔진의 압도적 철권통치 (SameSite=Lax 국룰화): 과거 20년간 개발자들은 해커(CSRF)와 피 터지는 칼싸움(토큰 발급)을 벌였다. 하지만 2020년부터 구글(크롬), 애플(사파리) 같은 전 세계 브라우저 신(God)들이 칼을 빼 들었다. 개발자가 헤더 세팅을 빼먹고 아무것도 안 해도, 브라우저가 스스로 모든 쿠키에 SameSite=Lax 족쇄를 기본값(Default)으로 채워버려, 외부 사이트에서 들어오는 무지성 POST 파괴 요청의 쿠키 탑승을 물리적으로 완벽히 튕겨내 버린다. 개발자의 무능함을 인프라(브라우저 생태계)가 강제로 덮어씌워 구원해 내는 위대한 인프라 보안의 승리 시대로 진입했다.
• 웹의 패러다임 역전 (Cookie-less Architecture): CSRF의 아버지이자 숙주였던 '쿠키(Cookie)' 자체가 서드파티 쿠키 차단(애플 ATT 등 프라이버시 정책) 철퇴를 맞으며 우주에서 쫓겨나고 있다. 넥스트 제너레이션 웹은 브라우저 쿠키를 쳐다보지도 않고, 100% 토큰 베이스(Authorization Bearer Header) 통신이나 FIDO(생체 인증)를 기반으로 한 절대 격리 무상태성 아키텍처로 넘어가고 있어, CSRF라는 해킹 용어 자체가 박물관의 공룡 뼈 화석처럼 영원한 전설 속으로 사라질 준비를 하고 있다.

참고 표준

• OWASP CSRF Prevention Cheat Sheet: "너네 사이트가 토큰을 달아야 하는지 안 달아도 되는지 헷갈린다고? 자, 이 표를 보고 그대로 베껴서 세팅해!"라며 전 세계 백엔드 아키텍트들에게 무지성 평화를 가져다준 OWASP 재단의 절대 방어 정답지.
• Spring Security (CSRF Protection): 자바 스프링 뼈대 위에서, http.csrf() 딱 한 줄 켜두면 해커가 던진 모든 위조 공격을 /error/403 포대자루에 쑤셔 넣고 1초 만에 분쇄해버리는 엔터프라이즈 방어 생태계의 교복 같은 프레임워크 룰.

크로스 사이트 요청 위조(CSRF) 방어의 역사는, 소프트웨어 공학이 '웹이라는 멍청한 인프라(HTTP Cookie)가 빚어낸 거대한 똥(결함)'을 개발자들의 피와 땀(토큰 아키텍처)으로 수십 년간 틀어막아 온 가장 숭고한 보수 공사의 연대기다. 낡은 인터넷은 아무런 악의 없이 모든 집(서버)에 똑같은 택배(쿠키)를 기계적으로 배달해 주는 맹목적이고 무식한 우체부였다. 해커는 이 우체부의 순진함을 악용해 1,000만 고객의 목을 쳤다. 기술사는 우체부(브라우저)를 욕하며 주저앉지 않고, 들어오는 모든 편지봉투(Request)를 의심하여 1회용 암구호(Token)가 찍혀있지 않으면 1초 만에 화염방사기로 편지를 태워버리는 차갑고 완벽한 문지기(Filter)를 내 성문(서버) 앞단에 세워야만 했다. 이제 브라우저라는 거대한 우주가 깨달음을 얻고 자체 면역(SameSite)을 갖춘 축복의 시대가 왔지만, "시스템의 모든 입력(요청)은 철저히 그 출처와 의도를 수학적(토큰)으로 증명해야만 받아들인다(Zero Trust)"는 그 치열했던 아키텍트들의 방어 철학만큼은 인류 서버 보안의 불멸의 뼈대로 영원히 남을 것이다.

• 📢 섹션 요약 비유: CSRF 방어 역사는 **'전화 보이스피싱을 막는 진화의 역사'**와 같습니다. 초창기엔 "은행인데요, 통장 비밀번호 불러주세요(해커의 위조 요청)"에 할머니(서버)가 깜빡 속아서 돈을 다 보냈습니다. 그래서 할머니는 "잠깐! 은행이 보낸 1회용 문자 인증번호(Anti-CSRF 토큰) 먼저 불러봐!"라고 역으로 깐깐하게 암호를 묻는 방어법을 배웠습니다. 그리고 이제 시대가 발전해 통신사(브라우저 인프라) 자체가 "해외 발신 전화(외부 사이트 요청)는 아예 할머니 폰(서버)에서 벨이 울리지 않게 원천 차단(SameSite=Lax)"해버리는 가장 위대하고 평화로운 결말을 향해 달려가고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 내가 '로봇 햄버거 가게(은행 서버)'에 들어가서 회원증(로그인 쿠키)을 목에 걸었어요. 그러면 내 회원증을 보고 내 돈에서 햄버거값을 빼가요.
2. 그런데 나쁜 도둑(해커)이 등 뒤에서 낚싯줄을 던져서 내 손을 억지로 조종해서 "여기 있는 돈 몽땅 도둑한테 송금해 줘!(위조된 나쁜 명령)" 버튼을 누르게 속였어요!
3. 그래서 가게 주인은 내 회원증만 보지 않고, **"잠깐! 내가 아까 너한테만 몰래 귓속말로 알려준 '비밀 암호(CSRF 토큰)'가 뭐야? 대답 못 하면 가짜야!"**라고 깐깐하게 검사해서 도둑의 꼼수를 1초 만에 쳐내는 똑똑한 방어법을 **'CSRF 방어'**라고 한답니다!