프록시 서버
: 브라우저 대신 외부 서버에 요청을 보내고 응답을 받는 역할을 대리 수행하는 서버.
브라우저 측에서 직접 외부 서버에 요청을 보내지 않고, 클라이언트와 동일한 origin의 프록시 서버를 통해 요청을 보내면 SOP의 제한을 피할 수 있다.
COR (Cross-Origin Resource Sharing)
: 서로 다른 출처라도 리소스 요청, 응답을 허용할 수 있도록 하는 정책
-
교차 출처 리소스 공유
-
도메인(Hostname): myshop.com
-
출처 (Origin): https://www.myshop.com
=> 출처가 다른 서버간의 리소스 공유 -
예전에는 프론트 , 백을 따로 구성하지 않아서 모든 처리가 같은 도메인 안에서 가능했다.
→ 시간이 지나면서 클라이언트에서 API를 직접 호출하는 방식이 당연해짐
→ 클라이언트와 API는 다른 도메인
=> CORS 정책이 생김 (출처가 다르더라고 요청과 응답을 주고 받을 수 있도록 서버에 리소스 호출이 허용된 출처를 명시)
CORS 에러 대응법
서버에서 Access-Control-Allow-Origin 응답 헤더 세팅하기
- 서버에서 Access-Control-Allow-Origin 헤더를 설정해서 요청을 수락할 출처를 명시적으로 지정할 수 있다.
- 해당 해더를 세팅하면 출처가 다르더라도 https://myshop.com 리소스 요청을 허용 가능하게 됨.
'Access-Control-Allow-Origin': <origin> | * // 보안 취약 * 설정 → 출처에 상관없이 리소스에 접근할 수 있는 와일드카드이기 때문에 보안에 취약해진다.
'Access-Control-Allow-Origin': https://myshop.com // 직접 허용할 출처 세팅 추천 프록시 서버 사용
: 프록시 서버를 사용하여 웹 애플리케이션에서 리소스로의 요청을 전달하는 방법
ex) 웹 어플리케이션 :http://example.com - 데이터 요청 -> http://api.example.com
웹 애플리케이션 → http://example.com/api/proxy → (서버 내부 요청) → http://api.example.com- 웹 애플리케이션 대신 같은 출처에 위치한 프락시 서버를 통해 API 요청을 중계하도록 구성한다.
→ 브라우저 입장에선 http://example.com에 요청한 것 처럼 보여서 CORS 검사 없이 응답 가능!
SOP
: 서로 다른 출처일 때 리소스 요청과 응답을 차단하는 정책
- SOP 부합 예시
실무 때 겪은 CORS ? 관련 에러
- 문제 상황 : 작년에 로봇의 실시간 데이터를 주고 받는 UI를 개발하는 프로젝트를 수행 하였는데, 로봇 내의 로컬 배포를 해야 하는 상황에서 cors 에러를 마주한 상황이 있었다.
노트북으로 로컬 배포한 페이지에 접속 했을 땐 사이트가 보였지만, 테블릿 or 다른 기기를 로봇 와이파이에 연결 후 접속 하였을 땐 CORS 에러로 사이트가 뜨지 않는 상황이 일어 났었다.
- 라이브러리 사용의 문제
- nginx의 존재는 알았지만 모르는 프레임워크를 깔아서 책임 질 수 있을까? 에 대한 고민으로 http-proxy-middleware 라는 패키지를 사용 했는데, 로컬용이라 배포했을 때 동작을 하지 않는다는 답변을 들었다. ( 정적 파일을 배포하면 프록시 기능은 사라지고 그냥 브라우저 요청만 남게 됨)
- 노트북에선 동일 출처로 인식하여 사용 가능 했음
- 테블릿 -> IP 주소: 포트 로 접속하여 다른 출처로 인식 -> 에러 발생
- 해결 방법 : nginx 사용
- nginx
- 정적파일 제공
- 프록시 서버 역할 가능
출처 :
매일메일 서비스 (질문 출처)
토스 - CORS(교차 출처 리소스 공유)
