KO

EN

How to Secure Cookies

쿠키(Cookies)는 웹 애플리케이션에서 중요한 역할을 하지만, 동시에 보안 설정에 신중을 기해야 하는 대상입니다. 이 글에서는 쿠키를 보다 안전하게 관리하기 위해 각 속성들을 깊이 있게 살펴보고자 합니다. 특히 SameSite 속성을 비롯해 HttpOnly, Secure, Path, Domain, Expires, Max-Age 속성들이 각각 어떻게 쿠키 보안에 기여하는지 자세히 알아보겠습니다.

쿠키에는 사용자를 식별할 수 있는 세션 ID와 같은 민감한 정보가 담길 수 있습니다. 만약 이러한 쿠키가 공격자에게 탈취된다면, 세션 하이재킹(Session Hijacking)을 통해 사용자의 계정이 무단으로 사용될 위험이 있습니다. 또한, CSRF(Cross-Site Request Forgery) 공격에 악용되어 사용자가 의도하지 않은 동작을 웹사이트에서 수행하게 될 수도 있습니다. 따라서 쿠키 속성 하나하나를 잘 이해하고 올바르게 설정하는 것이 매우 중요합니다.

쿠키를 견고하게 만들어 줄 핵심 보안 속성들을 하나씩 자세히 살펴보겠습니다.

1. HttpOnly: Protecting Against XSS

HttpOnly 속성이 설정된 쿠키는 JavaScript의 document.cookie API를 통한 접근이 차단됩니다. 이는 웹사이트에 XSS(Cross-Site Scripting) 취약점이 존재할 경우, 공격자가 삽입한 악성 스크립트가 사용자의 쿠키 값(특히 세션 ID)을 직접 읽어내어 탈취하는 것을 방지하는 데 효과적입니다.

설정 예시 (HTTP 헤더):

Set-Cookie: session_id=verysecretvalue; HttpOnly

사용자 인증과 관련된 민감한 쿠키에는 HttpOnly를 설정하는 것이 바람직합니다. 기본적인 방어 수단이지만 그 효과는 분명합니다.

2. Secure: Ensuring Encrypted Transmission

Secure 속성이 지정된 쿠키는 오직 HTTPS 프로토콜을 통해서만 서버로 전송됩니다. 암호화되지 않은 HTTP 연결로는 해당 쿠키가 전송되지 않으므로, 네트워크 중간에서 공격자가 쿠키를 가로채는 중간자 공격(MITM, Man-in-the-Middle Attack)으로부터 쿠키를 보호할 수 있습니다.

설정 예시 (HTTP 헤더):

Set-Cookie: user_preference=dark_mode; Secure

대부분의 현대 웹사이트가 HTTPS를 기본으로 사용하는 만큼, Secure 속성 역시 적극적으로 적용하는 것이 좋습니다. 특히 SameSite=None 정책을 사용할 경우 Secure 속성은 필수적으로 함께 설정되어야 합니다.

3. SameSite: The CSRF Shield (In-Depth)

SameSite 속성은 CSRF(Cross-Site Request Forgery) 공격을 방어하는 데 핵심적인 역할을 수행합니다. 이 속성은 쿠키가 다른 출처(cross-site)에서 시작된 요청과 함께 전송될지 여부를 브라우저가 결정하도록 지시합니다. 즉, 특정 웹사이트(siteA.com)의 쿠키가 관련 없는 다른 웹사이트(evil.com)에서 siteA.com으로 보내는 요청에 포함될지를 제어하는 것입니다.

SameSite 속성은 다음 세 가지 값 중 하나를 가집니다:

  • Strict: 가장 강력한 보호 수준을 제공합니다. SameSite=Strict로 설정된 쿠키는 요청이 현재 사용자가 머무르고 있는 동일한 사이트(same-site, 즉 first-party context) 내에서 시작된 경우에만 전송됩니다. 예를 들어, 외부 사이트의 링크를 통해 접속하는 경우에는 Strict로 설정된 쿠키가 전송되지 않아, 로그인 세션 쿠키가 이같이 설정되어 있다면 사용자는 재로그인해야 할 수 있습니다.

    • 사용 시점: 상태 변경을 유발하는 작업(예: 비밀번호 변경, 글쓰기, 주문 처리)과 관련된 쿠키에 적합합니다.
    • 설정 예시: Set-Cookie: session_id=verysecretvalue; SameSite=Strict

  • Lax: Strict보다는 다소 완화된 설정이지만 여전히 우수한 보안을 제공합니다. Lax는 기본적으로 대부분의 cross-site 요청에는 쿠키를 전송하지 않습니다. 그러나 사용자가 URL을 직접 입력하거나 링크를 클릭하는 등의 최상위 탐색(top-level navigation)이면서 안전한 HTTP 메서드(GET, HEAD, OPTIONS, TRACE)를 사용하는 경우에는 cross-site 요청이라도 쿠키를 전송합니다. 이를 통해 외부 사이트에서 링크를 통해 접속 시 로그인 상태를 유지하는 등 사용자 경험을 해치지 않으면서 CSRF 공격을 방어할 수 있습니다. 다수의 최신 브라우저는 SameSite 속성이 명시되지 않은 쿠키의 기본값으로 Lax를 채택하고 있습니다.

    • 사용 시점: 일반적인 세션 관리 쿠키에 매우 적합하며, 보안과 사용자 편의성 사이의 좋은 균형점을 제공합니다.
    • 설정 예시: Set-Cookie: tracking_id=randomstring; SameSite=Lax

  • None: 이 설정을 적용하면 쿠키는 모든 요청(same-site 및 cross-site)에 대해 제한 없이 전송됩니다. SameSite 속성이 도입되기 이전의 기본 동작 방식과 가장 유사합니다. 중요한 점은 SameSite=None을 사용하려면 반드시 Secure 속성을 함께 지정해야 한다는 것입니다 (SameSite=None; Secure). 이는 HTTPS 연결에서만 작동하도록 강제하여 보안 위험을 완화하기 위한 조치입니다.

    • 사용 시점: 서비스가 외부 서비스의 iframe 내에 임베드되어 쿠키를 통한 인증이 필요하거나, 여러 도메인에 걸쳐 사용자를 식별해야 하는 SSO(Single Sign-On) 시나리오, 또는 광고나 분석 스크립트처럼 cross-site 컨텍스트에서 쿠키가 명확히 필요한 경우에 한정적으로 사용됩니다.
    • 주의사항: 보안적으로 가장 유연한 만큼 위험도 따르므로, 반드시 필요한 경우에만 신중하게 사용하고 Secure 속성을 절대 누락해서는 안 됩니다.
    • 설정 예시: Set-Cookie: third_party_widget_session=externalvalue; SameSite=None; Secure

