Http header

웹 클라이언트와 서버 간의 통신에서 부가적인 정보를 주고받기 위한 핵심 요소
HTTP message의 body를 해석하고 처리하는 데 필요한 지침, 메타데이터, 인증 정보, 캐시 제어 등이 포함됨
HTTP header body의 의미를 설명하고, 요청/응답을 조정하는 정보 집합.

HTTP msaage의 구조

[요청 메시지] Client → Server
[응답 메시지] Server → Client

->

요청/응답 라인 (Request Line / Status Line)
→ HTTP Header (헤더)
→ 빈 줄
→ 본문 (Body, 선택적)

HTTP header의 분류

요청 헤더(Request Headers)

헤더	의미	예시
Host	요청 대상 도메인	Host: www.example.com
User-Agent	클라이언트 정보	User-Agent: Mozilla/5.0 ...
Accept	수용 가능한 MIME 타입	Accept: text/html, application/json
Authorization	인증 정보	Authorization: Basic abc123==
Cookie	클라이언트 저장 정보	Cookie: sessionId=xyz

• Host: 요청을 보낼 호스트를 나타냄. 주로 도메인 네임으로 명시. 포트번호가 포함되어 있을 수 있음
• User-Agent: 요청 메시지 생성에 관여한 클라이언트 프로그램과 관련된 다양한 정보 명시됨
• Referer: 클라이언트가 요청을 보낼 때 머무르던 URL
• Authorization: 클라이언트의 인증 정보

응답 헤더(Response Headers)

헤더	의미	예시
Set-Cookie	클라이언트에 저장할 쿠키 지정	Set-Cookie: id=12345; Path=/
Location	리다이렉트 URL	Location: https://newsite.com
Content-Length	본문 길이 (바이트 단위)	Content-Length: 1024
Cache-Control	캐시 동작 지정	Cache-Control: no-cache

• Server: 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보 ex) Server: Apache/2.4.1 (Unix)
• Allow: 클라이언트에 허용된 HTTP 메서드 목록을 알려 주기 위해 사용됨.
• Retry-After: 자원을 사용할 수 있는 날짜 혹은 시각을 알려줌
• Location: 클라이언트에게 자원의 위치를 알려줌. 리다이렉션 발생 시나 새로운 자원 생성 시 사용
• WWW-Authenticate: 자원에 접근하기 위한 인증 방식을 설명하는 헤더 ex) WWW-Authenticate

공통 헤더(General Headers)

헤더	의미	예시
Connection	연결 유지 여부	Connection: keep-alive
Date	메시지 생성 시간	Date: Wed, 05 Jun 2024 12:00:00 GMT

• Date: 메시지가 생성된 날짜와 시각에 관련된 정보
• Connection: 클라이언트의 요청과 응답 간의 연결 방식을 설정. Connection: keep-alive, Connection: close etc
• Content-Type, Content-Language, Content-Encoding: 메시지 본문의 표현 방식.

HTTP를 기반으로 한 기술

Cash

자주 사용하는 정적 리소스(HTML, 이미지, JS 등)의 사본을 로컬에 저장해 두고, 다음에 같은 요청이 오면 다시 다운로드 하지 않고 로컬에서 불러오는 것

목적

• 속도 향상
• 서버 부하 감소
• 트래픽 절약

저장 위치

• 브라우저 캐시(사용자 디바이스) ->개인 전용 캐시(private cash)
• 프록시 서버 캐시
• CDN 등 중간 서버 -> 공용 캐시(public cash)

동작방식

1.브라우저가 style.css를 서버에 요청
2. 서버가 응답하며 Cache-Control: max-age=86400 포함
3. 브라우저는 이 파일을 24시간 캐시에 저장
4. 다음 요청 시 서버에 가지 않고 로컬 캐시 사용

관련 헤더

헤더	역할	예시
Cache-Control	캐시 정책 지정	no-cache, max-age=3600
ETag	리소스 식별용 버전 태그	"abc123"
Last-Modified	리소스 최종 수정일	Tue, 04 Jun 2024 08:00:00 GMT

cache freshness
사본을 저장하기에, 원본 데이터가 변경될 시의 상황을 대비해야 함
-> 캐시 데이터에 유효기간 설정.

• 캐싱된 데이터의 유효기간이 만료가 되었을 때,
  - 원본에 변화가 없다->유효기간 연장
  • 원본에 변화가 있다->새로운 자원 응답 받아 사용

검사방법
캐시의 유효 기간이 만료되었을 때, 클라이언트는 캐시의 신선도를 재검사한다.

