CORS

CORS(Cross Origin Resource Sharing)

웹 개발자라면 한번쯤은 CORS와 관련하여 콘솔에 뜨는 빨간 글씨의 에러를 본적이 있을 것이다.

하지만, CORS 정책이 괜히 존재하는 것이 아니다. 브라우저의 보안과 관련하여 아주 중요한 역할을 수행하기 때문이다.

 

 

Origin(출처) 란?

이는 URL, 도메인 등과 비슷해 보이지만 엄연히 의미가 다르다.

Origin은 url에서 프로토콜, 도메인, 포트 번호를 합친 부분을 의미한다.

ex) URL : https://naver.com:80/posts/123456?data=789#abc

여기서 프로토콜에 해당하는 부분은 https:// 이고, 도메인에 해당하는 부분은naver.com이며, 포트 번호에 해당하는 부분은 :80이다. 따라서 Origin은 https://naver.com:80이다. 참고로, window.location.origin 명령어를 사용하면 현재 접속중인 웹사이트의 Origin을 알아낼 수 있다.

 

Origin :  https://naver.com:80

 

 

 

SOP와 CORS의 관계

SOP(Same Origin Policy)

• "동일한 출처에서만 리소스를 공유할 수 있다" 라는 법률
• 같은 origin끼리 송수신한다.
• 동일 출처(Same Origin) 서버에 있는 리소스는 자유로이 가져올 수 있지만, 다른 출처(Cross Origin) 서버에 있는 이미지나 유튜브 영상같은 리소스는 상호작용이 불가능
• 서로 다른 두 Application에서 SOP가 없다면 해커의 공격을 받을 수 있는 위험한 환경이 되어버림

SOP가 없다면??

악의적인 마음을 품은 해커가 자신의 웹사이트를 구축해놓고, 이 웹사이트를 가리키는 링크를 담은 메일을 사용자에게 보내는 것이다. 그리고 이 사용자는 A라는 웹사이트에 로그인이 되어 있어서 브라우저 단에 인증 정보가 존재한다고 해보자.
만약 그 사용자가 실수로 해당 링크를 클릭하여 해커의 웹사이트에 접속하면, 해커가 심어둔 JavaScript 코드가 실행되어 자기도 모르게 A 웹사이트로 개인 정보를 조회하는 API 요청을 보낼 것이다. 이 사용자의 브라우저 단에는 인증 정보가 존재하기 때문에, 이것이 해당 요청에 함께 실어서 전송되면 서버는 인증된 요청이라 생각하여 개인 정보를 응답해줄 것이다. 그러고 나면 그 개인 정보를 해커가 빼돌릴 수 있게 된다.
(이것이 바로 CSRF 공격이다.)

하지만 SOP가 존재한다면 이러한 문제(CSRF)를 어느 정도 예방할 수 있다. 해커가 구축한 웹사이트와 A 웹사이트는 당연히 Origin이 다르기 떄문에, 해커의 웹사이트에서 A웹사이트로 API 요청을 보낼 수 없기 때문이다. 따라서 SOP는 브라우저의 아주 기본적인 보안 정책으로서 기능한다.

 

CORS

• 교차 출처 리소스 공유
• 추가 HTTP 헤더를 사용하여, 한 출처에서 실행중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근 할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제
• 포트만 달라도 오리진 에러(프록시서버의 경우) => White list(허용하는 오리진 주소 목록)
• 민감한 정보일때는 Access Control Allow Credentials를 true 프론트, 백 둘 다 설정해줘야 한다.

 

CORS 동작 원리

CORS의 기본적인 동작 원리는 단순하다. 브라우저는 다른 Origin으로 요청을 보낼때 Origin 헤더에 자신의 Origin을 설정하고, 서버로부터 응답을 받으면 응답의 Access Control Allow Origin 헤더에 설정된 Origin의 목록에 요청의 Origin 헤더 값이 포함되는지 검사하는것 뿐이다. 즉 , CORS 요청을 위해서는 서버에서의 응답의 Access Control Allow Origin 헤더에 허용되는 Origin의 목록 혹은 와일드카드(*)를 설정해주면 된다. 이것이 기본적인 CORS정책이다.
(와일드카드(*)는 모든 Origin을 허용한다는 것을 의미하는 특수 기호이다.)

 

---

출처

https://it-eldorado.tistory.com/163