[네트워크]CORS란?

CORS(Cross-Origin Resource Sharing) : 교차 출처 리소스 공유
출처가 다른 자원들을 공유한다는 뜻으로, 한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 개념이다.
즉, CORS란 도메인이 다른 서버끼리 리소스를 주고 받을 때 보안을 위해 설정된 정책이다.

 

 

출처(Origin)

출처는 Protocol과 Host, :80,:443과 같은 포트번호까지 모두 합친 것을 의미한다. 즉, 서버의 위치를 찾아가기 위해 필요한 가장 기본적인 것들을 합쳐 놓은 것이다.

또한 출처 내의 포트 번호는 생략이 가능한데, 이는 각 웹에서 사용하는 HTTP, HTTPS 프로토콜의 기본 포트 번호가 정해져있기 때문이다. (port 80)

 

그러나 만약 https://google.com:443 과 같이 출처에 포트 번호가 명시적으로 포함되어 있다면

이 포트 번호까지 모두 일치해야 같은 출처라고 인정된다.

하지만 이 케이스에 대한 명확한 정의가 표준으로 정해진 것은 아니기 때문에, 더 정확히 이야기하자면 어떤 경우에는 같은 출처, 또 어떤 경우에는 다른 출처로 판단될 수도 있다.

 

Cross-Origin (다른 출처) 판단 기준

두 개의 출처가 서로 같다고 판단하는 로직은, 두 URL의 구성요소 중 Scheme(프로토콜),Host(도메인),Port 3가지만 동일하면 된다.

따라서 일반적으로는 same-origin이란 scheme(프로토콜), host(도메인), 포트가 같다는 말이며, 이 3가지 중 하나라도 다르면 cross-origin이다.

---

2. 종류

1.단순 요청

1. 요청의 메소드는 GET, HEAD, POST 중 하나여야 한다.
2. Request Header에는 Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width 속성만 허용
3. Content-Type 헤더가 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나여야 함
4. XMLHttpRequest나 fetch 요청이 커스텀 헤더를 포함하지 않아야 함
5. 서버는 Access-Control-Allow-Origin 응답 헤더를 추가해야 함

🚨 Simple Request가 일반적으로 드문 이유

1. 웹 애플리케이션에서는 application/json을 많이 사용
   • 대부분의 API는 application/json을 사용하여 데이터를 주고받음 → Simple Request가 아님
2. 사용자 인증을 위해 Authorization 헤더를 추가하는 경우 많음
   • Authorization 헤더를 포함하면 Simple Request가 아님
3. 커스텀 헤더를 사용하는 경우 많음
   • 예를 들어, X-User-ID 같은 헤더를 추가하면 Simple Request가 아님
4. POST 요청도 특정 Content-Type을 사용하면 Preflight가 필요함
   • application/json을 사용하는 POST 요청은 서버 데이터에 영향을 줄 가능성이 있어 Preflight 요청이 필요함

📌 결론

• Simple Request가 되려면 엄격한 조건을 만족해야 하므로, 실제 웹 애플리케이션에서는 거의 사용되지 않음
• 대부분의 HTTP API는 application/json을 사용하거나, Authorization 같은 인증 헤더를 필요로 하므로, 결국 Preflight Request(예비 요청)를 동반하는 CORS 요청이 일반적임

---

2.예비요청

프리플라이트(Preflight) 방식은 일반적으로 우리가 웹 어플리케이션을 개발할 때 가장 마주치는 시나리오이다. 이 시나리오에 해당하는 상황일 때 브라우저는 요청을 한번에 보내지 않고 예비 요청과 본 요청으로 나누어서 서버로 전송한다.

예비요청 HTTP 메소드 중 OPTIONS 메소드가 사용된다. 예비요청의 역할은 본요청을 보내기 전에 브라우저 스스로가 이 요청을 보내는 것이 안전한지 확인하는 것이다.

이후 OPTION 요청을 받은 서버는 Response Header에 서버가 허용할 옵션을 설정하여 브라우저에게 전달한다.

 

다음 중에 하나라도 포함되면 예비요청이 필요함.

• PUT, DELETE, PATCH 등의 메서드 사용
• Authorization 등의 커스텀 헤더 포함
• application/json 같은 특정 Content-Type 사용 

---

3.인증된 요청

Credential Request 방식은 CORS 요청에 인증 정보를 포함하는 방식이다.

쿠키,토큰 세션 정보 등을 서버로 전달할 때 사용되며, 기본 CORS보다 보안을 강화하기 위한 방법이다.

📌 인증 정보를 포함하는 방법

JavaScript의 fetch API, Axios, Ajax 등을 사용할 때 요청에 인증 정보를 포함하려면,credentials 옵션을 설정해야 함

옵션 값	설명
same-origin (기본값)	같은 출처에서만 인증 정보를 포함 가능
include	모든 요청에 인증 정보를 포함
omit	모든 요청에서 인증 정보를 제외

//fetch API에서 쿠키 포함하기
fetch('<https://example.com/data>', {
  method: 'GET',
  credentials: 'include'  // 모든 요청에서 인증 정보 포함
});

🚨 Credential Request의 추가 검사 조건

서버에서 추가적인 응답 헤더를 설정해야 함

1. Access-Control-Allow-Origin에 와일드카드(*) 사용 불가
   • Access-Control-Allow-Origin: * ❌ (불가능)
   • Access-Control-Allow-Origin: <https://example.com> ✅ (명확한 도메인 필요)
2. Access-Control-Allow-Credentials: true가 필요
   • 서버 응답 헤더에 반드시 추가

   Access-Control-Allow-Origin: <https://example.com>
   Access-Control-Allow-Credentials: true
   

📌 결론

• credentials: include 옵션을 사용하면 쿠키, 토큰 등 인증 정보를 포함한 요청이 가능
• 보안을 위해 브라우저가 추가적인 검사 조건을 적용함
  1. Access-Control-Allow-Origin에 명확한 도메인 지정 필요
  2. Access-Control-Allow-Credentials: true 응답 헤더 필요
• 이 설정이 없으면 브라우저가 응답을 차단함 🚫

즉, CORS 요청에서 인증 정보를 포함하려면, 서버도 이를 허용하도록 설정해야 함!

---

CORS 응답 헤더

서버에서 응답 시 CORS를 허용하려면 다음과 같은 HTTP 헤더를 설정해야 합니다.

응답	헤더 설명
Access-Control-Allow-Origin	허용할 출처를 지정 (* 사용 시 모든 출처 허용)
Access-Control-Allow-Methods	허용할 HTTP 메서드 (GET, POST, PUT, DELETE 등)
Access-Control-Allow-Headers	허용할 요청 헤더 (Content-Type, Authorization 등)
Access-Control-Allow-Credentials	true 설정 시 쿠키 및 인증 정보 포함 요청 허용
Access-Control-Max-Age	예비 요청의 캐싱 시간(초 단위)

 

 

 

참고

https://velog.io/@effirin/CORS란?