브라우저 보안 정책

안녕하세요! 커널360 백엔드 2기 김민규 크루입니다.

이번 시간에는 브라우저 보안 정책에 대해 이야기해보겠습니다.

브라우저 보안 정책은 언제 처음 도입 되었을까요?

이는 1995년 Netscape 2.02. 버전에서 등장한 보안 정책, Same Origin Policy 에서 부터 시작됩니다.

◼️ Same Origin Policy

넷스케이프 네비게이터

출처 : https://en.wikipedia.org/wiki/Netscape_Navigator_2

1995년, 넷프케이프 네비게이터 브라우저에 새로운 스크립트 언어가 추가되었습니다.

동적으로 브라우저의 DOM에 접근하고, 내용을 수정할 수 있는 자바스크립트의 등장입니다.

출처 : https://ko.wikipedia.org/wiki/자바스크립트

당시 자바스크립트는 막강했습니다.

서로 다른 브라우저 탭에 저장된 쿠키를 획득할 수 있었고, 다른 DOM 객체에도 접근할 수 있었습니다.

예를 들면, 넷스케이프 2.0 브라우저는 자바스크립트 프로그램이 about:cache url을 통해 클라이언트의 모든 브라우저 히스토리 목록에 접근할 수 있습니다.

⚠️ Can one javascript domain access another’s DOM? YES
⚠️ Can one site access data from another site? YES
⚠️ Can one site send data to another site’s server? YES

이러한 기능을 막고자 1995년, 넷스케이프 2.02 버전에 하나의 보안책이 추가되었습니다.

바로 Same Origin Policy입니다.

출처 : http://ftp.lanet.lv/ftp/windows/www/netscape2.02/

JavaScript Security

Navigator version 2.02 and later automatically prevents scripts on one server from accessing properties of documents on a different server. This restriction prevents scripts from fetching private information such as directory structures or user session history.

출처 : http://rilievo.stereofot.it/teledidattica/javascript/jsref/intro.ht

Same Origin Policy 하에 모든 자바스크립트 요청의 출처는 동일해야 합니다.

여기서 같은 출처의 기준은 뭘까요?

참고 : Google I/O Web.dev

브라우저는 프로토콜, 호스트 네임, 포트까지 동일한 웹사이트를 ‘동일 출처’ 로 간주됩니다.

예를 들어, URL이 https://www.example.com:443/foo/bar 이면 ‘출처’는 https://www.example.com:443 입니다.

◼️ CORS Policy

시간이 흘러 브라우저 시장에서 MS의 인터넷 익스플로러가 주도권을 잡게 되었고, XmlHttpRequest API가 등장했습니다.

XmlHttpRequest API로 인해 브라우저는 페이지 로딩이 끝난 이후 동적으로 서버에 HTTP 요청을 할 수 있게 되었죠.

그러나 이는 동일 출처 정책 (SOP) 의 제한이 발생합니다. 따라서 교차 출처 허용 표준이 없던 시절엔, 이 문제를 우회적으로 해결해야 했습니다.

이후 2006년 5월 17일에 W3C는 access-control 명세 초안을 발표하여 크로스 도메인 이슈를 해결하는 표준을 만들기 위한 논의를 시작했는데, 이게 현재의 CORS 정책이 되었습니다.

“권한이 있다면, 출처가 달라도 접근 가능하도록 하자”

이는 서버가 허용한 교차 출처 목록이 없다는 의미입니다.

브라우저가 OPTION 으로 보낸 Preflight 요청으로 인해 발생한 CORS 정책 위반 메시지입니다.

브라우저가 본 요청에 앞서 보내는 OPTION 요청이 preflight 요청입니다.

만약 출처도 다르고(Origin) 교차 출처 허용(CORS)도 없다면, fetch 요청시 정책 위반 에러가 발생합니다.

프론트엔드 앱 서버와 API 서버 URL이 다른 경우, 해결 방법은 아래와 같습니다.

방법 1. 허용할 출처를 Preflight 응답에 서버가 명시한다.
방법 2. 프론트 / API의 Origin를 동일하게 맞춘다.
방법 3. 브라우저 보안 정책을 회피한다.
- Background Service Worker 를 이용한다. ( 크롬 확장 프로그램 개발 ) 출처 : Chrome Extension Development
- 들어오는 preflight 응답을 훔쳐서 조작한 뒤 브라우저에게 전달한다.
  - CORS Unblock Chrome Extension
- 보안 정책을 끈다
```
  ./google-chrome --diable-web-security
```