[웹 보안의 기초 정리] Cookie, SameSite, CORS, ACAO

🍪 Cookie는 어디에 저장되고, 어떻게 동작할까?

브라우저는 서버로부터 받은 Cookie를 도메인 + 경로(Path) 기준으로 저장해요.

예를 들어 www.test.com 서버가 /user/profile 주소로 응답하면서 Path=/user/로 설정된 쿠키를 보냈다면
해당 쿠키는 www.test.com/user/로 시작하는 모든 요청에 자동으로 포함됩니다.

브라우저는 Set-Cookie 응답 헤더를 통해 서버가 보낸 쿠키를 Origin 기반 저장소에 보관합니다.

Set-Cookie: token=abc123; Path=/users; HttpOnly; Secure; SameSite=Lax;

항목	설명
Domain	해당 쿠키가 유효한 도메인 (기본: 응답한 도메인)
Path	URL 경로 조건 (기본: 현재 경로 이하)
Secure	HTTPS 환경에서만 쿠키 전송
HttpOnly	JS로 접근 불가 (document.cookie로 못 봄)
SameSite	Cross-Origin 요청 시 전송 여부 결정 (기본 : None)

Cross-Origin 이란?

Cross-Origin(교차 출처)은 웹 브라우저에서 요청을 보낸 웹 페이지 출처(Origin)와 요청을 받는 서버 출처가 서로 다를 때를 말합니다.

여기서 출처(Origin)는 다음 3가지 요소의 조합입니다.

• 프로토콜 (Protocol): http:// 또는 https://
• 도메인 (Domain): www.google.com, www.naver.com 등
• 포트 (Port): 80, 443, 8080 등 (명시되지 않으면 기본 포트 : 80 사용)

이 세 가지 요소 중 어느 하나라도 다르면 두 출처는 다른 것으로 간주되며 이들 간의 통신은 Cross-Origin 요청이 됩니다.

요청 출처	응답 출처	동일/교차 출처	이유
https://a.com	https://a.com/data	동일 출처	프로토콜, 도메인, 포트 모두 같음
https://a.com	https://b.com/api	교차 출처	도메인이 다름
http://a.com	https://a.com	교차 출처	프로토콜이 다름
https://a.com:8080	https://a.com:443	교차 출처	포트가 다름

왜 Cross-Origin이 중요한가?

웹 브라우저에는 Same-Origin Policy (동일 출처 정책)라는 핵심 보안 원칙이 있습니다.
이는 악의적 웹사이트가 사용자의 동의 없이 다른 사이트의 민감한 정보를 가져가거나 조작하지 못하도록 하기 위한 정책입니다.

따라서 기본적으로 브라우저는 다른 출처 간 특정 상호작용을 제한하며 서버가 명시적으로 허용하지 않으면 교차 출처 요청이 차단됩니다.

A 사이트 Cookie가 B 사이트에서 자동으로 전송될까?

기본적으로는 자동 전송되지 않습니다.

동일 출처 정책과 사용자 개인정보 보호를 위해 브라우저는 외부 사이트에서 쿠키를 자동으로 보내는 것을 엄격히 제한합니다.

SameSite 란?

SameSite는 서버가 쿠키에 설정해 쿠키가 교차 출처 요청에 포함될지 결정하는 속성입니다.

값	설명
Strict	완전 차단. 가장 강력한 보안 레벨입니다. 쿠키가 처음 설정된 동일한 사이트(출처)에서 오는 요청에만 쿠키를 전송합니다. 다른 사이트에서 시작된 모든 교차 출처 요청에는 해당 쿠키를 절대 포함하지 않습니다.
Lax	대부분 차단하지만, 일부 예외 허용. 기본적으로 Strict와 유사하게 교차 출처 요청에 쿠키 전송을 제한합니다. 하지만 <form> 태그의 GET 요청이나 <a> 태그(링크 클릭)와 같은 **최상위 탐색(Top-level Navigation)**에는 예외적으로 쿠키 전송을 허용합니다. (예: 다른 웹사이트에서 로그인 페이지 링크를 클릭하여 이동할 때 로그인 세션 유지)
None	모든 요청 허용. SameSite=None으로 설정된 쿠키는 동일 출처 요청뿐만 아니라 모든 교차 출처 요청에도 전송될 수 있도록 허용합니다. 단, 이 속성을 사용하려면 반드시 Secure 속성도 함께 설정하여 HTTPS 환경에서만 쿠키가 전송되도록 해야 합니다. (HTTP 환경에서는 작동하지 않음)

SameSite 설정은 CSRF 공격 방어에 매우 중요한 역할을 하며 대부분 최신 브라우저는 기본값을 Lax로 두어 보안을 강화하고 있습니다.

Access-Control-Allow-Origin(ACAO) 이란?

Access-Control-Allow-Origin은 CORS(Cross-Origin Resource Sharing) 정책의 핵심 응답 헤더입니다.

이는 브라우저가 다른 출처(Cross-Origin)로부터 온 요청의 응답을 클라이언트 웹 페이지(JavaScript 등)에서 접근하도록 허용할지 여부를 서버가 알려주는 역할을 합니다.

쿠키 전송 여부와는 별개로 서버가 이 교차 출처 요청을 허용할지 말지 결정하는 독립적인 보안 메커니즘이라고 이해하시면 됩니다.

브라우저의 ACAO 검사 과정

1. 공격자 운영 사이트 https://evil.com에서 피해자가 접속한 브라우저를 통해 https://a.com/api/delete-data에 요청 전송
2. 서버 https://a.com이 응답에 "Access-Control-Allow-Origin: https://www.a.com" 설정
3. 브라우저는 요청 출처(evil.com)와 ACAO의 도메인이 다름을 감지
4. 브라우저가 응답을 클라이언트 스크립트에서 읽지 못하도록 차단
5. 콘솔에 "CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource." 출력
   

☑️ 하지만 서버는 동작한다!

브라우저가 응답을 차단한다고 해서 서버가 요청을 거부하거나 로직을 수행하지 않는 것은 아닙니다.

서버는 요청을 정상적으로 받아 내부 로직(예: DB 조회, 수정)을 수행하고 응답을 전송합니다.

단지 브라우저가 응답을 JS에서 읽지 못하게 차단하는 것입니다.

비유로 이해하기

• 브라우저 = 공항
• CORS = 출입국 관리소
  • 다른 나라(Origin)에서 온 사람(요청)을 검사
  • 허가하지 않으면 응답은 전달되지만 “너는 응답 내용을 볼 수 없어”라고 차단
• ACAO (Access-Control-Allow-Origin) = 출국 심사대
  • 서버가 “이 응답은 특정 사람(도메인)만 읽을 수 있어!”라고 선언
• SameSite = 탐지견
  • “이 짐(쿠키)을 외국(다른 도메인)으로 가져가도 돼?”를 검사

---

다시 한번 강조하지만 설정들은 응답을 못 받게 만드는 것이지 절대 로직 수행 자체를 막지는 않습니다.

따라서 서버에서는 추가적으로 인증, 인가, CSRF 토큰 검증 등의 보안 로직을 반드시 구현해야 합니다.