VIBECODING 365 / DICTIONARY
세션
Session (web)
DEFINITION
웹 앱에서의 세션
HTTP는 요청마다 독립이라 흔히 상태 없는(stateless) 프로토콜로 불린다. 그래서 사이트는 한 클라이언트의 연속 요청을 「세션」으로 묶어 상태를 이어 가야 한다. MDN Session management은 테마 선택 같은 일반 상태뿐 아니라, 인증된 사용자 신원처럼 공격자에게 가치 있는 상태일수록 세션 관리를 신중히 설계해야 한다고 강조한다. (참고: MDN의 「A typical HTTP session」은 TCP 연결·요청·응답 한 사이클을 말하는 별개 주제다.)
중앙집중형: 서버 상태 + 세션 ID
가장 흔한 모델은 중앙집중형이다. 인증이 되면 서버가 세션 상태를 기록하고 세션 ID를 만들어 상태와 연결한 뒤, 그 ID 사본을 클라이언트에 준다. 이후 요청에 클라이언트가 ID를 실으면 서버가 상태로 권한을 판단한다. 세션 ID는 사용자·계정 정보를 담지 말고 서버 쪽 조회 키로만 의미가 있어야 하며, 추측·예측이 어렵도록 충분한 엔트로피를 가져야 한다. MDN은 OWASP 가이드를 인용해 최소 64비트 엔트로피를 권하고, 가능하면 검증된 프레임워크·라이브러리로 ID를 생성하라고 한다.
쿠키에 두는 이유와 CSRF
클라이언트 저장은 localStorage와 쿠키가 대표적이다. MDN은 쿠키를 권장한다. HttpOnly로 JavaScript가 세션 ID를 읽지 못하게 하면 XSS로 ID를 훔쳐 보내는 공격을 줄일 수 있다(다만 악성 스크립트가 브라우저에서 쿠키가 자동 포함되는 요청을 보내는 것까지는 막지 못한다). Secure는 암호화되지 않은 연결로 ID가 나가지 않게 하고, Domain/Path는 보낼 URL을 최대한 좁힌다. 쿠키로 ID를 실으면 CSRF 위험이 생기므로 SameSite만으로 끝내지 말고 CSRF 토큰·fetch metadata 등 추가 방어가 필요하다고 MDN은 적는다. 로그인 시마다 새 세션 ID를 발급하고 기존 값을 무효화하는 것이 세션 고정(session fixation)의 핵심 방어다.
분산형(토큰)과 수명
대안으로 서버가 서명한 세션 상태 객체(흔히 JWT)를 클라이언트에 두는 분산형(탈중앙) 모델이 있다. 여러 서버가 서명만 검증하면 상태를 공유할 수 있지만 구현이 복잡하고, 아키텍처상 필요 없으면 중앙집중형이 낫다고 MDN은 정리한다. 수명은 보안과 사용성의 트레이드오프이며, 실제 만료·무효화는 서버에서 해야 한다. OWASP가 말하는 idle/absolute/renewal timeout 개념을 MDN이 소개하며, 자격 증명 변경·계정 복구·의심 징후 때는 세션을 끊고 재인증을 요구할 수 있다.
ENGLISH
Session (web)
EXAMPLE
로그인 후 서버가 세션 레코드를 만들고 Set-Cookie로 HttpOnly·Secure 세션 ID를 주면, 이후 요청의 Cookie로 ID를 실어 서버가 로그인·권한을 조회한다.
관련
이어서 볼 문서
RELATED TERMS
연관 용어
HTTP cookie
서버가 브라우저에 심고 이후 요청에 다시 실어 보내는 작은 HTTP 데이터. 상태가 없는 HTTP에서 로그인·개인화를 잇고, 전송 범위는 Secure·HttpOnly·SameSite로 정한다.
security 교차 출처 리소스 공유Cross-Origin Resource Sharing (CORS)
다른 출처 페이지의 스크립트가 이 응답을 읽어도 되는지, 서버가 HTTP 헤더로 브라우저에 알리는 방식이다. 요청이 가는 것과 스크립트가 읽는 것은 다르며, 쿠키를 실을 때는 별표 출처가 허용되지 않는다.
백엔드·인프라 미들웨어Middleware
미들웨어는 실제 API 처리 함수 앞뒤에서 요청과 응답을 가로채 공통 작업을 수행하는 중간 계층이다. 로그인 확인, 입력값 검증, 로깅, CORS, rate limit, 오류 변환처럼 여러 엔드포인트에 반복되는 서버 로직을 한곳에 모을 때 사용한다. 바이브 코딩에서는 AI가 모든 라우트에 인증 코드를 복사해 붙이는 대신 미들웨어로 공통 규칙을 분리하도록 지시하면 중복과 보안 누락을 줄일 수 있다. 다만 실행 순서가 중요하므로 공개 라우트와 보호 라우트의 범위를 테스트로 확인해야 한다.