CORS 에러를 프론트에서 해결? 무시? 아무튼? 해보자!

CORS 에러는 터지는데.. 아무힘이 없는 프론트 개발자가 과연 무얼 할 수 있을까?

 

CORS란?

CORS (Cross-Origin Resource Sharing)는 웹 어플리케이션에서 다른 도메인의 리소스에 접근할 때 발생하는 보안 이슈를 해결하기 위한 표준 방법이다. CORS는 브라우저 단에서 작동하며, 웹 서버가 특정한 HTTP 헤더를 반환함으로써 웹 브라우저가 자원에 대한 권한을 부여하도록 한다. 이 헤더는 서버에게 특정한 도메인, 프로토콜, 포트에서만 요청을 허용하도록 지시할 수 있다.

CORS는 웹 어플리케이션에서 다른 도메인으로부터 리소스를 요청하는 데에 있어서 발생하는 보안 문제를 해결한다. 이전에는 같은 도메인에서만 요청할 수 있었기 때문에, 다른 도메인으로 요청을 보내는 경우 보안 문제가 발생할 수 있었다. 그러나 CORS를 사용하면 다른 도메인에서도 자원에 접근할 수 있다.

CORS는 다음과 같은 방법으로 작동한다.

1. 브라우저는 HTTP 요청을 보낸다.
2. 서버는 요청에 대한 응답을 반환한다.
3. 브라우저는 응답을 분석하여 CORS 헤더를 확인한다.
4. CORS 헤더가 존재하면 브라우저는 자원에 대한 권한을 검사한다.
5. 권한이 허용되면 자원을 사용하고, 그렇지 않으면 에러가 발생한다.

CORS는 웹 애플리케이션에서 다른 도메인의 리소스에 접근하는 데 있어서 필수적인 보안 기능이다. CORS 에러를 해결하기 위해서는 해당 상황에 맞는 CORS 설정을 서버 측에서 제공해야 한다. 그러나 CORS 설정이 잘못되면 보안 위험을 초래할 수 있으므로, 서버 개발자는 반드시 적절한 설정을 수행해야 한다. 또한, 보안을 위해서는 최소한의 CORS 설정만을 허용하는 것이 좋다.

 

CORS 에러가 발생하는 경우를 알아보자.

1. 출처가 다른 도메인 또는 포트로 리소스를 요청할 때
CORS 정책에 따라, 출처가 다른 도메인이나 포트에서 리소스를 요청하는 경우에는 브라우저에서 CORS 에러가 발생한다. 이 경우에는 서버 측에서 Access-Control-Allow-Origin 헤더를 설정하여 요청을 허용해야 한다.

2. HTTPS에서 HTTP로 리소스를 요청할 때
보안상의 이유로 HTTPS에서 HTTP로 리소스를 요청하는 경우에도 CORS 에러가 발생할 수 있다. 이 경우에는 HTTPS로 통신하는 서버에서 HTTP로 요청을 전달하는 것이 아니라, HTTPS로 전달해야 한다.

3. 인증 정보를 포함한 요청을 보낼 때
CORS 정책에 따라, 인증 정보를 포함한 요청을 보낼 때에는 서버에서 Access-Control-Allow-Credentials 헤더를 설정해야 한다. 이 헤더가 설정되어 있지 않으면 브라우저는 인증 정보가 포함된 요청을 거부한다.

4. 허용되지 않은 메서드를 사용할 때
CORS 정책에 따라, 허용되지 않은 메서드를 사용하는 요청을 보내는 경우에는 CORS 에러가 발생한다. 이 경우에는 서버에서 Access-Control-Allow-Methods 헤더를 설정하여 요청을 허용해야 한다.

5. 허용되지 않은 헤더를 사용할 때
CORS 정책에 따라, 허용되지 않은 헤더를 사용하는 요청을 보내는 경우에도 CORS 에러가 발생한다. 이 경우에는 서버에서 Access-Control-Allow-Headers 헤더를 설정하여 요청을 허용해야 한다.

6. 프리플라이트 요청에 대한 응답이 없는 경우
브라우저는 CORS 정책을 준수하기 위해, 프리플라이트 요청을 보내고 서버에서 이에 대한 응답을 받아야 한다. 이 때, 서버에서 응답이 없는 경우에는 CORS 에러가 발생한다. 이 경우에는 서버에서 프리플라이트 요청에 대한 응답을 보내도록 설정해야 한다.

7. 브라우저가 CORS를 지원하지 않는 경우
일부 오래된 브라우저에서는 CORS를 지원하지 않는 경우가 있다. 이 경우에는 서버 측에서 다른 방법을 사용하여 요청을 처리해야 한다.

