CORS(교차 출처 리소스 공유)란?

서론

백엔드를 개발하면서 프런트 개발자와 협업을 진행하다 보면 한 번쯤은 위 이미지처럼 CORS 에러에 대해 맞닥뜨린 적이 있을 것입니다. 이번 게시글에서는 이러한 CORS가 뭔지, 그리고 왜 발생하고 어떻게 해결할 수 있는지 한번 정리해 보겠습니다.

 

SOP(Same Origin Policy)

CORS를 알기 전에 먼저 SOP라는 개념에 대해 먼저 알아야 합니다. 

동일 출처 정책(same-origin policy)은 어떤 출처(origin)에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 보안 방식입니다. 동일 출처 정책은 잠재적으로 해를 끼칠 수 있는 요청을 분리함으로써 공격받을 수 있는 경우를 줄여줍니다.

여기서 출처(origin)는 접근할 때 사용하는 URL의 프로토콜, 호스트(도메인), 포트를 의미합니다. 만약 두 객체의 프로토콜, 호스트, 포트가 모두 일치하는 경우 같은 출처를 가졌다고 말합니다.

URL의 구조

위 이미지에서 HTTP 혹은 HTTPS의 경우가 프로토콜이 되고, www.example.com의 경우 호스트(도메인)가 되며, 80의 경우 포트가 됩니다.

기본적으로 프로토콜의 HTTP는 80번, HTTPS는 443번 포트를 사용하며, 80번과 443번 포트는 생략이 가능합니다.

즉, 정리하면 출처(Origin)란 URL 구조에서 살펴본 프로토콜, 호스트, 포트를 합친 것을 의미합니다. 

동일 출처 VS 다른 출처

URL	결과	이유
http://example.com/app1/index.html http://example.com/app2/index.html	동일 출처	프로토콜(http)와 호스트(example.com) 일치
http://Example.com:80  http://example.com	동일 출처	HTTP의 기본 포트는 80이므로 생략가능 하기에 동일 출처 (대소문자는 동일한 것으로 간주)
http://example.com/app1 https://example.com/app2	다른 출처	서로 프로토콜(http, https)가 다름
http://example.com http://www.example.com http://myapp.example.com	다른 출처	서로 호스트가 다름
http://example.com http://example.com:8080	다른 출처	서로 포트가 다름

그렇다면 왜 동일 출처 정책(same-origin policy, SOP)을 사용하면 보안에 도움이 되는지 알아보겠습니다.

동일 출처 정책(same-origin policy, SOP)이 왜 필요할까?

위 이미지에서 domainA라는 사이트에 접속해서 로그인을 했다고 가정합시다. 그리고 domainA라는 사이트 내에서 pg2라는 페이지로 이동할 수도 있고, domainB라는 사이트로 이동할 수 있다고 가정합시다.

domainA/pg2라는 페이지의 경우 이전 페이지인 domainA/pg와 같은 출처(origin) 이기 때문에 동일한 로그인 정보를 가지고 서비스를 이용할 수 있습니다. 하지만 domainB/pg라는 페이지는 domainA와는 다른 출처(origin)입니다. 따라서 domainB라는 사이트에서는 domainA에 로그인된 정보를 탈취하여 민감한 정보를 가지고 온다거나 하는 불미스러운 상황이 일어날 수도 있습니다.

그렇기 때문에 이제 여기서 SOP의 기능이 발휘하게 됩니다. 

1. domainA의 입장에서는 다음 요청(domainB)의 출처(origin)를 확인합니다.
2. 확인해 보니 이 요청은 domainB에서 왔습니다.
3. domainA는 이 요청이 다른 출처(origin)이라고 판단 즉, cross origin이라고 판단을 하게 됩니다.
4. 따라서 domainB의 요청은 받아들여지지 않습니다.

그렇다면 만약 다른 출처(domainB)의 리소스가 필요하다면 어떻게 할까요?

바로 이때 CORS가 사용됩니다.

 

CORS

교차 출처 리소스 공유(Cross Origin Resource Sharing, CORS)는 다른 출처의 자원을 공유하는 것을 의미합니다.

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

여기서 중요한 점은 첫째, 다른 출처에 접근을 할 수 있도록 하는 것이고 둘째, 권한을 브라우저에게 알려주는 체제라는 것입니다.

CORS의 접근 방법은 크게 세 가지가 있습니다.

1. 단순 요청(Simple Request)
2. 사전 요청(Prefilight Request)
3. 인증정보 포함 요청(Credentialed Request)

 

단순 요청(Simple Request)

단순 요청은 서버에게 바로 요청을 보내는 방법입니다.

단순 요청(Simple Request)

