🦖

웹 프로그래밍에서, 특히 프론트에서 CORS 문제가 종종 발생한다. 이는 로컬에서 확인을 할 때에도, Postman으로 요청을 보낼 때에도 아무런 문제가 없다가, 프론트에서 브라우저를 통해 요청을 보낼 때면 발생하는 문제이기에 처음 직면하면 당황스러울 수 있는 문제이다. 이러한 CORS 에러가 왜 발생하는지, CORS란 무엇인지 제대로 알아보자! 🍀

---

🚧 CORS

CORS(Cross-Origin Resource Sharing)의 개념을 이해하기 위해서는, 우선 Origin(출처)이 무엇인지 알아야 한다 :)

Origin (출처)

우리가 평소 접근하는 URL은 다음과 같이 구성되어 있다..

위의 구성요소 중에서 Protocol + Host + Port 이 셋을 합친 부분을 Origin, 출처라고 부른다. 이 부분이 같으면 동일 출처(Same-Origin), 다르면 다른 출처(Cross-Origin)라 하는 것이다.

다른 출처 요청의 위험성

서로 출처가 다른 (Cross-Origin) 웹사이트 간의 요청은 생각보다 큰 위험성을 지닌다. 이는 동일 출처 정책(SOP)이 존재하는 이유이기도 하다. 그렇다면, 다른 출처의 요청은 왜 위험할까? 동일 출처 정책이 왜 필요한 걸까?

우선 알아둘 것은, SOP : 동일 출처 정책이란, 동일한 출처의 웹페이지 사이에서만 요청을 할 수 있도록 제한하는 정책이다.
이해를 위해 쉽게 얘기하자면, '신뢰하는 곳'으로부터 '신뢰하지 않는 곳'으로 보내는 요청을 내 컴퓨터의 '브라우저'가 막는 것이다.

지난번에 살펴본 쿠키/세션/토큰의 내용을 조금 짚어보자. 우리가 안전한 웹페이지A에 로그인하면, 매번 다시 로그인해야 하는 이상한 상황을 방지하기 위해 우리 컴퓨터의 브라우저는 쿠키의 형태로 우리의 정보를 저장해 두었다가 요청 시 함께 보낸다.

이 점이 중요하다. 우리의 브라우저는 중요한 '로그인 정보'를 가지고 있다. 만약 '신뢰하지 않는 웹페이지B'에 방문했다가 (이 웹 페이지가 악의를 두고 만든 것일 경우) 브라우저의 정보를 가져가거나 데이터를 변경해버리는 불상사가 일어날 수 있는 것이다.

그래서 등장한 것이 바로 동일 출처 정책이다!

SOP (Same-Origin Policy) 동일 출처 정책

동일 출처 정책(Same-origin policy)은 브라우저의 정책 중 하나로, 다른 출처로부터 조회된 자원들의 읽기 접근을 막아 다른 출처 공격을 예방한다.

요청하는 클라이언트와 요청받는 서버가 같은 출처에 있으면 동일 출처, 서로 다른 서버에 있으면 다른 출처 요청이다.

즉, 프론트-백이 각각 front-tino.com / back-tino.com의 도메인을 가질 때 front-tino.com에서 back-tino.com에 요청을 보내면 이것은 다른 출처 요청에 해당하는 것이다.

기본적으로는 동일 출처 요청만 자유롭게 요청이 가능하기에 각각이 아무런 설정을 해두지 않는다면 위처럼 프론트에서 백에 요청하는 것은 CORS error가 발생하며 요청에 실패한다.

---

✨
그러나, 점차 인터넷이 발전하고 한 출처에서 다른 출처의 자원을 필요로 하는 상호적 관계가 발전하면서 SOP는 많은 불편을 야기했다. 이때문에 새롭게 생겨난 브라우저의 정책이 CORS이다.

---

CORS (Cross-Origin Resource Sharing) 다른 출처의 자원 공유

CORS(Cross-Origin Resource Sharing)는 출처가 다른 자원들을 공유한다는 뜻으로, 한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 개념이다.

위에서 언급한 것처럼, SOP로 인해 '동일 출처 내의 요청'으로만 제한됐던 요청에 대해 그 제한을 풀어주는 것이 CORS이다.

