📖 CORS에 대해
CORS란?
(Cross-Origin Resource Sharing)
CORS는 웹 브라우저가 한 도메인에서 실행 중인 웹 어플리케이션이 다른 도메인에 있도록 허용하는 보안 메커니즘입니다.
기본적으로, 웹 브라우저는 보안상의 이유로 같은 출처(도메인, 프로토콜, 포트)에서만 리소스를 공유하는 Same-Origin Policy를 따릅니다. 하지만 CORS를 사용하면 서버가 특정 헤더를 설정하여 다른 출처에서의 요청을 허용할 수 있습니다.
주요 요소
- HTTP 헤더: 서버는 Access-Control-Allow-Origin 헤더를 사용하여 접근을 허용할 출처를 명시합니다.
- Preflight 요청: 복잡한 요청의 경우, 브라우저는 실제 요청을 보내기 전에 OPTIONS 메서드를 사용하여 사전 요청을 보내 서버가 이를 허용하는지 확인합니다.
- 보안 강화: 서버는 Access-Control-Allow-Methods와 Access-Control-Allow-Headers를 사용해 허용되는 HTTP 메서드와 헤더를 명시할 수 있습니다.
CORS이 나오게 된 배경
요즘엔 프론트엔드 레이어와 API 서버 레이어를 따로 구성하는 경우가 많은데, 웹 프론트엔드 사이드 따로, 서버 따로 둔다는 겁니다.
이런 경우에 보통 웹 프론트엔드에서 다른 도메인이 위치한 API 서버로 요청을 넣어야 하는 상황이 생깁니다.
이런 기능은 당연히 지원이 되어야 하는 거 아닌가? 라고 생각할 수도 있지만, 예전에는 당연한 게 아니었습니다.
원래는 도메인이 다르면 요청을 주고 받을 수 없게 하려는 게 웹 브라우저의 기본 정책이었음, 그러다가 여러 과정을 겪으면서 CORS란 방식을 통해 그걸 가능하게끔 풀어주게 됐습니다.
예전에는 이런 방식으로 흘러갔습니다.
유저가 웹 브라우저 주소창에 주소값을 입력 => 서버에서는 응답할 때 HTML 페이지를 반환 = 하나의 서버에서 비즈니스 로직과 HTML 페이지 빌드를 같이 하는 게 일반적
이걸 다시 말하면, 모든 게 당연하게도 같은 도메인에서 일어났다는 점.
중간에 웹사이트에서 서버로 js를 이용해서 추가 요청을 넣는다고 해도 어디까지나 같은 도메인에서 일어나는 일이었습니다.
예전에는 웹사이트에서 다른 서버로 요청을 날린다 하면 개인정보 유출, 피싱 등 보안상 악의적인 행동을 하는 걸로 의심을 했습니다.
그렇기 때문에 웹 브라우저에서는 같은 도메인이 아니면 요청 자체를 막는 선택을 하게 됐던 것입니다.
그런데 점점 웹사이트에서 할 수 있는 일이 많아졌음, 단순히 문서 제공하는 용도 X ➡️ 어플리케이션을 만들기 시작
그런 과도기적인 상황이 되다 보니, 기존 웹브라우저 보안 정책때문에 불편한 점들이 조금씩 생기기 시작했습니다.
예를 들어 날씨를 제공해주는 API 서버를 하나 예시로 들어보겠습니다.
브라우저를 이용하는 유저에게 날씨 편의기능을 제공하고 싶은데, 이럴 경우 어떻게 만들면 좋을까?
직접 구축한 웹서버에 날씨를 가져오는 라우트를 하나 추가하고, 그걸 부르면 날씨 API 서버에 다시 요청 ➡️ 날씨 정보 받아옴 ➡️ 웹사이트에 보여줄 수 있게 반환
이 방법도 괜찮긴 하나, 굳이 웹서버를 거칠 필요없이 웹사이트에서 바로 날씨 API 서버랑 통신하면 안 되나?? 라는 생각이 들게 됩니다.
그러나, 날씨 API와 웹사이트의 도메인이 다르다 보니 이런 식의 요청을 주고 받을 수가 없었습니다.
이러한 상황을 답답해하는 개발자들이 사용했던 방식 중 JSONP 라는 방식이 있었습니다.
HTML script 태그의 경우, 다른 도메인의 파일을 불러오는 게 가능했음. 원래는 이 스크립트 불러오라고 하는 기능을 리소스 요청을 주고 받는데 우회적으로 사용한 게 바로 이 JSONP였던 것입니다.
스크립트 불러오는 것처럼 실행을 하는데, 실제로는 서버에서 데이터 반환하는 용도로 사용했습니다.
창의적인 방식이긴 했지만, 웹브라우저 입장에선 우회적인 루트로 보안을 무력화 시키는 걸 계속 방치할 수는 없는 노릇이었으나, 버그로 판단하고 막아버리기엔 너무 많은 수요가 있기에 불가능했습니다.
그래서 이런 우회 루트 말고, 공식적인 루트를 열어줄테니 그걸 써라 해서 나온 것이 CORS
일반적으로 CORS 세팅을 직접할 일은 거의 없습니다. 웹프론트엔드에서는 요청 넣을 때 CORS 옵션만 넣어주면 요즘은 Request 헤더까지 알아서 다 넣어주기 때문
📖 기술면접 질문
5. 쿼리 스트링은 주로 어디에 사용하셨나요?
- 의도: 쿼리 스트링의 개념과 작동 방식에 대해 이해하고 있는지
- 답안)
쿼리 스트링을 주로 검색 기능을 구현할 때 자주 사용했습니다. 검색 결과에 대한 내용은 따로 페이지 주소 라우트에 따른 서버 사이드 렌더링이 필요하지 않기도 하고, 기존 페이지를 유지하면서도 화면이 바꼈음을 알려주기 위해 사용했습니다. 이렇게 검색 기능에 쿼리 스트링을 이용하면 URL이 바뀜에 따라 브라우저의 히스토리 스택에 쌓여서 뒤로 가기나 앞으로 가기에 수월할 뿐더러, 다른 사람에게 검색 결과를 공유할 때 쿼리 스트링이 들어간 URL을 공유하면 되기에 해당 URL로 접근할 경우에 원하는 결과를 얻을 수 있다는 장점이 있습니다.
6. 브라우저에 URL을 입력하면 일어나는 일에 대해 순서대로 설명해주세요.
- 의도: 기본적인 브라우저 작동 방식에 대해 이해하고 있는지
- 답안)
우리가 브라우저에 URL을 입력하면 일어나는 일을 단계별로 설명드리겠습니다. 네이버 주소인 naver.com을 주소창에 쳤다고 가정해보겠습니다. 브라우저는 URL에서 프로토콜, 도메인 이름, 경로 등을 분석하게 됩니다. 이후 브라우저는 도메인 이름을 IP 주소로 변환하고자 DNS, 즉 도메인 네임 서버에 요청을 보냅니다. 그럼 도메인 네임 서버는 도메인에 해당하는 IP 주소를 응답으로 보내줍니다. 복잡한 IP 주소가 나오게 됩니다. 그리고 브라우저는 TCP 네트워크 연결을 구축하여 해당 IP 주소를 가진 웹 서버에 접근하여 데이터를 요청합니다. 그러면 웹서버는 HTTP 응답을 브라우저에 보내고, 브라우저는 받아온 HTML CSS JS 코드를 화면에 렌더링하게 됩니다.
7. 정규 표현식을 사용해본 경험이 있으신가요?
- 의도: 개념을 알고 있는지
- 답안)
주로 유저의 인풋 데이터를 검증할 때 사용하곤 했습니다. 예를 들어 휴대폰 번호를 검증해야 할 때, 010-1234-5678 의 포맷이 맞는지 확인하기 위해 폼에서 제출하는 타이밍에 정규 표현식을 사용해 검증하곤 했습니다. 정규 표현식 자체가 외워서 만들기는 좀 어려워서
regexr.com같은 정규 표현식 테스트 도구를 사용해 만드는 편입니다.
8. 크로스 브라우징이 무엇인가요?
- 의도: 웹 브라우저 간 예외 처리가 필요하다는 점을 알고 있는지
- 답안)
크로스 브라우징에서 앞에 크로스는 보통 개발 업계에서 무언가의 '사이'를 뜻하곤 합니다. 그래서 크로스 브라우징을 지원한다는 말은 여러 브라우저 사이에 오류없이 같은 경험을 제공한다는 의미와 같습니다.
예를 들어 아이폰 유저가 웹을 테스트할 땐 문제가 안 생겼는데, 갤럭시 유저가 웹테스트를 진행할 땐 화면 레이아웃이 깨진다거나 하는 등 특정 CSS 속성이 크롬과 사파리 브라우저에서 다르게 작동하고 있기에 생기는 문제가 있습니다.
