그림으로 배우는 Http&Network Basic 정리 - 6장. HTTP 헤더(6.6~6.8)

6.6. 엔티티 헤더 필드

엔티티 헤더(Entity Header)는 HTTP 요청(Request) 또는 응답(Response)의 본문(Body)에 대한 정보를 제공하는 헤더 필드이다.

즉, 요청이든 응답이든 본문이 포함될 수 있기 때문에, 엔티티 헤더는 두 경우 모두 존재할 수 있습니다.

• 요청(Request) 메시지에 포함될 때 → 클라이언트가 서버에 전송하는 데이터의 속성을 설명
• 응답(Response) 메시지에 포함될 때 → 서버가 클라이언트에게 보내는 데이터의 속성을 설명

 

6.6.1. Allow 

Allow 헤더는 서버가 특정 리소스에 대해 허용하는 HTTP 메서드 목록을 나타내는 헤더입니다.
즉, 클라이언트가 어떤 HTTP 메서드를 사용할 수 있는지 알려줍니다.

405 응답이 발생할 때는 서버가 어떤 메서드를 허용하는지 명확하게 알려주기 위해 Allow 헤더를 보내는 것이 일반적인 방식이다.

//✅ 서버가 GET, POST만 허용하는 경우
HTTP/1.1 200 OK
Allow: GET, POST

//✅ 클라이언트가 DELETE를 요청했으나, 허용되지 않은 경우
DELETE /resource HTTP/1.1
Host: example.com

//서버 응답
HTTP/1.1 405 Method Not Allowed
Allow: GET, POST

 

6.6.2. Content Encoding

Content-Encoding 헤더는 HTTP 메시지 본문(Body)이 어떤 방식으로 인코딩(압축)되었는지를 나타내는 엔티티 헤더이다.
이 헤더를 사용하면 서버가 클라이언트에게 데이터를 압축하여 전송할 수 있다.

Content-Encoding의 일반적인 값

gzip	Gzip 알고리즘으로 압축 (가장 일반적)
deflate	Deflate 알고리즘으로 압축
br	Brotli 알고리즘으로 압축 (최신 브라우저에서 선호)
compress	Unix compress 명령어 방식 (거의 사용되지 않음)
identity	인코딩 없음 (기본값)

 

6.6.3. Content Language

Content-Language 헤더는 HTTP 응답에서 본문(Body)의 언어를 지정하는 엔티티 헤더이다.
즉, 서버가 제공하는 컨텐츠(문서, 페이지, API 응답 등)가 어떤 언어로 작성되었는지를 나타낸다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Language: en, fr

Content-Language와 Accept-Language 차이

Content-Language	콘텐츠가 어떤 언어로 작성되었는지 서버가 클라이언트에게 알림	응답(Response) 헤더,요청헤더
Accept-Language	클라이언트가 원하는 언어를 서버에 요청	요청(Request) 헤더

 

6.6.4. Content-Location

Content-Location 헤더는 응답(Response)에서 본문이 실제로 위치한 URL을 나타내는 엔티티 헤더이다.
즉, 현재 응답이 참조하는 리소스의 "대체 위치"를 나타낸다.

 

 

• Content-Location은 현재 응답 본문이 실제로 위치한 URL을 나타낸다.
• 주로 리소스의 원본 위치를 제공하거나, 콘텐츠 협상(Content Negotiation)에서 사용된다.

6.6.6. Content-md5

Content-MD5는 HTTP 본문(Body)의 무결성을 검증하기 위해 사용되는 엔티티 헤더이다.
즉, 서버가 응답을 보낼 때 본문의 MD5 해시 값을 포함하여, 클라이언트가 데이터를 정상적으로 받았는지 확인할 수 있도록 한다

 

• MD5 해시를 Base64 인코딩한 문자열을 사용한다.
• 16바이트(128비트)의 MD5 해시를 Base64로 변환하면 24자리 문자열이 생성된다.
• 하지만 MD5의 보안 취약점 때문에 현대 웹에서는 거의 사용되지 않으며, 대신 ETag, SHA-256, Checksum 방식이 선호된다

6.6.7. Conten-Range

Content-Range는 HTTP 응답(Response)에서 본문의 일부만 전송할 때 사용되는 엔티티 헤더이다.
즉, 파일의 특정 부분만 전송하는 "범위 요청(Range Request)"을 처리할 때 사용된다.

 

