flawopen.com/CSRF/GET 요청
GET 요청에 CSRF 토큰이 필요한가요?
GET이 데이터 조회만 한다면 서버 상태를 바꾸지 않아야 하며 일반적으로 CSRF 토큰도 필요하지 않습니다. 브라우저, 크롤러, 미리보기, 임베드 리소스는 의도적인 클릭 없이 GET을 보낼 수 있습니다. 삭제나 구매 같은 작업에는 비안전 메서드를 사용하고 쿠키 인증 상태 변경을 CSRF로부터 보호하세요. 상태를 바꾸는 레거시 GET은 여전히 취약하므로 마이그레이션 전 임시 방어가 필요합니다.
GET을 안전한 메서드로 유지해야 하는 이유
RFC 9110은 GET을 안전하다고 정의합니다. 클라이언트는 상태 변경을 요청하지 않습니다. 안전하다는 말은 로깅 같은 부수 효과까지 없다는 뜻은 아닙니다. GET은 멱등하기도 하지만 별개의 속성입니다. 브라우저, 프리페치, 크롤러, 링크 미리보기는 사용자가 의도적으로 조작하지 않아도 안전한 요청을 보낼 수 있습니다. 다른 사이트의 <img src="...">도 사용자 쿠키가 포함된 GET을 유발할 수 있습니다. 엔드포인트가 항목을 삭제하거나 계정 설정을 바꾸면 GET 의미론을 위반하며 일반 페이지 콘텐츠가 이를 실행할 수 있습니다.
상태 변경 요청에 CSRF 방어를 적용하세요
- ✓GET, HEAD, OPTIONS에서 요청된 상태 변경을 수행하지 말고 변경 작업에는 POST, PUT, PATCH 또는 DELETE를 사용하세요
- ✓쿠키 인증 비안전 메서드를 프레임워크 CSRF 방어 또는 검증된 토큰으로 보호하고 SameSite와 Origin/Fetch Metadata 검사를 추가 방어로 사용하세요
- ✓상태 변경 GET은 HTTP 메서드 의미론의 결함으로 취급하세요. 임시 CSRF 방어를 추가하고 작업을 이전한 뒤 URL에서 비밀 정보를 제거하세요
GET CSRF 관련 FAQ
취약한 것으로 간주하세요. 임시로 서버 검증 CSRF 방어(예: Synchronizer Token과 지원되는 경우 Origin 또는 Fetch Metadata 검사)를 요구하고 캐시와 Referer를 감사한 뒤 POST, PUT, PATCH 또는 DELETE로 이전하세요. 토큰을 쿼리 문자열에 넣지 마세요. URL은 브라우저 기록, 로그, Referer 데이터에 남을 수 있습니다. 토큰 검사는 엔드포인트가 안전한 메서드 의미론을 따를 때까지의 임시 조치입니다.