위 이미지는 자바스크립트에서 API를 요청할 때 브라우저(크롬, 웨일 등)와 서버의 동작을 나타내는 이미지입니다.

단순 요청은 서버에 API를 요청하고, 서버는 Access-Control-Allow-Origin 헤더를 포함 한 응답을 브라우저에 보냅니다. 브라우저는 Access-Control-Allow-Origin 헤더를 확인해서 CORS 동작을 수행할지 판단합니다.

Simple request 조건

서버로 전달하는 요청(request)이 아래의 3가지 조건을 만족해야 서버로 전달하는 요청이 단순 요청으로 동작합니다.

1. 요청 메서드(method)는 GET, HEAD, POST 중 하나여야 한다.
2. 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 중 하나를 사용해야 한다.

첫 번째 조건은 어렵지 않은 조건이지만 2번, 3번 조건은 까다로운 조건입니다. 2번 조건은 사용자 인증에 사용되는 Authorization 헤더도 포함되지 않아 까다로운 조건이며, 3번 조건은 많은 REST API들이 Content-Type으로 application/json을 사용하기 때문에 지켜지기 어려운 조건입니다.

 

사전 요청(Preflight request)

사전 요청(Preflight request) 요청은 서버에 예비 요청을 보내서 안전한지 판단 후 본 요청을 보내는 방법입니다. 

사전 요청(Preflight request)

사전 요청은 실제 리소스를 요청하기 전에 OPTIONS라는 다른 도메인의 리소스에 요청이 가능한지 확인 후, 가능하다면 실제 요청(Actual Request)을 보냅니다.

OPTIONS 메서드로 서버에 예비 요청을 먼저 보내고, 서버는 이 예비 요청에 대한 응답으로 Access-Control-Allow-Origin 헤더를 포함한 응답을 브라우저(크롬, 웨일 등)에 보냅니다. 브라우저는 단순 요청과 동일하게 Access-Control-Allow-Origin 헤더를 확인해서 CORS 동작을 수행할지 판단합니다.

사전 요청 방식은 사전 요청과 실제 요청 총 두 번 보내지게 됩니다. 이렇게 되면은 매번 하나의 요청을 보낼 때마다 두 번의 요청이 왔다 갔다 하게 됩니다. 따라서 굉장히 리소스적으로 부담이 되게 됩니다. 따라서 이를 해결하기 위해 OPTIONS 메서드의 응답에 대해서 브라우저는 캐싱을 해두고 일정 시간 동안 다음 똑같은 요청을 보낼 때 preflight 캐싱된 것을 확인하고 동일한 요청이라면 사전 요청을 미리 보내지 않고 바로 본 요청을 보내는 방식으로 부담을 줄입니다.

Preflight Request

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

Preflight Response

• Access-Control-Allow-Origin : 허가 출처
• Access-Control-Allow-Methods : 허가 메서드
• Access-Control-Allow-Headers : 허가 헤더
• Access-Control-Max-Age : Preflight 응답 캐시 시간

여기서 Preflight Response의 응답 코드는 200대여야 하고 Body는 비어있는 것이 좋다.

 

인증 요청(Credentialed Request)

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

• 클라이언트: 쿠키 또는 JWT 토큰을 담아 보낼 경우 credentials : include를 포함하여 보냅니다.
• 서버: Access-Control-Allow-Credentials를 true로 설정 시 클라이언트의 인증 포함 요청 허용이 가능해집니다.

 

CORS의 해결

CORS의 해결에는 세 가지 방법이 있습니다.

1. 프런트 프록시 서버 설정: 프런트 서버에서 백엔드 서버로 요청을 보낼 때, 대상의 URL을 변경합니다.
2. 직접 헤더 설정: 직접 헤더에 설정을 추가합니다.
3. 서버에서 스프링 부트 내 설정: 설정 클래스를 만들고 WebMvcConfigurer을 구현하면 addCorsMappings란 메서드를 사용하여 CORS의 출처 및 설정을 관리할 수 있습니다.

3번의 방법은 아래로 해결이 가능합니다.

package com.example.demo.src;

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {
    private static final long MAX_AGE_SECOND = 3600;

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(MAX_AGE_SECOND);
    }

}

src 폴더에 WebConfig.java 파일을 생성하여 위 코드를 작성해 주시면 됩니다.

하지만 브라우저에서 보안을 위해 의도적으로 제한해놓은 기능을 서버에서 강제로 허용하는 것은 좋지 않기 때문에 프런트에서 1번의 방법으로 해결하는 것을 권장합니다.

 

참고

1. https://beomy.github.io/tech/browser/cors/
2. https://www.youtube.com/watch?v=-2TgkKYmJt4&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9CTech 
3. https://developer.mozilla.org/ko/docs/Glossary/Origin