CORS

SOP(Same Origin Policy)

SOP는 다른 출처의 리소스를 사용하는 것을 제한하는 보안 방식이며 이는 URL의 프로토콜, 호스트, 포트가 같음을 의미합니다.

이 세 가지가 무엇이라도 하나가 다르면 다른 출처라고 판단을 하는 것입니다.

 

 

이는 토큰이 유출되어도 요청의 Origin을 확인하기고 다른 출처(cross origin)로 판단해 요청을 막을 수 있습니다.

그렇다면 다른 출처의 리소스가 필요하다면 어떻게 할까에서 CORS가 등장합니다.

 

CORS(Cross-Origin Resource Sharing)

교차 출처 리소스 공유는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할  수 있는 권한을 부여하도록 브라우저에게 알려주는 체제입니다.

-MOZILLA

 

CORS 접근 제어 시나리오

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

OPTIONS 메서드를 통해 다른 도메인의 리소스에 요청 가능한 지 확인하는 작업을 거치고 요청이 가능하다면 실제 요청을 보냅니다.

프리플라이트 요청은 다음 세 가지를 포함합니다.

 

• Origin: 요청 출처
• Access-Control-Request-Method : 실제 요청의 메서드
• Access-Control-Request-Headers: 실제 요청의 추가 헤더

 

프리플라이트 응답은 다음 네 가지를 포함합니다.

 

• Access-Control-Allow-Origin: 서버 측 허가 출처
• Access-Control-Allow-Methods: 서버 측 허가 메서드
• Access-Control-Allow-Headers: 서버 측 허가 헤더
• Access-Control-Max-Age: 프리플라이트 응답 캐시 시간

 

CORS spec이 생기기 이전에 만들어진 서버들은 브라우저의 SOP request만 가능하다는 가정하에 만들어졌는데, CORS로 인해서 이러한 서버들을 보호하기 위해 프리플라이트 요청이 필요해지게 됩니다.

따라서 프리플라이트 요청은 서버가 CORS를 인식하고 핸들 할 수 있는지 먼저 확인함으로써 CORS를 인식하지 못하는 서버들을 보호할 수 있는 메커니즘입니다.

 

 

단순 요청(Simple Request)

프리플라이트 요청 없이 바로 요청을 날립니다.

메서드는 GET, POST, HEAD 중 하나, Content-Type은 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나, 헤더는 Accept, Accept-Language, Content-Language, Content-Type 만 허용합니다.

인증정보 포함 요청(Credential Request)

인증 관련 헤더를 포함할 때 사용하는 요청입니다.

쿠키나 JWT 토큰을 클라이언트에서 자동으로 담아서 보내고 싶을 때 credentials: include를 통해 할 수 있으며 서버 측에서도 설정이 필요합니다.