cross origin에서 리소스(서버자원)을 요청하여 사용한다.
다른서버에 있는 리소스 자원을 요청해 사용하기 위해 필요하다.
MDN
Cross-Origin Resource Sharing (CORS) 은 추가 HTTP 헤더를 사용하여 브라우저에게 한 출처에서 실행중인 웹 응용 프로그램의 다른 출처의 선택된 자원에 대한 접근 권한을 알려주는 메커니즘입니다. 웹 응용 프로그램은 자신과 다른 출처 (도메인, 프로토콜 또는 포트)를 가진 리소스를 요청할 때 cross-origin HTTP 요청을 실행합니다.
예전에는 서버에서 클라이언트라는 파일을 가지고 있고 유저가 서버에 요청을하면 서버에 있던 클라이언트를 유저가 받아가서 그 클라이언트에서 서버와 통신하거나 클라이언트에 스태틱하게 담겨져있던 데이터를 유저가 일방적으로 보는 방식으로 진행이 되었기때문에 서버에서 내려준 클라이언트는 서버에 위해가 되는 행동을 하지 않을 것이기때문에 의심의 여지가 없었다. 오리진이 같기 때문에 서버가 클라이언트의 요청을 막을 필요가 없었다.
최근에 들어서 싱글페이지 어플리케이션이라는 기술이 등장했고,
웹 애플리케이션이 점점더 고도화 되면서 이제는 우리 서버에만 요청하는 것이 아니라 우리가 만든 어플리케이션에서 유투브, 슬랙, Github 등등의 API를 활용하여 다른 서버에 있는 리소스를 필요로하게 되는 복잡한 웹 애플리케이션이 많아지게 되었다.
다른 서버로 리소스를 요청하는 것을 Cross Origin 요청이라고 한다.
보안상의 이유로 브라우저들은 스크립트 내에서 초기화되는 Cross Origin HTTP 요청을 제한한다.
브라우저에서 크로스 도메인 요청은 기본적으로 제한 되어있다. 만약 요청을 열어 놓으면 우리 서버에 어떤 요청을 할지, 서버에 어떤 리소스를 생성할지를 확인할수 없기때문에 보안상의 이유로 제한되어있는 것이다.
웹 애플리케이션 고도화를 위해 개발자들은
1. cross-domain 요청을 할 수 있도록 요청
2. 서버가 Allow한 범위내에서 cross origin 요청 허용
const defaultCorsHeaders = {
// 모든 도메인(*)을 허용한다.
'access-control-allow-origin': '*',
// 메소드는 GET POST PUT DELETE OPTIONS만 허용 한다.
'access-control-allow-methods': 'GET, POST, PUT, DELETE, OPTIONS',
// 헤더에는 content-type과 accept만 쓸 수 있다.
'access-control-allow-headers': 'content-type, accept',
// preflight request는 10초 까지 허용 된다.
'access-control-max-age': 10 // Seconds.
};
서버에서 Allow 하는 조건들을 다 맞추고 있는가? => 사전에 서버에 확인 하는 요청
ex)
1. post요청을 하기전 브라우저가 사전에 서버에게 이러이런한 방식으로 post요청을 할건데 이것을 너네 서버가 허용하고 있니? 라고 물어본다.
2. 서버가 허용한다고 응답을 하면
3. 실제로 클라이언트에 설정해두었던 post요청을 서버로 보내서 리소스를 생성한다.