HTTP 헤더 - 인증, 쿠키, 캐시

이전 HTTP 헤더 게시글과 이어지는 글입니다.

자주 사용되는 HTTP 헤더 - 인증, 쿠키, 캐시

인증 (Authentication)

RFC 7235에서 HTTP 인증 프레임워크를 정의하며, 기본 인증(Basic Authentication), 다이제스트 인증(Digest Authentication), 토큰 기반 인증(Bearer Authentication), 프록시 인증 등을 다룹니다. 이러한 인증 프레임워크에서 사용되는 인증 헤더는 다음과 같습니다.

1. Authorization 헤더

클라이언트가 서버에 인증 정보를 전달하는 데 사용

인증 스킴 (Basic, Bearer 등)

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Authorization: Bearer <token>

2. WWW-Authenticate 헤더

서버가 클라이언트에게 인증 방식을 요구할 때 사용
401 응답시 WWW-Authenticate 필수

realm 파라미터 필수

WWW-Authenticate: Basic realm="Secure Area"
WWW-Authenticate: Bearer realm="example", error="invalid_token"

3. Proxy-Authenticate 및 Proxy-Authorization 헤더

프록시 서버를 통한 인증을 수행할 때 사용

# 프록시 인증 요청
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="proxy"

# 클라이언트 응답
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

HTTP 인증 프레임워크

1. 기본 인증 (Basic Authentication)

Base64(username:password) 형식
HTTPS 필수 (평문 전송)
realm: 보호 공간 설명

# 클라이언트 요청
GET /private HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

# 서버 응답 (인증 실패 시)
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"

2. 다이제스트 인증 (Digest Authentication)

비밀번호 해시 전송
nonce로 재전송 공격 방지
qop(Quality of Protection) 지원

# 서버 첫 응답
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
    realm="http-auth@example.org",
    qop="auth, auth-int",
    algorithm=SHA-256,
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

# 클라이언트 요청
Authorization: Digest username="Mufasa",
    realm="http-auth@example.org",
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    uri="/dir/index.html",
    qop=auth,
    nc=00000001,
    cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
    response="8ca523f5e9506fed4657c9700eebdbec",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

3. 토큰 기반 인증 (Bearer Authentication)

JWT 같은 토큰 사용
상태 비저장 인증
OAuth 2.0과 함께 사용

# 클라이언트 요청
GET /resource HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# 서버 응답 (인증 실패 시)
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

쿠키 (Cookies)

쿠키는 클라이언트 측에서 상태 정보를 저장하고 HTTP 요청 시마다 서버로 전송하는 작은 데이터 조각입니다. HTTP는 기본적으로 클라이언트와 서버가 서로 상태를 유지하지 않는 무상태(Stateless) 프로토콜입니다. 이러한 문제점을 쿠키를 활용해야 세션을 유지할 수 있습니다. 또한 광고 정보를 트래킹 할 때도 많이 사용됩니다. 쿠키 정보는 항상 서버로 전송되어 네트워크 트래픽을 추가적으로 유발합니다. 따라서 최소한의 정보만 사용하거나, 웹 스토리지로 서버에 전송하지 않고 웹 브라우저 내부에 데이터를 저장할 수 있습니다.

<쿠키 헤더 주요 속성>

Path: 쿠키가 전송될 서버의 경로를 해당 경로를 포함한 하위 경로 페이지로만 제한
Domain: 쿠키가 전송될 도메인을 지정
- 해당 속성을 헤더에 명시할 경우, 명시한 문서 기준 도메인과 서브 도메인을 포함
- 헤더에 명시하지 않을 경우, 현재 문서 기준 도메인만 적용
Expires: 명확한 만료 날짜를 지정
Max-Age: 쿠키의 유효 시간을 초 단위로 지정, Max-Age가 있으면 Expires 무시

1. Set-Cookie 헤더

서버가 클라이언트에게 쿠키를 설정하도록 지시

Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; Domain=example.com; Path=/; Max-Age=3600

2. Cookie 헤더

클라이언트가 서버에 요청을 보낼 때 서버에서 받은 쿠키를 포함하여 서버로 전달

Cookie: sessionId=abc123

쿠키 헤더 주요 속성 및 보안 고려사항

쿠키는 보안 취약점 아래와 같이 속성을 사용해도 공격에 노출될 수 있고, 네트워크 요청마다 자동으로 전송되어 보안에 취약합니다. 따라서 쿠키에는 보안에 민감한 데이터는 저장하면 안 됩니다.

1. Secure

