CSRF를 "토큰 한 줄 깔면 된다"로 외운 사람과, 시나리오를 분해해서 어떤 동작이 위험하고 어떤 방어 계층을 어떻게 조합할지 답하는 사람을 가른다. 후속은 보통 SameSite 옵션 차이·SPA/모바일 환경에서의 방어·OAuth/SSO 콜백 동선으로 이어진다.
CSRF(Cross-Site Request Forgery)는 사용자가 어떤 사이트에 로그인된 상태에서 다른 사이트가 그 사이트로 요청을 보내게 만들어, 브라우저가 자동으로 쿠키·인증 정보를 실어 보내는 점을 악용하는 공격이다. 핵심은 "요청을 누가 보냈는가"가 아니라 "브라우저가 인증 정보를 자동으로 끌고 가는가"에 있다. 그래서 방어도 한 가지 도구가 아니라 계층 조합이다 — 서버가 발급해 폼·요청에 끼우는 CSRF 토큰을 매 변경 요청에서 검증하고, 세션 쿠키를 SameSite Lax/Strict로 두어 크로스 사이트 자동 전송 자체를 줄이며, 위험 동작에는 재인증·OTP 같은 추가 확인을 끼운다. "하나만 깔면 끝"이 아니라 "여러 계층으로 위험을 깎는다"는 접근이 본질이다.
CSRF 필터·토큰 검증을 도입하면서 어떤 엔드포인트를 보호하고 어디는 풀어줬는지 결정해 본 경험이 있다면 "위험 동작 식별" 단계의 사례로 풀 수 있다
쿠키를 SameSite=Lax 또는 Strict로 옮기면서 외부 콜백·OAuth 동선이 깨졌다 다시 살린 경험이 있다면 SameSite 트레이드오프를 본인 사례로 말할 수 있다
SPA에서 헤더 기반 토큰 인증으로 옮기면서 기존 CSRF 토큰을 어떻게 정리했는지 떠올릴 수 있다면 "인증 모델에 따라 방어가 다르다"는 시각으로 연결할 수 있다
보안 점검·모의 해킹 보고서에서 CSRF 항목을 받아 본 경험이 있다면 보고서가 어떤 방어 계층의 부재를 지적했는지로 답을 한 단계 깊게 만들 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.