8. CDN 등에서 제공하는 리소스를 요청할 때
일부 CDN 등에서 제공하는 리소스를 요청할 때에도 CORS 에러가 발생할 수 있다. 이 경우에는 CDN 서비스 제공 업체에서 CORS 설정을 제공하고 있으므로 해당 설정을 확인해야 한다.

9. 브라우저 설정 문제
일부 브라우저에서는 CORS 에러가 발생하는 경우가 있는데, 이는 브라우저 설정에서 발생하는 문제일 수 있다. 이 경우에는 브라우저 설정을 확인하거나, 다른 브라우저를 사용하여 문제를 해결할 수 있다.

 

자.. 그럼 일단 결론은 뭐다? 서버 개발자에게 요청을 해야 한다~

??? : 근데.. 어떡하죠..? 서버 개발자가 휴가를 떠났어요..!!!!

그렇다면 일단 프론트 쪽에서라도 살펴볼 수 있는 방법들을 알아보자.

 

혹시 인증 정보를 빠트리진 않았나?

위의 3번, 인증 정보를 포함한 요청을 보낼 때의 경우는 프론트에서도 처리해줘야 할 한 가지가 있다. 바로 withCredentials 옵션을 추가하는 것.

브라우저 측에서는 CORS 에러를 방지하기 위해 XMLHttpRequest나 fetch API 등을 사용할 때, withCredentials 속성을 설정하거나, crossorigin 속성을 사용하여 요청을 보내야 한다. 이렇게 설정해야 브라우저가 CORS 에러가 발생하지 않도록 처리해 준다.

기본적으로 브라우저가 제공하는 요청 API 들은 별도의 옵션 없이 브라우저의 쿠키와 같은 인증과 관련된 데이터를 함부로 요청 데이터에 담지 않도록 되어있다. 이는 응답을 받을때도 마찬가지이다. 따라서 요청과 응답에 쿠키를 허용하고 싶다면 withCredentials 옵션을 사용해야 한다.

분명 withCredentials 옵션을 추가했는데 쿠키가 안들어가는 현상이 발생했는가? 혹시 인증을 진행한 도메인과 리다이렉트 된 도메인이 다르진 않은지 확인해보자. 쿠키는 도메인 별로 저장된다. 리다이렉트 된 로컬호스트와 인증을 진행한 도메인이 다르다면 hosts 파일을 수정해서 도메인을 동일하게 만들어주자.

 

mkcert, 들어는 보셨나?

어쩌다 서버까지 개발을 하게 된 불쌍한 프론트 개발자 A. 개발 서버는 http로 로컬에서 돌아가고 있는데 아뿔싸, 프론트엔드는 https로 동작하고 있다는데… 이는 바로 위의 2번, HTTPS에서 HTTP로 리소스를 요청할 때에 해당하는 경우인 것이다.

그런 경우가 어떻게 발생할 수가 있냐고? 나는 이 문제를 피그마 플러그인을 개발하면서 겪어봤다. 피그마 플러그인은 dev 환경이 https로 동작할 수밖에 없기 때문에, 플러그인용 서버를 함께 개발해야 하는 상황에서 난관에 부딪힐 수밖에 없었다.

http에서 https로 보내는 요청은 프로토콜이 달라도 도메인만 같으면 문제가 되지 않지만, https에서 http로 보내는 요청은 프로토콜이 다르기 때문에 CORS에러가 발생한다.

그렇다면 localhost를 https로 띄우면 된다! mkcert를 사용하면 localhost를 https로 동작시킬 수 있다.

 

됐고, 그냥 무시하는 방법은 없나?

그냥 개발 환경에서만 CORS 에러가 터지지만 않으면 되는데, 당장 바로 CORS 에러를 무시하고 개발할 수 있는 방법은 없을까?

크롬, 어디까지 실행해봤니?

보안을 싸그리 무시하고 크롬을 실행시킬 수 있는 방법이 있다는 걸 아는가?

1. 원하는 위치에 빈 디렉토리를 하나 만들어준다.
   mkdir chrome-no-cors
2. 다음의 명령어를 실행한다.
   open -na 'Google Chrome' --args --user-data-dir=${path} --disable-web-security

그럼 어마무시하게도 보안이 낮은 위험한 크롬창이 뜨게 된다. 그러니 정말 개발의 목적으로만 사용하도록,,,😇

나는 .zshrc에 단축어까지 저장해놨다.
alias chrome-no-cors="open -na 'Google Chrome' --args --user-data-dir=/Users/danmin/Workplace/chrome-no-cors --disable-web-security"