(+) 처음에는 CORS 에러를 보고, CORS가 접근을 막는 것이라고 생각했는데, 오히려 SOP가 접근을 막고 CORS가 그것을 일부 풀어주는 것이었다...!

웹 애플리케이션은 리소스가 자신의 출처(도메인+프로토콜+포트)와 다를 때 교차 출처 HTTP 요청을 실행한다. 이는 추가 HTTP 헤더를 사용해 브라우저에 알린다.

---

🚥 CORS 정책 3가지

1. Simple Request

단순 요청은 서버에 바로 요청을 보낸 후, 서버가 응답 헤더에 Access-Contorol-Allow-Origin과 같은 값을 보내면 그 때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다.

예비 요청을 생략할 수 있는 Simple Request는 특정 조건을 만족해야 한다.

• 요청 메서드는 GET, HEAD, POST 중 하나여야 한다.
• Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
• 만약 Content-Type를 사용하는 경우 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.

-> 하지만 일반적인 방법으로 웹 애플리케이션 아키텍처를 설계하게 되면 거의 충족시키기 어려운 조건들이므로, 사실상 Simple Request의 경우는 보기 어렵다.

2. Preflight Request

일반적으로 웹 애플리케이션을 개발하라 때 가장 많이 마주치는 상황으로, 이 상황에서 브라우저는 요청을 한 번에 보내지 않고 예비 요청과 본 요청으로 나누어서 서버로 전송한다.

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

JavaScript에서 브라우저에게 리소스를 받아오는 명령을 내리면 브라우저는 서버에게 예비 요청(OPTIONS)을 먼저 보낸다.

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

예를 들어 응답 헤더에 Access-Control-Allow-Origin 항목을 추가하여 허용할 도메인을 지정할 수 있는데, 설정하게 되면 개발자 도구에서 아래와 같이 확인할 수 있다.

Access-Control-Allow-Origin: https://example.com

브라우저는 서버가 보낸 Response 정보를 이용하여 허용되지 않은 요청인 경우 405 Method Not Allowed 에러를 발생시키고, 실제 페이지의 요청(본 요청)은 서버로 전송하지 않는다.

반대로 허용된 요청인 경우, 다시 본 요청을 보내게 된다. 그리고 서버가 본 요청에 대한 응답을 하면 브라우저는 최종적으로 응답 데이터를 자바스크립트에 넘겨준다.

3. Credentialed Request

또 다른 시나리오는, 헤더에 인증과 관련된 정보(쿠키, 토큰 등)를 담아서 보내는 Credential Request (인증된 요청)를 사용하는 방법이다.

이는 CORS의 기본적인 방식이라기 보다는 다른 출처 간 통신에서 좀 더 보안을 강화하고 싶을 때 사용하는 방법이다.

서버로 쿠키를 함께 전송해야 하는 경우가 있는데, 요청에 쿠키가 담기게 되면 Credentialed Request 허용이 되어 있어야 한다.

즉, 인증과 관련된 정보를 담을 수 있게 해주는 옵션 'credentials'를 줘야하는데, 이 때 서버 쪽에서 응답 헤더에 Access-Control-Allow-Credentials: true를 보내주지 않는다면 브라우저에서 응답을 받는 것을 거부하게 된다.

이 옵션에는 총 3가지의 값을 사용할 수 있으며, 각 값들이 가지는 의미는 다음과 같다.

옵션 값	설명
same-origin(기본값)	같은 출처 간 요청에만 인증 정보를 담을 수 있다
include	모든 요청에 인증 정보를 담을 수 있다
omit	모든 요청에 인증 정보를 담지 않는다

만약 same-origin이나 include와 같은 옵션을 사용하여 리소스 요청에 인증 정보가 포함된다면, 이제 브라우저는 다른 출처의 리소스를 요청할 때 단순히 Access-Control-Allow-Origin만 확인하는 것이 아니라 좀 더 빡빡한 검사 조건을 추가하게 된다.

요청에 인증 정보가 담겨있는 상태에서 다른 출처의 리소스를 요청하게 되면 브라우저는 CORS 정책 위반 여부를 검사하는 룰에 다음 두 가지를 추가하게 된다.