어떤 SameSite 값을 선택해야 할까요? 특별한 이유가 없다면 SameSite=Lax를 기본으로 사용하는 것이 좋습니다. 매우 민감한 작업을 처리하는 쿠키라면 SameSite=Strict를 고려할 수 있습니다. Cross-site 요청에서 반드시 쿠키가 필요한 상황이라면, 그때 SameSite=None; Secure를 사용하는 것이 안전한 접근 방식입니다.

Path 속성은 쿠키가 전송될 서버의 URL 경로를 제한합니다. 예를 들어 Path=/admin으로 설정된 쿠키는 /admin 경로 및 그 하위 경로(예: /admin/users)로 요청을 보낼 때만 전송되며, /dashboard나 / (루트) 같은 다른 경로로는 전송되지 않습니다.

설정 예시 (HTTP 헤더):

Set-Cookie: admin_session_token=secretadminstuff; Path=/admin; HttpOnly; Secure

이를 통해 쿠키가 불필요하게 다른 애플리케이션 컨텍스트로 전송되는 것을 막아 쿠키의 노출 범위를 최소화할 수 있습니다. 명시되지 않은 경우, 기본값은 쿠키를 설정한 문서의 경로입니다.

Domain 속성은 쿠키가 전송될 호스트(서버)를 지정합니다. Domain=example.com으로 설정하면, 쿠키는 example.com 및 그 모든 서브도메인(예: www.example.com, api.example.com)으로 요청 시 전송됩니다. Domain 속성을 생략하면 쿠키를 설정한 호스트(서브도메인 제외)에만 쿠키가 전송됩니다.

설정 예시 (HTTP 헤더):

Set-Cookie: site_wide_preference=blue_theme; Domain=example.com

지나치게 광범위한 Domain 설정(예: .com과 같은 최상위 도메인)은 보안상 위험하여 브라우저에서 거부됩니다. 또한, Domain 속성은 현재 호스트의 상위 도메인으로만 지정할 수 있으며, 완전히 다른 도메인으로 설정할 수는 없습니다.

쿠키의 유효 기간을 설정하여 영구적으로 저장되지 않도록 관리하는 것이 중요합니다. 만료 시간 설정에는 Expires와 Max-Age 두 가지 속성이 사용됩니다.

  • Expires: 쿠키가 만료되는 정확한 날짜와 시간(UTC)을 명시합니다. 설정 예시: Set-Cookie: legacy_cookie=data; Expires=Fri, 31 Dec 2025 23:59:59 GMT

  • Max-Age: 쿠키가 만료될 때까지의 시간을 초 단위로 지정합니다. 예를 들어 Max-Age=3600은 쿠키가 1시간 동안 유효함을 의미합니다. Max-Age가 Expires보다 우선적으로 적용됩니다. Max-Age가 0 또는 음수 값이면 쿠키는 즉시 삭제됩니다. 설정 예시: Set-Cookie: short_lived_token=tempdata; Max-Age=3600

Expires와 Max-Age가 모두 설정되지 않으면 해당 쿠키는 세션 쿠키(session cookie) 로 간주되어 브라우저가 닫힐 때 삭제됩니다. 그러나 브라우저 설정에 따라 세션이 복원될 경우 세션 쿠키가 유지될 수도 있으므로, 민감한 정보는 명시적으로 짧은 만료 시간을 설정하는 것이 더 안전한 방법입니다.

Conclusion: Layered Security is Key

쿠키 보안을 위한 다양한 속성들(HttpOnly, Secure, SameSite, Path, Domain, Expires/Max-Age)에 대해 자세히 알아보았습니다. 각 속성의 동작 방식과 보안상 이점을 정확히 이해하는 것이 중요합니다.

이러한 속성들을 적절히 조합하여 사용하는 것이 쿠키 보안의 핵심입니다. 단일 설정만으로는 모든 위협을 방어하기 어려우므로, 항상 여러 계층의 방어(defense in depth)를 고려하여 웹 애플리케이션과 사용자를 안전하게 보호해야 합니다.