• 클라이언트가 Range 요청을 보낼 경우, 서버는 206 Partial Content 응답과 함께 Content-Range를 포함하여 해당 범위만 반환할 수 있다.
• 대용량 파일 다운로드, 동영상 스트리밍, 파일 업로드 재개 등의 기능에서 많이 사용된다. 🚀

📌 Content-Type 헤더

Content-Type은 HTTP 본문(Body)의 데이터 형식을 나타내는 엔티티 헤더이다.
즉, 서버가 응답(Response)에서 본문의 MIME 타입을 명시하거나, 클라이언트가 요청(Request)에서 전송하는 데이터의 형식을 지정할 때 사용된다.

Content-Type: <MIME 타입>[; charset=<문자 인코딩>]

 

 

• MIME 타입(Multipurpose Internet Mail Extensions type): 데이터의 형식을 지정
• 옵션으로 charset(문자 인코딩) 추가 가능
  • charset=UTF-8을 추가하면 클라이언트가 올바른 문자 인코딩을 사용할 수 있다.

Expires 헤더

Expires는 HTTP 응답(Response)에서 캐싱된 리소스의 만료 날짜와 시간을 지정하는 헤더이다.
즉, 클라이언트(브라우저, 프록시 서버 등)가 특정 리소스를 언제까지 캐싱할 수 있는지를 나타낸다.

Cache-Control: max-age > Expires

✅ Expires vs Cache-Control

현대 웹에서는 Expires보다 Cache-Control: max-age 또는 ETag 기반의 캐싱 방식이 더 많이 사용된다.

Expires	특정 날짜에 만료	절대 시간 (GMT)	HTTP/1.0부터 지원
Cache-Control: max-age	몇 초 후 만료	상대 시간 (초 단위)	HTTP/1.1에서 권장

📌 Last-Modified 헤더

Last-Modified는 HTTP 응답(Response)에서 리소스가 마지막으로 수정된 날짜와 시간을 나타내는 엔티티 헤더이다.
즉, 서버가 특정 리소스를 마지막으로 변경한 시점을 클라이언트에게 제공하여, 캐싱과 조건부 요청(If-Modified-Since)을 최적화하는 역할을 한다.

 

HTTP/2 200 OK
Cache-Control: max-age=86400, public
ETag: "abc123"
Last-Modified: Wed, 28 Feb 2025 12:00:00 GMT

 

---

 

6.7. 쿠키를 위한 헤더 필드

RFC 6265는 IETF(국제 인터넷 표준화 기구)에서 정의한 쿠키(Cookie)의 공식 표준 문서이다.

 

1️⃣ 쿠키의 생성 및 사용

• Set-Cookie : 쿠키를 설정하는 방식
• Cookie : 클라이언트가 서버에 쿠키를 전달하는 방식

2️⃣ 보안 관련 규칙

• Secure: HTTPS 연결에서만 쿠키를 전송하도록 제한
• HttpOnly: JavaScript에서 쿠키 접근을 막아 XSS(크로스 사이트 스크립팅) 공격을 방지

3️⃣ 쿠키 속성

• Domain: 쿠키를 사용할 도메인 지정
• Path: 특정 경로에서만 쿠키를 전송하도록 제한
• Max-Age/Expires: 쿠키의 유효 기간 설정

➡️ 최신 버전으로는 RFC 6265bis 개정안 존재한다. ( SamSIte 속성 개선 )

 

6.7.1.  Set-Cookie 

일반적인 HTTP 헤더는 ","를 이용해서 여러 값을 하나로 합칠 수 있었다.

Cache-Control: no-store
Cache-Control: no-cache

//합쳐서 보낼경우
Cache-Control: no-store, no-cache

하지만, Set -Cookie 헤더의 속성 중 Expires는 날짜를 설정하는데, 날짜 형식에서 ","가 사용된다.

Set-Cookie: sessionId=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Path=/;

 

그렇기에, Set-Cookie 헤더는 1개에 1개의 쿠키만 설정하고 하나로 합치면 안된다.

여러개의 쿠키를 저장해야할 경우 여러개의 Set-Cookie 헤더를 사용할 것을 권장하고 있다.

 

Set-Cookie: <cookie-name>=<cookie-value>; [옵션]

 

