CORS 오류란? 해결 방법은?

SOP (Same Origin Policy)란?

• 동일 출처 정책
• 다른 기원에서 온 자원을 제한하는 정책이며 브라우저에서 지원하는 정책 중 하나이다.
• 하나의 Origin에서 다른 Origin으로 통신하지 못하게 막는 정책이다. 자신과 같은 Origin 으로부터만 리소스에 접근 가능하다.
• 보안상 이슈로 CSRF 요청이 난무하지 않도록 하게 하기 위함이다.
• SOP가 없게 된다면 유저가 실수로 google.ca가 아니라 goooogle.ca로 접속했을 때 gooocle.ca에 요청을 보내 기능을 수행하게 하거나, 정보를 탈취할 수 있다. (CSRF, Cross Site Request Forgery)

Same Origin이란?

• 같은 프로토콜, 호스트, 포트를 사용하는 Origin을 말한다.
  

CORS (Cross-Origin Resourse Sharing)란?

• 교차 출처 리소스 공유
• CORS는 SOP로 인한 제약사항을 완화해주는 역할을 한다. Origin이 달라도 리소스를 공유할 수 있도록 도와준다.
• CORS를 허용해주는 경우
  • Simple Request: GET,HEAD,POST 같은 Method와 Content-Type 헤더의 값이 text/plain, application/x-www-form-urlencoded 또는 multipart/form-data 일 때 서버는 요청이 들어온 Origin과 Access-Control-Allow-Origin 헤더에서 허용하고 있는 Origin이 일치하는지 판별하고 다르다면 연결을 종료시킨다.
    • Access-Control-Allow-Origin 은 하나의 Origin만 정의할 수 있고, 여러개일 경우 * 와일드 카드를 사용한다.
  • Non Simple Request:  GET, HEAD, POST Method가 아닌 요청과 1. 에서 언급하지 않는 Content-Type으로 요청이 들어 왔을 때 브라우저는 Preflight Request라는 것을 서버로 보낸다. 서버는 이 Preflight Request가 허용됐는지 판단하고 응답을 보낸다.
• 예전에는 프론트 백엔드를 따로 구성하지 않고 한 번에 구성해 모든 처리가 같은 도메인 안에서 가능했기 때문에 다른 출처로 요청을 보내는 게 의심스러운 행위였다. 시간이 지나 클라이언트와 API가 다른 도메인에 있는 경우가 많아지고, 클라이언트에서 직접 API를 호출하는 방식이 당연해지며 출처가 다르더라도 요청과 응답을 주고받을 수 있도록 서버에 리소스 호출이 허용된 출처 (Origin)을 명시해주는 방식으로 CORS 정책이 생겼다.

CSP (Content Security Policy)란?

• 동일 출처 정책(SOP)를 우회하는 공격법들이 생겨나 최신 브라우저에서 방어책이 몇 가지 있다. Content-Security-Policy HTTP 헤더를 정의하고, 브라우저에는 이런 소스에서 받은 리소스만 실행하거나 렌더링할 것을 지시한다.
• Content-Security-Policy: script-src 'self' [https://apis.google.com](https://apis.google.com/)
  • 스크립트의 출처가 self (현재 위치) 또는 구글 사이트일 경우에만 스크립트 실행을 허용하는 것이다.

CORS 설정 없이 SOP를 우회하여 외부 서버와 통신하는 방법은?

1. 프록시 서버 사용

• 프록시 서버는 브라우저 대신 외부 서버에 요청을 보내고 응답을 받는 역할을 대리 수행하는 서버이다. 브라우저 측에서 직접 요청을 보내지 않고, 클라이언트와 동일한 origin의 프록시 서버를 통해 요청을 보내면 SOP 제한을 피할 수 있다.
• 클라이언트 측 도메인 client.com이고, 서버 측 도메인이 server.com이라고 가정한다. 이때 CORS 설정을 별도로 하지 않았다면, 도메인이 다르므로 브라우저 단에서 SOP에 의해 통신이 차단된다. 브라우저가 아닌 클라이언트 서버로 요청을 보내면 서버와 서버 간의 통신에는 SOP가 적용되지 않기 때문에 응답을 받을 수 있게 된다.
• 이후 클라이언트 서버는 client.com/api/xxx 같은 경로로 server.com 으로부터 받은 응답을 브라우저에 반환한다. 이렇게 하면 클라이언트 측 origin과 서버 측 origin이 client.com으로 일치하기 때문에 정상적으로 응답을 수신할 수 있게 된다.

2. 서버에서 Access-Control-Allow-Origin 응답 헤더 세팅하기

• 요청을 수락할 출처를 명시적으로 지정할 수 있다. 이렇게 헤더를 세팅하면 출처가 다르더라도 리소스를 허용하게 된다.
• 와일드 카드는 출처에 상관없이 리소스에 접근할 수 있지만 보안에 취약해지기 때문에 직접 허용할 출처를 세팅하는 방법이 좋다.

내가 겪은 CORS 오류와 해결 방법

📌문제

TikiTaka 프로젝트 API 연동 도중 다음과 같이 CORS 오류가 발생하였다!

쿠키가 secure 옵션으로 전송될 때 HTTPS 환경에서 인증서가 등록되어 있지 않아 CORS 오류가 발생한 것이었다.

💡 해결 방법

서버에서는 CORS 설정을 완료하고 setAllowCredentials(true)를 포함하여 클라이언트와의 인증 정보를 허용하도록 설정하였고, 프론트에서는 Axios 세팅에서 withCredentials=true로 설정하여 쿠키를 포함한 요청을 전송하도록 하였다.

HTTPS 환경에서 정상적으로 쿠키를 전송하기 위해 인증서를 등록하여 문제를 해결하였다. HTTPS 환경이 구축되면 브라우저는 서버와 안전하게 통신할 수 있다! 결국 CORS 오류는 백엔드 개발자와 빠르게 소통하고 협업하여 해결해야 함을 깨달았다....!

HTTPS는 보안 연결을 제공하는데, 쿠키의 secure 옵션은 HTTPS 연결에서만 작동하므로 인증서가 필요하다. 서버가 HTTPS 환경을 제공하지 않거나 인증서를 제대로 등록하지 않으면, 브라우저가 쿠키를 전달하지 않으며, 이로 인해 CORS 오류가 발생한다. 인증서를 등록하면 브라우저가 서버와 안전하게 통신할 수 있고, CORS 정책 위반 문제가 사라진다.