일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- vibe coding
- 리액트
- hydration warning
- high order component
- hydration 경고
- javascript
- 주니어 프론트엔드
- 코테
- llm 활용
- next.js 13
- 자바스크립트
- 회고
- 프론트엔드
- 코딩테스트
- react vs nextjs
- 실무에서의 접근성
- 바이브 코딩
- 택배 상자 꺼내기
- 웹 접근성 고려
- 넥스트
- 주니어 개발자
- 회고록
- next.js
- augmented coding
- 프로그래머스
- 개발자
- 증강 코딩
- react
- shallowequals
- Next
- Today
- Total
쉽고, 재밌게 정리하고 기록하자
프론트엔드... 너도 CORS 에러 해결할 수 있어..!😉 본문
현재 실전프로젝트를 개발하는 도중에 Log in 시 CORS 에러가 발생해 백엔드 쪽에서 해결해주길 기다리다가
혹시 프론트 쪽에서도 CORS 에러를 처리할 수 있을까? 라는 생각이 들어서 검색을 통해 CORS에러에 대한
오해와 프론트엔드쪽에서 CORS를 해결할 수 있다는 것을 보고 직접 적용한 것들을 적어보려고 합니다!😉
💡CORS(Cross Origin Resource Sharing) 란?
MDN 공식문서에 따르면, CORS는 다음과 같이 정의됩니다.
교차 출처 리소스 공유 (Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여,
한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.
확실히 이렇게 설명하면 어려운것 같으니 조금 더 쉽게 말하자면 개발 단계에서 프론트(브라우저)에서 백(서버)으로 API 요청을 보낼 때 프론트와 백의 서로 다른 Origin간의 리소스 교환을 말합니다. (도메인과 오리진의 차이점)
💡CORS에 대한 몇가지 오해..!
오해 1. CORS 에러는 서버가 보내느 에러다?!
CORS는 CSRF 라고 불리는 브라우저 취약점 공격으로부터 브라우저 사용자를 보호하기 위해 만든 기능이다.
HTTP 표준 스펙에 포함되어 있고, CORS 관련 기능의 구현은 브라우저 개발사에게 책임이 있다.
웹 표준 기술을 따르는 정상적이고 일반적인 브라우저라면 CORS 역시 표준 스펙에 맞게 구현되어 있다.
일반적인 브라우저 ➡️ 익스플로러를 제외한 크롬, 사파리, 파이어폭스, 오페라 등을 말합니다.
평범한 일반 사용자가 손쉽게 다운로드 받아서 쓸 수 있는 종류의 브라우저들입니디.
CORS 정책은 서버에 저장되어 있으며, 저장된 CORS 정책을 브라우저에게 보내주는 일을 서버가 맡고 있긴 하지만
그 CORS 정책을 보내달라고 서버에게 요청하는건 브.라.우.저 이다!
- 브라우저에서 http요청이 발생하면 브라우저는 발생한 http 요청이 CORS검증을 해야하는 상황인지 판단
- 보안 청책상 검증이 필요한 상황에 해당하면 CORS 검증을 서버에 요청. (Prefight Request)
- 서버에게서 응답받은 CORS 검증 요청 결과에 따라 브라우저는 발생했던 http 요청을 취소시켜버리고 에러를 뱉는다!
즉, CORS 에러는 브라우저에서 발생한다!
오해 2. 외부 공격으로부터 서버를 보호하기 위해 특정 도메인/IP 이외의 경로로 들어오는 요청을 차단하는게 CORS에러이다?!
CORS는 보안정책중 하나이지만, 보호의 대상은 서버가 아니다.
CORS는 HTTP 요청 헤더 중에서 Origin 이라는 헤더와 관련되어 있다.
브라우저를 통하지 않은 서버간 통신일 경우 Origin 헤더는 자동으로 붙는게 아니다. 그렇다고 못 붙이냐 하면 그것도 아니다. 서버간 통신일 때 요청자 서버는 원하면 Origin 헤더를 안 넣어도 되고, 넣고 싶으면 Origin의 값으로 아무 문자열이나 마음대로 넣어서 보낼 수 있다. 즉 서버간 요청 상황에서 CORS정책은 보안상 의미를 가지지 않습니다.
서버가 특정 요청자에게만 요청을 허용해야 할 땐, 인증 토큰이나 보안키 등 더 확실하고 간단한 방법을 사용하면 된다.
오해 3. 프론트엔드에서 AJAX 요청을 보낼때 어떤 특별한 라이브러리를 사용하거나 어떤 설정을 잘 해서 요청한다면 CORS 문제를 해결할 수 있다?!
만일 어떤 라이브러리나 설정을 통해, CORS 에러를 우회할 수 있는 방법이 있다면, 그건 브라우저 보안 취약점입니다.
프론트엔드 소스코드로만 CORS 에러를 우회하는 방법은 없어야합니다.
💡CORS 에러 해결방법
상황에 따라 최선의 대처하는 방법은 다 다릅니다! (제 상황은 1,2번 실패 후 3번으로 진행하였습니다🥲)
1. 프론트엔드 개발서버 프록시 환경설정
Create-react-app
공식문서 : https://create-react-app.dev/docs/proxying-api-requests-in-development/
Proxying API Requests in Development | Create React App
Note: this feature is available with react-scripts@0.2.3 and higher.
create-react-app.dev
package.json 에 다음과 같은 코드를 추가합니다!
테스트를 하는동안 사용할 테스트용 api 서버의 도메인을 아래 코드의 http://my-api-server.com 라 써있는 부분에 대입해서 쓰세요!
저는 위의 방법을 이용하였지만 yarn start 과정에서
options.allowedHosts[0] should be a non-empty string. 라는 오류가 발생해 다음 방법으로 진행하였습니다!
2. http-proxy-middleware 모듈을 이용하기
공식문서 : https://create-react-app.dev/docs/proxying-api-requests-in-development/
const { createProxyMiddleware } = require('http-proxy-middleware');
module.exports = function(app) {
app.use(
'/api',
createProxyMiddleware({
target: 'http://localhost:5000',
changeOrigin: true,
})
);
};
위의 코드를 src 폴더안에 setProxy.js 라는 파일로 작성하면 리액트 서버에 프록시 서버를 도입할 수 있다고 합니다.
하지만 글쓴이는 현재 프로젝트를 typescript를 사용하고 있고 도메인 주소도 https 를 사용하여서 그런지 사용이 되지 않아서 다음 방법으로 넘어갔습니다(다음에 미들웨어를 이용해 사용해보도록 하겠습니😉)
3 직접 proxy 서버 만들기
이 방법은 위의 방법들이 통하지 않았을 때 할 수 있는 최후의 방법입니다.
모든 상황에 대해 완벽하게 맞춤 대응이 가능하지만 치명적인 단점이 하나 있다.
바로 백엔드를 만질 줄 알아야 한다는 것...
api 서버로부터 받아야 할 요청을 대신 요청해서 프론트엔드에 응답해주는 서버를 개발환경에 만들어 두고,
cors 정책을 내 맘대로 주무른 뒤, 개발과정동안 api요청을 거기로 보내면 됩니다!
백엔드를 만질 줄 모르는 나로써는 nodeJS로 만든 간단한 프록시 서버를 만든 깃허브를 찾아 사용하였습니다.
https://github.com/joonseokhu/api-proxy-server
1. Proxy Sever의 proxy.config.json 작성
2. 작업중인 프론트엔드 instance 폴더에 작성
위의 깃허브에 들어가 설명에 따라 차근차근 따라하면 쉽게 구현할 수 있을거라고 생각합니다!😉
공식 문서나 mdn도 보고 많은 블로그들도 참고하며 보았는데 그중에 정말 와닿는 글을 보았습니다.
하지 말아야 할 해결 방법들
백엔드에게, 항상 허용으로 CORS 정책 바꿔달라고 하기
"현관문 도어락을 매번 여는게 귀찮다고 아무도 도어락을 뜯어두고 살진 않는다." 라는 말을 보았는데
확실히 CORS 정책을 이해하게 되었습니다.
브라우저 보안기능이 비활성화된 커스텀 브라우저 사용해서 개발하기
cors를 비활성화해둔 브라우저를 쓰는 방법 역시 좋은 대처법이 아니다.
브라우저에서 cors를 비활성화 해서 프론트엔드에서 api를 붙이면 나는 cors 에러를 안 겪겠지만,
일반적인 브라우저를 쓰는 사람들에겐, 다시 말해 나를 제외한 모든 사람들에겐 여전히 에러가 나고 있는것입니다.
이번 프로젝트를 하면서 다시 한번 CORS에러에 대해 공부하고 서버쪽에 에러가 아니라는걸 알고
대처하며 해결을 할 수 있어 정말 좋은 경험이라고 생각합니다.😎
'study' 카테고리의 다른 글
[간단메모📝] Closer는 뭐라고 생각하시죠?!!🧐 (0) | 2022.12.31 |
---|---|
나혼자 볼 기술면접 질문 예시🥸 (0) | 2022.12.11 |
💾타입스크립트로 네이버 지도 구현해보기 (1) | 2022.11.21 |
🌸React Query를 알아보자 (0) | 2022.11.14 |
Recoil을 배워보자 (0) | 2022.11.06 |