• cookie-name: 쿠키의 이름
  → 제어 문자(Control Character), 공백(Space), 탭(Tab)을 제외한 ASCII 문자만 가능
  → 특수 문자(예: , ; " \ 등)는 사용할 수 없음.
• cookie-value: 쿠키에 저장할 값
  → 일반적으로 URL 인코딩된 값이 들어감.

🔹 쿠키 이름의 접두사(Prefix)를 통한 보안 옵션 적용

 

쿠키 이름 앞에 특정한 접두사(__Secure-, __Host-)를 붙이면 추가적인 보안 규칙이 적용된다.

✅ 1. __Secure- (보안 쿠키)

Set-Cookie: __Secure-session=abc123; Secure; Path=/; HttpOnly;

__Secure- → HTTPS에서만 쿠키를 설정할 수 있다. (HTTP에서는 Set-Cookie자체가 차단됨).

 

✅ 2. __Host- (더 강력한 보안 쿠키)

Set-Cookie: __Host-session=xyz789; Secure; Path=/; HttpOnly;

 

• 도메인을 지정하면 안 됨 (Domain 속성을 사용하면 안 됨)
• Path는 반드시 / 로 설정 (서브 디렉터리 제한 불가)
• 서브도메인에서 쿠키가 공유되지 않도록 제한하려면 __Host-를 사용하면 된다.

 

1️⃣ Expires 속성

Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>

 

Expires 속성은 쿠키가 언제 만료될지를 설정하는 속성이다.

설정된 시간 이후에는 브라우저가 해당 쿠키를 자동으로 삭제된다. 절대 시간(UTC 기준 날짜 & 시간)으로 지정된다.

Expires 속성이 없으면 쿠키는 브라우저가 종료될 때까지 유지된다. => 세션쿠키

즉, Expires를 설정하면 "영구 쿠키(Persistent Cookie)", 없으면 "세션 쿠키(Session Cookie)".

Max-Age와 함께 사용하면 최신 브라우저와 구형 브라우저 모두에서 호환성 보장 가능하다. 참고로, Expires와 Max-Age속성이 동시에 설정되면, Max-Age가 우선순위를 가집니다.

 

2️⃣ Path 속성

Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>

 

Path 속성은 쿠키가 어느 URL 경로에서 유효한지를 정하는 속성이다.

Path 속성을 명시하지 않으면 기본적으로 현재 URL의 경로에서만 유효하다.

Path =/; 로 설정하면 사이트 전체에서 쿠키 사용이 가능하다.

Path=/admin; 로 설정하면 하위 경로(/admin/settings, /admin/users)에서만 쿠키가 전송된다.

 

3️⃣ Domain 속성

Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>

 

Domain 속성은 쿠키가 어느 도메인에서 유효한지를 정하는 속성이다.

 이 속성을 설정하면 해당 도메인과 서브도메인(subdomain)에서도 쿠키를 사용할 수 있다

예를 들어서, https://naver.com 으로 속성을 설정하면, 서브도메인인 https://section.blog.naver.com/ 도 사용가능하다.

 

4️⃣ Secure 속성

Secure 속성은 쿠키가 HTTPS에서만 전송되도록 강제하는 속성이다.

Secure가 없으면 HTTP에서도 쿠키가 전송될 수 있어 중간자 공격(MITM)에 취약하다.

속성	Secure 속성	__Secure- 쿠키
역할	HTTPS에서만 쿠키를 전송	HTTPS에서만 쿠키 설정이 가능
HTTP에서 사용 가능 여부	❌ (HTTP에서 쿠키 전송 불가)	❌ (HTTP에서 Set-Cookie 자체가 차단됨)

 

5️⃣ HttpOnly 속성

HttpOnly 속성은 쿠키를 JavaScript에서 접근하지 못하도록 막는 속성이다.

즉, HttpOnly가 설정된 쿠키는 document.cookie를 통해 읽을 수 없고, 오직 서버와의 HTTP 요청을 통해서만 전송된다.

그래서 사진과 보이는것과 같이 HttpOnly를 설정할 경우, console.log(document.cookie) 사용시 출력되지 않는다.

그렇기에 XSS(크로스사이트 스크립팅) 공격을 방지 할 수 있다.

 

 

 

6️⃣ SamSite 속성

SameSite 속성은 쿠키가 크로스 사이트 요청(다른 도메인에서의 요청)에서 전송될지 여부를 결정하는 속성이다.
즉, CSRF(크로스 사이트 요청 위조) 공격을 방지하기 위해 쿠키의 동작을 제한하는 역할을 한다.

 

• SameSite를 설정하지 않으면 브라우저 기본값(Lax)이 적용됨.
• SameSite=None을 사용할 경우 Secure 속성이 필수임.

Strict	가장 강력한 보안, 크로스 사이트 요청에서 쿠키 전송 안 됨	최고 수준의 보안이 필요한 로그인 세션
Lax (기본값)	GET 요청에서는 쿠키 전송됨, CSRF 공격 방어	보안 & UX 균형 (일반적인 로그인 유지)
None	모든 요청에서 쿠키 전송됨 (단, Secure 필수)	크로스 사이트 인증, 광고, 결제 서비스

 

 

6.7.2.  Cookie 헤더

Cookie 헤더는 클라이언트(브라우저)가 서버로 쿠키 데이터를 전송할 때 사용하는 HTTP 요청 헤더이다.

사용자가 방문한 웹사이트에서 설정한 쿠키가 요청과 함께 자동으로 전송된다.

GET /dashboard HTTP/1.1
Host: example.com
Cookie: sessionId=abc123;

 

🔹 Cookie 헤더와 Set-Cookie 차이점

Set-Cookie	서버 → 클라이언트	서버가 클라이언트에 쿠키 저장 요청
Cookie	클라이언트 → 서버	클라이언트가 서버에 저장된 쿠키 전달

 

---

6.8. 그 이외의 헤더 필드

6.8.1. X-Frame-Options 

X-Frame-Options 헤더는 웹사이트가 iframe, object, embed 태그를 통해 다른 사이트에 포함되는 것을 제한하는 HTTP 응답 헤더다. 
이를 통해  클릭재킹(Clickjacking) 공격을 방지할 수 있다.

클릭재킹(Clickjacking)은 사용자가 본인도 모르게 악성 사이트에서 특정 버튼이나 링크를 클릭하도록 유도하는 공격 기법이다.
공격자는 보통 <iframe>을 사용해 사용자가 원치 않는 행동(예: 계정 탈취, 결제, 권한 변경 등)을 하게 만든다

헤더 옵션	보안	설명
DENY	✅ 강력 추천	어떤 경우에도 <iframe> 안에서 페이지 로딩 차단 (가장 강력한 보안)
SAMEORIGIN	✅ 추천	같은 도메인에서만 <iframe> 허용 (자사 서비스 내에서는 허용 가능)
ALLOW-FROM <URL>	❌ 비추천 => CSP 사용 추천	지원하는 브라우저가 거의 없음, 대신 frame-ancestors 사용하여 대체가 가능하다.

 

6.8.2. X-XSS-Protection 

X-XSS-Protection은 브라우저에서 XSS(크로스사이트 스크립팅) 공격을 탐지하고 차단하는 HTTP 응답 헤더다.
과거에는 브라우저가 자동으로 XSS 공격을 탐지하고 차단하는 기능을 제공했지만, 현재 대부분의 최신 브라우저에서는 이 기능이 제거되었거나 Content-Security-Policy (CSP)를 사용하는 것이 권장되고 있다.

헤더 값	설명
0	XSS 보호 기능 끄기
1	XSS 보호 기능 켜기

 

6.8.3. DNT

DNT(Do Not Track) 헤더는 사용자가 웹사이트 및 광고 네트워크에 대해 자신의 온라인 활동 추적을 원하지 않는다는 의사를 전달하는 HTTP 요청 헤더다.

현재는 대부분의 최신 브라우저에서 지원을 중단하고 웹 표준에서도 제외된다.

헤더 값	의미
0	사용자가 추적을 허용함
1	사용자가 추적을 거부함

 

6.8.4. P3P

P3P(Platform for Privacy Preferences)는 웹사이트가 사용자의 개인정보 보호 정책을 XML 형식으로 기술하여 브라우저가 이를 자동으로 해석할 수 있도록 하는 W3C 표준이었다.

 

사용자는 P3P를 통해 자신의 개인정보가 어떻게 사용될지 미리 알 수 있도록 설계되었으나, 이것또한,, 잘 사용하지 않는 기술이라고 한다.