1. Access-Control-Allow-Origin에는 * (와일드카드)를 사용할 수 없으며, 명시적인 URL이어야한다.
   (https://foo.com과 같이 구체적인 origin을 지정해주어야 한다.)

2. 응답 헤더에는 반드시 Access-Control-Allow-Credentials: true가 존재해야한다.

---

🌿 Spring Boot에서 cross-origin 설정하기

SpringBoot와 같이 일부 프레임워크는 개발자가 cross-origin을 코드 단 몇줄만으로 쉽게 설정할 수 있는 기능을 제공한다. SpringBoot에서는 어떻게 설정하고 사용할 수 있는지 알아보자.

메서드 설정, 컨트롤러 설정이 있으며 개별적으로 적용 할 수도 있다.

메서드에 설정하기

@RestController
@RequestMapping("/account")
public class AccountController {

    @CrossOrigin
    @RequestMapping(method = RequestMethod.GET, path = "/{id}")
    public Account retrieve(@PathVariable Long id) {
        // ...
    }

    @RequestMapping(method = RequestMethod.DELETE, path = "/{id}")
    public void remove(@PathVariable Long id) {
        // ...
    }
}

retrieve() 메서드에 선언된 @CrossOrigin의 기본 설정은 다음과 같다.
1. 모든 출처가 허용된다.
2. 허용된 HTTP 메서드는 @RequestMapping에 선언된 메서드들이다.
3. 프리플라이트 응답은 30분 동안 캐시된다.

컨트롤러에 설정하기

@CrossOrigin(origins = "http://example.com", maxAge = 3600)
@RestController
@RequestMapping("/account")
public class AccountController {

    @RequestMapping(method = RequestMethod.GET, path = "/{id}")
    public Account retrieve(@PathVariable Long id) {
        // ...
    }

    @RequestMapping(method = RequestMethod.DELETE, path = "/{id}")
    public void remove(@PathVariable Long id) {
        // ...
    }
}

컨트롤러에 설정했으므로 AccountController에 있는 retrieve() 와 remove() 함수 모두에 적용된다.

개별 적용시키기

@CrossOrigin(maxAge = 3600)
@RestController
@RequestMapping("/account")
public class AccountController {

    @CrossOrigin("http://example.com")
    @RequestMapping(method = RequestMethod.GET, "/{id}")
    public Account retrieve(@PathVariable Long id) {
        // ...
    }

    @RequestMapping(method = RequestMethod.DELETE, path = "/{id}")
    public void remove(@PathVariable Long id) {
        // ...
    }
}

스프링에서 여러가지 CORS 정책을 복합해서 설정 할 수 있다.

모든 메서서드들은 3600초가 캐시 시간이다. retrieve() 메서드는 허용 출처가 "http://example.com" 밖에 안된다. 하지만, remove() 메서드는 별도의 설정이 없으므로 모든 출처가 가능하다.

전역 설정하기

CORS 정책의 설정은 WebMvcConfigurer를 구현하여 설정할 수 있다. 이는 필터 기반이기 때문에, 전역적으로 모든 요청에 대해서 검사한다.

@Configuration
@EnableWebMvc
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**");
    }
}

---

💊 CORS 문제 해결

서두에서, 프론트에서 브라우저를 통해 요청을 보낼 때면 발생하는 CORS에 대해서 언급했었다.

CORS의 개념을 이해하고 생각을 바꾸게 된 것은, CORS는 요청을 막는 정책이 아니라 오히려 SOP(동일 출처 정책)가 제한해둔 요청을 풀어주기 위해 사용하는 것이 CORS 정책이라는 사실이다.

결론적으로, CORS 문제에 맞닥뜨릴 경우 위에서 다룬 cross-origin 설정으로 해결하면 된다! 🤗

---

📝 정리하기
CORS는 브라우저의 정책 중 하나로, SOP로 제한된 '다른 출처 요청'에 대해 그 제한을 풀어주는 정책이다. 즉, 다른 출처 Cross-Origin 사이의 자원 공유가 가능하도록 하는 정책이다.