HTTP 헤더, CORS 에러 관련 간단하게 정리

1. 개요

 이번에 CORS 에러를 오랜만에 보았다. 그래서 이를 해결하기 위해 HTTP 헤더 부분을 보았는데 Header Field 부분이 너무 헷갈렸다. 그래서 구글링을 통해 HTTP 헤더, CORS 에러에 대해 다시 복습한 후, 핵심 내용이라 생각되는 것들만 정리하였다. 자세한 내용들은 구글링을 통해서 쉽게 확인할 수 있기도 하고, 간단하게 정리한 내용들을 틈틈이 보면서 기억을 되살리기 위해서 간단하게 정리하였다.

 

2. HTTP 헤더란

 HTTP 헤더란 클라이언트 서버가 HTTP 요청 및 응답에서 추가적인 정보를 주고 받기 위해 사용하는 메타데이터이다. 각 헤더는 이름과 값의 쌍으로 구성되며 요청이나 응답의 본문(body)과는 별도로 전송된다. 그리고 헤더는 용도에 따라 다음과 같이 분류된다.

• General Header: 요청과 응답 모두에 적용되며, 메시지 본문과는 관련이 없는 일반적인 정보를 포함한다.
• Request Header: 클라이언트가 서버에 요청을 보낼 때 요청에 대한 추가 정보를 제공한다.
• Response Header: 서버가 클라이언트에 응답을 보낼 때 응답에 대한 추가 정보를 제공한다.
• Entity Header: 요청이나 응답의 본문에 대한 정보를 제공한다.

여담으로 General Header와 Entity Header는 개발자 도구의 네트워크 탭에서는 표시되지 않는데, 이는 개발자 도구는 사용 편의를 위해 의미별 구분 없이 보여주기 때문라고 한다. 그리고 실제로도 요청/응답으로만 나눠서 봐도 충분하다고 한다.

 

3. Request Headers

 Request Headers는 클라이언트가 서버에 요청을 보낼 때 요청에 대한 추가 정보를 제공하는 헤더이다. 이러한 헤더는 서버가 요청을 이해하고 적절한 응답을 제공하는 데에 도움을 준다.

 

3-1. 중요한 Request Headers의 Header Fields

헤더 이름	설명	주요 사용처
Host	요청 대상 서버의 도메인을 명시	가상 호스팅 시 필수
Origin	요청의 출처(origin)를 명시	CORS 정책 판단 기준
Referer	이전 페이지의 URL을 명시	분석, 인증, 보안용
User-Agent	브라우저/클라이언트 정보	브라우저 감지, 통계
Accept	클라이언트가 수락 가능한 콘텐츠 타입	JSON, HTML 등 컨텐츠 negotiation
Authorization	인증 토큰 (ex. Bearer 토큰)	API 인증 시 필수
Content-Type	요청 본문의 데이터 타입	POST, PUT 요청 시 필수 (e.g. application/json)

 

 

4. Response Headers

 Response Headers는 서버가 클라이언트에 응답을 보낼 때 응답에 대한 추가 정보를 제공하는 헤더이다. 이러한 헤더는 클라이언트가 응답을 처리하는데 필요한 정보를 포함한다.

 

4-1. 중요한 Response Headers의 Header Fields

헤더 이름	설명	주요 사용처
Content-Type	응답 데이터의 MIME 타입 명시	브라우저가 어떻게 렌더링할지 결정
Content-Length	응답 본문의 바이트 수	스트리밍/다운로드 처리
Set-Cookie	클라이언트에 쿠키 설정	로그인 세션 유지 등
Location	리디렉션 주소	301, 302 응답 시 필수
Access-Control-Allow-Origin	CORS 허용 origin	* 또는 특정 origin 명시
Access-Control-Allow-Methods	허용할 메서드 (GET, POST 등)	preflight 응답에서 필수
Access-Control-Allow-Headers	허용할 헤더 목록	CORS Preflight 요청 응답 시 필수

 

5. CORS 에러

 CORS(Cross-Origin Resource Sharing)는 웹 브라우저의 보안 정책인 Same-Origin Policy를 우회하여, 다른 출처의 리소스에 접근할 수 있게 허용하는 메커니즘이다. 브라우저는 보안을 위해 기본적으로 다른 출처의 리소스에 대한 요청을 제한하며, CORS를 통해 이러한 제한을 완화할 수 있다.

 CORS 에러는 서버가 적절한 CORS 헤더를 포함하지 않건, 클라이언트의 요청이 서버의 CORS 정책에 위배될 때 발생한다. 예를 들어, 서버가 Access-Control-Allow-Origin 헤더를 포함하지 않으면, 브라우저는 보안을 위해 응답을 차단하고 CORS 에러를 발생시킨다. 이를 해결하려면 대략 다음과 같은 해결 방법이 있다.

 

5-1. 해결법

 서버 측에서 적절한 CORS 헤더를 설정해야 한다. 예를 들어, 모든 출처에서의 접근을 허용하려면 다음과 같은 헤더를 응답에 포함시킬 수 있다.

Access-Control-Allow-Origin: *

하지만 보안을 위해 필요한 경우 특정 출처만을 허용하도록 하는 것이 좋다. 

 

추가로, 프론트에서도 해결할 수 있기는 하다.

• 프록시 서버 사용
• (로컬 한정) http-proxy-middleware 사용 등

 

5-2. CORS 동작 방식 (요청 종류에 따른 분류)

5-2-1. 단순 요청 (Simple Request)

 

• 조건
  • 메서드가 GET, HEAD, 또는 POST 중 하나
  • Content-Type이 text/plain, multipart/form-data, application/x-www-form-urlencoded 중 하나
  • 요청 헤더가 커스텀 헤더 없이 기본적인 것
•  동작
  • 브라우저가 요청을 바로 보냄
  • 서버는 응답에 Access-Control-Allow-Origin 헤더를 포함시킴
  • 브라우저는 응답을 확인한 뒤, 접근 허용 여부 결정
• 예시

GET /image.jpg HTTP/1.1
Origin: https://example.com

Access-Control-Allow-Origin: https://example.com

1.  

 

5-2-2. 사전 요청(Preflight Request)

 

• 조건
  • 메서드가 PUT, DELETE, PATCH 등 단순 요청이 아닌 경우
  • Authorization, X-Custom-Header 같은 커스텀 헤더가 있는 경우
  • Content-Type이 application/json 등 단순 요청 범위를 벗어날 경우
• 동작
  • 브라우저가 먼저 OPTIONS 메서드로 사전 요청을 보냄
  • 서버가 Access-Control-Allow-* 관련 헤더들로 허용 여부 응답
  • 허용되면, 본 요청을 실제로 보냄
• 예시

OPTIONS /data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: Authorization

 

5-2-3. 자격 인증 포함 요청(Credentials Request)

• 조건
  • 요청에 withCredentials: true가 설정된 경우 (예: 쿠키 포함)
  • 서버는 응답에 다음 헤더를 포함해야 함

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: [정확한 origin 문자열] ※ `*` 사용 불가!

 

• 동작
  • 브라우저는 쿠키나 인증 정보를 포함해 요청
  • 서버는 Access-Control-Allow-Credentials: true로 허용 의사 표현
  • 브라우저는 응답 확인 후, 쿠키 포함 결과를 반영

 

6. 참고 문서 및 글

• MDN의 HTTP 헤더
• MDN의 요청 헤더
• MDN의 응답 헤더
• MDN의 사전 요청
• CORS 가 뭔데 CORS 에러 어떻게 해결하는건데