네트워크 | CORS와 SOP

CORS

Cross-Origin Resource Sharing, 교차 출처 리소스 공유

 

웹 애플리케이션이 한 출처(origin)에서 로드된 리소스가 다른 출처의 리소스에 접근할 수 있도록 허용하는 방식

브라우저는 기본적으로 보안 정책으로 인해 서로 다른 출처에서 데이터를 주고받지 못하게 함

CORS는 이를 해결하는 메커니즘으로, 서버가 허용된 출처(origin)를 명시하여 특정 클라이언트에만 리소스 접근을 허용하도록 함

 

필요성

현대 웹 애플리케이션은 외부 API나 다른 도메인의 리소스에 자주 접근해야 함

이를 위해 CORS를 사용하여 다른 출처의 안전하게 요청하고 사용할 수 있도록 함

 

---

SOP

Same-Origin Policy, 동일 출처 정책

 

웹 애플리케이션 보안을 위한 브라우저 정책

한 출처에서 로드된 스크립트가 다른 출처의 리소스에 접근하지 못하도록 제한함

여기서 출처(origin)란, URL의 프로토콜, 도메인, 포트를 모두 포함하는 개념

 

한계

• SOP는 보안을 위해 기본적인 출처 제한을 제공하지만, 일부 상황에서는 정당한 목적의 데이터 요청도 막을 수 있음
  • 예를들어, 프론트엔드 애플리케이션이 외부 API와 통신해야 하는 경우 SOP에 의해 차단될 수 있음
• 이러한 제한을 해결하기 위해 CORS와 같은 메커니즘을 사용하여 안전하게 데이터를 공유할 수 있음

 

---

CORS 작성 방법: CORS 헤더 설정 방법과 예제

CORS는 서버가 설정한 HTTP 헤더를 통해 특정 출처에 대한 접근을 허용함

 

Access-Control-Allow-Origin

요청을 허용할 출처를 지정

*는 모든 출처를 허용함

 

Access-Control-Allow-Methods

허용할 HTTP 메서드 지정 (예: GET, POST)

 

Access-Control-Allow-Headers

클라이언트에서 요청할 수 있는 헤더 목록을 지정

 

Access-Control-Allow-Credentials

인증 정보(쿠키 등)를 포함한 요청을 허용할지 여부를 결정

 

예제

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Credentials: true

이 설정은 https://example.com 출처에서 오는 GET과 POST 요청을 허용하며,

Content-Type 헤더와 인증 정보가 포함된 요청도 허용함

 

---

CORS 작동 방식: 브라우저에서 CORS가 어떻게 작동하는지

hello.com 받아들이지 않을 때 (에러 발생시키는 주체는 브라우저)

단순 요청 (Simple Request)

• 특정 조건(예: GET이나 POST같은 메서드만 사용)을 충족하는 요청은 별도의 사전 요청(preflight) 없이 바로 서버로 전송됨
• 서버는 응답 헤더에 Access-Control-Allow-Origin과 같은 CORS 관련 헤더를 포함해 특정 출처에만 응답을 허용할 수 있음

 

프리플라이트 요청 (Preflignt Request)

• 조건을 충족하지 않는 요청 (예: 커스텀 헤더를 포함하거나, PUT또는 DELETE 같은 메서드를 사용하는 경우)일 때 브라우저는 사전 요청을 보냄
• 사전 요청은 OPTIONS 메서드를 사용해 실제 요청을 보내기 전에 허용된 메서드와 헤더를 확인하는 단계
• 서버는 플리플라이트 요청에 대해 응답을 반환하며, 브라우저는 이를 확인한 후 실제 요청을 보낼지 결정

 

브라우저 차단

만약 서버가 올바른 CORS 헤더를 포함하지 않으면 브라우저는 보안을 위해 해당 리소스에 접근을 차단함

 

 

요약

CORS는 브라우저가 서버의 응답 헤더를 통해 요청이 허용된 출처에서 오는지 확인하고, 이를 바탕으로 접근을 허용하거나 차단하는 방식으로 동작함