쿠키로 로그인 상태를 유지하는 웹 앱에서 요청 위조와 악성 스크립트 실행을 막으려 합니다. CSRF와 XSS의 공격 경로는 어떻게 다르며 쿠키 옵션만으로 충분한가요?

CSRF와 XSS는 모두 웹 사용자의 권한을 악용할 수 있지만 공격 경로가 다릅니다. CSRF는 공격자 사이트가 사용자의 브라우저로 우리 사이트에 요청을 보내게 하고, 브라우저가 쿠키를 자동으로 첨부하는 성질을 이용합니다. XSS는 신뢰한 우리 페이지의 문맥에서 공격자 제어 스크립트가 실행되는 문제입니다. 따라서 SameSite나 HttpOnly 같은 쿠키 속성 하나로 두 문제를 모두 해결할 수 없습니다.

쿠키 기반 요청과 CSRF를 막습니다

상태를 바꾸는 POST·PUT·DELETE 요청에는 SameSite 정책을 기본 방어로 두고, 별도의 CSRF 토큰 또는 요청의 Origin/Referer 검증을 적용하겠습니다. CSRF 토큰은 공격자 사이트가 예측하거나 읽기 어려우면서 현재 세션과 연결돼야 합니다. 외부 결제나 소셜 로그인 callback처럼 교차 사이트 이동이 필요한 흐름은 SameSite 정책과 충돌할 수 있으므로, 그 경로만 허용 범위를 좁혀 별도로 검증합니다. 상태 변경을 GET에 넣지 않는 것도 중요합니다. 링크 미리보기·크롤러·이미지 로딩이 GET을 호출할 수 있기 때문입니다.

HttpOnly는 자바스크립트가 쿠키 값을 직접 읽지 못하게 하는 속성입니다. 그래서 토큰 탈취 경로 하나를 줄이지만, 이미 XSS가 실행된 페이지의 스크립트가 사용자의 권한으로 fetch나 폼 제출을 수행하는 것을 막지는 못합니다. Secure는 HTTPS가 아닌 전송을 줄이고, SameSite는 일부 교차 사이트 쿠키 전송을 제한하지만 각각의 보장 범위를 넘겨 해석하지 않겠습니다.

XSS는 출력 문맥을 고칩니다

사용자 입력을 HTML·속성·URL·JavaScript 문맥에 그대로 넣지 않고, 문맥에 맞는 출력 인코딩과 textContent 같은 안전한 DOM API를 사용하겠습니다. HTML을 허용해야 한다면 허용 태그·속성·URL scheme을 정한 정화 정책을 적용하고, javascript: URL이나 이벤트 핸들러 속성을 차단해야 합니다. CSP는 inline script와 승인되지 않은 소스의 실행을 제한하는 추가 방어지만, 취약한 렌더링 코드의 대체재가 아닙니다. 저장형·반사형·DOM 기반 XSS를 입력 위치만 보고 단정하지 않고 실제 실행 문맥으로 확인합니다.

인증 수단을 bearer token으로 바꾸면 위험이 사라지는 것이 아니라 위치가 이동합니다. 토큰을 브라우저 저장소에 두면 CSRF는 줄 수 있지만 XSS가 토큰을 읽을 위험이 커질 수 있고, 메모리 보관은 새로고침·갱신 설계가 필요합니다. 테스트에서는 외부 출처에서 상태 변경이 거절되는지, 악성 문자열이 HTML·속성·URL 문맥에서 실행되지 않는지, HttpOnly 쿠키를 읽지 못해도 같은 페이지에서 민감 요청을 만들 수 있는지를 각각 확인하겠습니다.

보안 헤더나 쿠키 설정이 배포된 것만 보지 않고 상태 변경 API의 서버 검증을 직접 시험하겠습니다. CORS도 CSRF 방어가 아닙니다. 브라우저가 응답을 읽지 못하더라도 요청 자체가 도착할 수 있는 경우가 있기 때문입니다.

방어를 적용할 때 보안 헤더만 추가하고 취약한 입력 경로를 방치하지 않겠습니다. 템플릿 엔진의 자동 escaping이 HTML 본문에는 적용돼도 raw HTML, style, URL 속성에 같은 방식으로 적용된다는 보장은 없으므로 출력 sink별 규칙을 확인합니다. 쿠키를 SameSite=Lax로 두더라도 사용자가 이미 악성 스크립트에 노출됐거나 브라우저 정책이 달라지는 경우를 고려해 서버의 CSRF 검증을 유지합니다. 상태 변경을 AJAX로만 제공해도 공격자가 다른 방식으로 form을 제출할 수 있는지 확인하고, CORS 허용 목록을 줄이는 것과 요청 위조 방지는 별도 테스트로 관리하겠습니다.