HTTPS에서만 쿠키 전송
중간자 공격(MITM) 방지
MITM(Man-In-The-Middle): 클라이언트와 서버 사이에 공격자가 끼어들어 통신 내용을 도청/변조하는 공격(Wi-Fi 등)

2. HttpOnly

JavaScript에서 쿠키 접근 불가
XSS(Cross-Site Scripting) 공격으로부터 보호
HTTP 전송에만 사용

3. SameSite

CSRF 공격 방어
XSRF 또는 CSRF(Cross-Site Request Forgery): 공격자가 인증된 사용자의 권한을 도용하여 악의적인 요청을 보내는 공격

Set-Cookie: sessionId=abc123; SameSite=Strict         //Strict: 동일 사이트에서만 전송
Set-Cookie: sessionId=abc123; SameSite=Lax            //Lax: GET 요청과 top-level 탐색만 허용
Set-Cookie: sessionId=abc123; SameSite=None; Secure   //None: 크로스 사이트 허용 (Secure 필수)

// 토큰 생성
const token = crypto.randomBytes(32).toString('hex');
res.cookie('XSRF-TOKEN', token, { sameSite: 'strict' });

// 검증
if (req.cookies['XSRF-TOKEN'] !== req.headers['x-xsrf-token']) {
    return res.status(403).send('Invalid CSRF token');
}

캐시 (Caching)

캐시는 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 저장소입니다. 캐시를 사용하게 되면 아래와 같이 서버에서 변경되지 않은 데이터라면 브라우저 캐시에 저장된 데이터를 즉시 로드하여 성능을 향상할 수 있습니다. 이로 인해 동일 요청에 대한 반복 처리 방지하여 서버 부하를 감소할 수 있습니다. 또한 서버 트래픽과 대역폭 사용량이 감소하게 되어 네트워크 비용을 절감할 수 있습니다.

# 캐시 없는 경우
매 요청마다 서버에서 데이터 로딩
GET /image.jpg -> 서버 처리 -> 응답 -> 클라이언트 (1-2초)

#캐시 사용
첫 요청: GET /image.jpg -> 서버 처리 -> 응답 -> 캐시에 저장
두 번째 요청: 캐시에서 즉시 로드 (0.1초 미만)

RFC 7234는 HTTP 캐싱 메커니즘을 설명하며, 클라이언트와 서버 간의 불필요한 데이터 전송을 줄여 성능을 개선하는 데 중점을 둡니다. 다음은 브라우저 캐시에서 사용되는 헤더를 정리했습니다.

1. Cache-Control 헤더

Cache-Control: max-age=3600, must-revalidate

클라이언트와 서버가 캐싱 정책을 제어하는 데 사용됨
주요 디렉티브:
- max-age: 캐시의 유효 시간 (초 단위), 캐시 유효 시간이 만료되면 서버에서 리소스 다시 요청
- 캐시 무효화:
  - no-cache: 데이터는 캐시 가능하지만, 항상 원 서버에서 데이터를 검증하고 사용
  - no-store: 캐시 저장 금지(데이터에 민감한 정보를 포함할 경우)
  - must-revalidate: 만료된 캐시는 원 서버에서 다시 확인해야 함

2. Expires 헤더

리소스의 만료 날짜를 지정하여 캐시 만료 시간을 설정
더 유현한 Cache-Control: max-age 권장 (우선순위가 더 높음)

Expires: Wed, 20 Feb 2025 10:00:00 GMT

3. 검증 헤더

3-1. ETag 및 If-None-Match 헤더

ETag: "abc123" If-None-Match: "abc123"

ETag(Entity Tag)는 특정 리소스의 변경 여부를 확인하는 데 사용
캐시 데이터에 임의 고유 버전 이름 부여 -> 데이터 변경 시, 이름 변경
캐시 제어 로직을 서버에서 완전히 관리
변경되지 않았다면 304 Not Modified 응답을 보냄

3-2. Last-Modified 및 If-Modified-Since 헤더

리소스의 마지막 변경 시간을 기준으로 캐시 유효성을 판단
서버가 클라이언트에 처음 리소스를 전달할 떼, Last-Modified 헤더에 데이터 마지막 수정 시간을 전달

캐시의 유효 시간(max-age)이 만료되면 클라이언트가 캐시의 If-Modified-Since 헤더에 데이터 마지막 수정 시간과 함께 서버로 데이터 요청 -> 만약 서버의 데이터 최종 수정 시간과 같을 경우, 브라우저 캐시에 저장되어 있는 이전 응답 결과 재사용

# 1. 첫 번째 서버 응답
HTTP/1.1 200 OK
Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT
Cache-Control: max-age=3600

# 2. max-age 만료 후 클라이언트 요청
GET /data.json
If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT

