browser boundary

CORS, CSRF, XSS는 같은 보안 설정이 아니다

요청이 브라우저에서 시작해 Nest API에 닿기 전까지 어느 경계에서 차단되는지 분리하면, 허용 출처와 쿠키 정책, 출력 인코딩, CSP를 서로 다른 점검 항목으로 다룰 수 있습니다.

1 브라우저

요청 생성

폼 제출, fetch, 이미지 로드처럼 시작 방식에 따라 쿠키 첨부와 preflight 여부가 달라집니다.

2 CORS

출처 허용 검사

Origin이 allowlist 밖이면 브라우저가 응답을 읽지 못하게 막고, 서버 로그에는 요청 자체가 보일 수 있습니다.

3 CSRF

의도 확인

쿠키 인증 요청은 토큰, SameSite, 재인증 같은 신호가 없으면 사용자의 실제 의도와 구분하기 어렵습니다.

4 XSS

출력 경계

사용자 입력은 저장 전 검증보다 렌더링 시점의 이스케이프와 CSP 위반 보고서에서 더 직접적으로 드러납니다.

5 Nest API

Guard와 Pipe

인증, 권한, DTO 검증은 브라우저 방어를 통과한 뒤에도 서버 계약을 마지막으로 고정합니다.

공격면별 Nest 적용 지점

CORS

main bootstrap

app.enableCors에서 origin 함수를 두고, credential 허용은 공개 API와 분리합니다.

CSRF

세션 쓰기 요청

쿠키 기반 POST, PATCH, DELETE는 토큰 검증과 SameSite 정책을 같이 기록합니다.

XSS

응답 렌더링

helmet CSP, 템플릿 이스케이프, JSON 응답의 content type을 한 묶음으로 점검합니다.

차단 신호를 어디서 볼지

DevTools CORS는 콘솔 오류와 preflight 응답 헤더 차이로 먼저 확인합니다.
서버 로그 CSRF 실패는 토큰 누락, 세션 불일치, 쓰기 메서드를 함께 남깁니다.
CSP report XSS 의심은 차단된 스크립트 출처와 위반 지시어를 보며 좁힙니다.