1. 날짜 기반:

• If-Modified-Since 헤더로 서버에 요청을 보냄
• 서버의 응답
  • 변경되었음: 200(OK)와 함께 새로운 자원 반환
  • 유지: 304(Not Modified)
  • 삭제되었음: 404(Not Found)
  • 서버는 Last-Modified 헤더로 특정 자원이 마지막으로 수정된 시점을 알려 줄 수 있다.

2. 엔티티 태그(Etag, Entity tag)

• 자원의 버전을 식별하기 위한 정보(유의미한 변경 사항이 있는지)
• 자원이 변경될 때마다 Etag값이 변경됨.
• 클라이언트는 서버에 If-None-Match 헤더와 함께 Etag 값을 보냄
• 서버의 응답
  • 변경되었음: 200(OK)와 변경된 Etag값 응답
  • 유지: 304(Not Modified)
  • 삭제되었음: 404(Not Found)

Cookie

서버가 사용자의 브라우저에 저장하는 작은 데이터. 이후 같은 사이트에 접근할 때 마다 자동으로 함께 전송됨.

동작 방식

• 서버가 쿠키를 생성해서 클라이언트에 전송
• 클라이언트는 쿠키를 저장함
• 추후 동일한 서버에 보내는 요청에 쿠키를 포함해 전송
• 서버는 이 쿠키를 통해 두 개의 요청이 같은 클라이언트에서 왔는지, 로그인 상태를 유지하고 있는지 등을 알 수 있음

목적

• 세션 유지(로그인 유지)
• 사용자 맞춤 설정(언어, 테마 등)
• 광고/트래킹

저장 위치

• 브라우저 내부(일반적으로 텍스트 파일 형태)

관련 헤더

헤더	설명	예시
Set-Cookie (서버 → 클라이언트)	쿠키 저장 요청	Set-Cookie: id=abc123; Path=/; HttpOnly
Cookie (클라이언트 → 서버)	저장된 쿠키 전송	Cookie: id=abc123

보안

쿠키는 웹에서 사용자 상태를 유지하기 위한 중요 수단이나, 그만큼 보안 취약점에 노출될 가능성도 높다.
특히 인증이나 세션 유지에 사용될 때, 공격자에게 탈취당하면 심각한 문제가 발생할 수 있다.

주요 보안 이슈

1. XSS (Cross-Site Scripting)

• 공격자가 웹 페이지에 악성 스크립트를 삽입해 사용자의 브라우저에서 실행되도록 만드는 공격
• 쿠키에 저장된 로그인 정보(세션 ID 등)를 자바스크립트로 탈취 가능
• 특히 HttpOnly가 설정되지 않은 쿠키는 document.cookie로 접근 가능
  -> 쿠키에 반드시 HttpOnly 플래그 설정(자바스크립트에서 접근 차단)
  -> 웹 페이지에 사용자 입력값 출력 시 반드시 HTML Escape 처리
  -> Content Security Policy(CSP) 설정

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict

2. 세션 하이재킹 (Session Hijacking)

• 공격자가 사용자의 세션 ID 쿠키를 탈취하여 피해자로 가장해 웹 서비스에 접근하는 공격
• HTTPS를 사용하지 않거나(평문으로 쿠키 전송), XSS로 쿠키를 탈취당하거나, 공개 Wi-Fi에서의 스니핑이 주 원인
  -> Secure 플래그로 HTTPS 연결에서만 쿠키 전송
  -> 세션 쿠키 재생성을 주기화하기
  -> IP 주소, User-Agent 등으로 세션 무결성 확인

Set-Cookie: sessionId=abc123; Secure; HttpOnly

3. CSRF (Cross-Site Request Forgery)

• 사용자가 로그인된 상태에서, 공격자가 악성 요청을 유도해 사용자 권한으로 요청을 실행시키는 공격

• 브라우저는 자동으로 쿠키를 전송하므로, 공격자가 만든 요청도 쿠키와 함께 서버에 도달

• 서버는 공격자가 보낸 요청을 진짜 사용자 요청으로 오인할 수 있다
  -> CSRF 토큰 사용: 폼마다 난수 토큰을 포함해 서버에서 검증
  -> SameSite 속성 설정

  속성	설명
  Strict	타 도메인 요청에는 쿠키 전송 금지 (보안 ↑, 불편 ↓)
  Lax	대부분의 일반 GET 요청은 허용
  None	제한 없이 전송 (단, Secure 필요)

Set-Cookie: sessionId=abc123; SameSite=Strict; Secure; HttpOnly