# 3. 서버 응답
# 서버 데이터가 변경X
HTTP/1.1 304 Not Modified  <- 304 응답

# 서버 데이터가 변경O
HTTP/1.1 200 OK  <- 200 응답
Last-Modified: Wed, 21 Oct 2024 08:28:00 GMT 
[새로운 데이터]

캐시 종류

1. 브라우저 캐시

사용자의 로컬에 저장
가장 빠른 응답 속도
위에서 다룬 헤더는 브라우저 캐시에서 사용

2. 프록시 캐시

여러 사용자가 공유 (public 캐시)
- 위 이미지에서 엣지 서버는 다양한 사용자가 접근 할 수 있음 -> 엣지 서버에 저장되어 있는 캐시는 public 캐시
위 이미지와 같이 CDN 등에서 사용
- CDN: 사용자의 물리적 위치와 가까운 서버에서 데이터를 제공함으로써 지연(latency)을 최소화하고 속도를 최적화, 전 세계 여러 위치(엣지 서버)에 콘텐츠 저장

<프록시 캐시 헤더>

1) Cache-Control 헤더

Cache-Control: public            // public 캐시에 응답 저장 가능
Cache-Control: private           // 브라우저(private 캐시)에만 응답 저장 (기본값)
Cache-Control: s-maxage=3600     // 프록시 캐시 유효시간

2) Age 헤더

Age: 60  // 프록시 캐시 내 머문 시간(초)

3. 애플리케이션 캐시

서버 측에서 애플리케이션 레벨에서 구현하는 캐시 메커니즘
서버 메모리나 별도의 캐시 서버에 저장
데이터베이스 부하 감소
구현 방식: 메모리 캐시 (Redis), 인메모리 캐시, 분산 캐시 (Memcached)

[출처 및 참고자료]

이미지: https://docs.tosspayments.com/resources/glossary/cdn

강의: 모든 개발자를 위한 HTTP 웹 기본 지식

'CS > 네트워크' 카테고리의 다른 글

CORS(Cross-Origin Resource Sharing) (0)	2025.02.19
HTTP 헤더 - 개요 및 자주 사용되는 헤더 (0)	2025.02.06
HTTP 상태 코드 (1)	2025.02.01
HTTP 메서드 (1)	2025.01.29
HTTP 개요 (0)	2025.01.24

Dev Note

HTTP 헤더 - 인증, 쿠키, 캐시

자주 사용되는 HTTP 헤더 - 인증, 쿠키, 캐시

인증 (Authentication)

1. Authorization 헤더

2. WWW-Authenticate 헤더

3. Proxy-Authenticate 및 Proxy-Authorization 헤더

HTTP 인증 프레임워크

1. 기본 인증 (Basic Authentication)

2. 다이제스트 인증 (Digest Authentication)

3. 토큰 기반 인증 (Bearer Authentication)

쿠키 (Cookies)

1. Set-Cookie 헤더

2. Cookie 헤더

쿠키 헤더 주요 속성 및 보안 고려사항

1. Secure

2. HttpOnly

3. SameSite

캐시 (Caching)

1. Cache-Control 헤더

2. Expires 헤더

3. 검증 헤더

3-1. ETag 및 If-None-Match 헤더

3-2. Last-Modified 및 If-Modified-Since 헤더

캐시 종류

1. 브라우저 캐시

2. 프록시 캐시

3. 애플리케이션 캐시

'CS > 네트워크' 카테고리의 다른 글

티스토리툴바

HTTP 헤더 - 인증, 쿠키, 캐시

자주 사용되는 HTTP 헤더 - 인증, 쿠키, 캐시

인증 (Authentication)

1. Authorization 헤더

2. WWW-Authenticate 헤더

3. Proxy-Authenticate 및 Proxy-Authorization 헤더

HTTP 인증 프레임워크

1. 기본 인증 (Basic Authentication)

2. 다이제스트 인증 (Digest Authentication)

3. 토큰 기반 인증 (Bearer Authentication)

쿠키 (Cookies)

1. Set-Cookie 헤더

2. Cookie 헤더

쿠키 헤더 주요 속성 및 보안 고려사항

1. Secure

2. HttpOnly

3. SameSite

캐시 (Caching)

1. Cache-Control 헤더

2. Expires 헤더

3. 검증 헤더

3-1. ETag 및 If-None-Match 헤더

3-2. Last-Modified 및 If-Modified-Since 헤더

캐시 종류

1. 브라우저 캐시

2. 프록시 캐시

3. 애플리케이션 캐시

'CS > 네트워크' 카테고리의 다른 글

관련글

티스토리툴바