회사 홈페이지 관리자 로그인 쿠키에는 어떤 속성을 붙여야 할까요?

회사 홈페이지 관리자 로그인 쿠키는 Secure·HttpOnly·SameSite 속성과 Domain·Path 범위를 함께 정해야 전송 경로, 스크립트 접근, 다른 사이트에서 오는 요청을 각각 좁힐 수 있습니다. 표준 문서가 설명하는 속성별 역할과 한계, 점검 순서를 정리했습니다.

탱탱소프트2026.11.07

회사 홈페이지 관리자 로그인 쿠키는 Secure·HttpOnly·SameSite 속성과 Domain·Path 범위를 함께 정해야 전송 경로, 스크립트 접근, 다른 사이트에서 오는 요청을 각각 좁힐 수 있습니다. 속성 하나가 모든 위험을 막지는 않기 때문에 각 속성이 무엇을 막고 무엇을 막지 못하는지 알고 조합하는 것이 중요합니다.

로그인 쿠키에는 세션 식별자만 담습니다

쿠키 표준인 IETF RFC 6265의 보안 고려 사항은 세션 정보를 쿠키에 직접 담으면 노출되거나 재사용될 수 있으므로, 서버가 쿠키에는 세션 식별자만 넣고 실제 상태는 서버 쪽에서 찾는 방식을 흔히 쓴다고 설명합니다. 공격자가 쿠키 내용을 알게 되더라도 피해 범위를 줄일 수 있기 때문입니다. 관리자 권한, 이름, 이메일 같은 정보는 쿠키 값에 넣지 않고 서버 세션에 둡니다.

Secure와 HttpOnly가 막는 것과 막지 못하는 것

RFC 6265에 따르면 Secure 속성이 붙은 쿠키는 보안 채널, 보통 TLS 위의 HTTP 요청에만 실립니다. 같은 문서는 Secure가 쿠키의 기밀성만 지킨다고 밝힙니다. 능동적인 네트워크 공격자가 보안되지 않은 채널에서 Secure 쿠키를 덮어쓸 수 있어 무결성까지 보장하지는 않는다는 뜻입니다. MDN의 Set-Cookie 문서는 http: 주소의 사이트가 Secure 쿠키를 설정할 수 없다는 점도 적고 있습니다.

HttpOnly 속성은 브라우저가 스크립트에 쿠키를 보여 주는 HTTP 이외의 통로에서 그 쿠키를 빼도록 합니다. MDN은 HttpOnly가 document.cookie 같은 자바스크립트 접근을 막아 교차 사이트 스크립팅(XSS) 공격을 완화하지만, 자바스크립트가 보내는 fetch 요청에는 여전히 쿠키가 실린다고 설명합니다. 쿠키를 읽지 못하게 할 뿐 화면 안의 악성 스크립트가 요청을 보내는 것까지 막지는 못하므로, 입력값 처리와 콘텐츠 보안 정책 같은 다른 방어와 함께 써야 합니다. RFC 6265는 두 속성이 서로 독립적이어서 한 쿠키에 함께 붙일 수 있다고 적습니다.

흰 책상 위에 열린 노트북 화면에 푸른 빛 입자가 퍼져 있고 뒤쪽 사무 공간은 흐리게 보이는 모습

AI로 생성한 개념 이미지. 실제 탱탱소프트 사진이 아닙니다.

SameSite와 범위 속성은 보내는 곳을 좁힙니다

MDN에 따르면 SameSite는 다른 사이트에서 시작된 요청에 쿠키를 실을지 정하며, 교차 사이트 요청 위조(CSRF) 같은 일부 공격에 대한 보호를 제공합니다. 값은 세 가지입니다.

Strict: 쿠키를 설정한 같은 사이트에서 시작된 요청에만 보냅니다.
Lax: 같은 사이트 요청에 더해, 주소창이 바뀌는 최상위 이동이면서 POST·PUT·DELETE가 아닌 안전한 메서드인 다른 사이트 요청에도 보냅니다.
None: 모든 요청에 보내며 Secure를 함께 붙여야 합니다.

MDN은 SameSite를 적지 않았을 때 일부 브라우저가 Lax를 기본값으로 쓴다고 설명합니다. 브라우저마다 다를 수 있으므로 관리자 쿠키에는 값을 직접 적는 편이 안전합니다.

범위도 함께 봅니다. MDN에 따르면 Domain을 생략하면 쿠키를 보낸 호스트에만 돌아가는 호스트 전용 쿠키가 되고, Domain을 지정하면 그 도메인과 모든 하위 도메인으로 쿠키가 전달됩니다. Path는 사이트의 경로별로 쿠키 전송을 나누는 기능일 뿐 보안 수단이 아니라고 MDN은 밝힙니다. 이름이 __Host-로 시작하는 쿠키는 HTTPS 페이지에서 Secure와 함께 설정되어야 하고 Domain 없이 Path가 /여야 하므로, 설정한 호스트에만 전송됩니다.

양쪽으로 서버 랙이 줄지어 서 있고 푸른 표시등이 빛나는 사람 없는 밝은 데이터센터 통로