CORS 설정이 불필요한 서버 아키텍처 (Same-Origin, @Profile)

 

3차 데모데이를 앞둔 현 시점 기준,
줍줍 팀의 서버 아키텍처와 고민했던 지점을 공유합니다.

 

 

3차 데모데이 시점, 줍줍의 서버 아키텍처

---

3차 데모데이 줍줍 서버 아키텍처

 

개발환경, 운영환경에 대해서만 나누어 구성을 완료하였습니다.
Github Actions를 이용해 CI를 구성하였고,
Git Flow 브랜치 전략을 채택하였으며,
develop, main 브랜치에 merge가 발생할 경우, 
Jenkins에서 이 이벤트를 받아 테스트, 빌드를 수행하여
각각 개발, 운영 환경으로 배포하게 구성했습니다.

추후 운영 환경 백엔드 WAS에 대한 로드 밸런싱을 위해
추가적인 NGINX가 도입될 수도 있을 것 같습니다.

 

 

 

CORS 설정이 불필요한 아키텍처

---

위와 같은 구성을 수행하며 가장 아쉬웠던 것은, 가장 앞에 있는 하나의 NGINX 였습니다.
백엔드 환경과 프론트엔드 환경의 NGINX가 분리되지 않은 기분이었기 때문입니다.

그럼에도 불구하고 현 설계를 선택한 이유는 Same-Origin을 유지하기 위해서였습니다.

Same-Origin 내 요청을 주고받는 네이버 지도

위 이미지는 네이버 지도에 처음 접속했을 때의 화면입니다.

map.naver.com/v5 라는 주소에 접속하였고,
북마크를 가져오기 위한 API를 호출하는 주소가 map.naver.com/v5/api/bookmark 입니다.

프로토콜, 호스트, 포트가 동일하여 Same-Origin을 유지하였고,
그 결과 사용자가 보기에도 안전하고 자연스러운 요청 주소임을 알 수 있고,
백엔드 서버에 CORS 관련된 설정을 하지 않아도 되는 상태입니다.

 

 

 

Same-Origin을 준수하는 줍줍

---

줍줍

줍줍은 API로 전달되는 요청을 NGINX가 path로 구분하여 요청을 전달해줍니다.
즉, /api 로 path가 시작할 경우, 해당 요청을 백엔드 WAS로 전달해주는 것입니다.

다만 이 과정에서 앞쪽에 명시되는 프로토콜, 호스트, 포트는 동일하므로
Same-Origin을 만족하게 됩니다. 

크롬 브라우저에서는 85버전부터 strict-origin-when-cross-origin 옵션을
Referrer Policy의 기본값으로 설정하였습니다.
이를 통해 더욱 높은 수준의 보안을 제공해준다고 설명하고 있습니다.
관련 자세한 내용은 아래를 참고하시면 좋을 것 같습니다.

https://developer.chrome.com/blog/referrer-policy-new-chrome-default/

 

 

 

로컬 및 개발 환경에서만 CORS 허용하기

---

@Profile({"local", "dev"})
@Configuration
public class CorsConfig implements WebMvcConfigurer {
    public static final String ALLOWED_METHOD_NAMES = "GET,HEAD,POST,PUT,DELETE,TRACE,OPTIONS,PATCH";

    @Override
    public void addCorsMappings(final CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedMethods(ALLOWED_METHOD_NAMES.split(","))
                .exposedHeaders(HttpHeaders.LOCATION);
    }
}

 

Same-Origin을 유지하도록 구성했으니, 개발 초기에 설정했던 CORS 설정을
바로 지우고 싶기도 했는데요, 추가적인 요구사항이 발생했습니다.

인증, 인가와 관련된 로직들을 개발하고 있을 때,
프론트엔드에서는 로컬 개발환경에서 인증, 인가를 테스트할 필요성이 있었습니다.

한편 Slack 정책 상 OAuth 로그인의 결과로 주어지는 code를 
https가 적용되지 않은 서버에게 응답하지 않았습니다.
code는 Query Parameter로 전달되기 때문에 https에서의 통신만 허용합니다.

그 결과, 프론트엔드 로컬 개발환경에서도, 백엔드는 개발환경의 WAS를 사용해야 했습니다.

따라서 프로파일에 따른 CORS 설정이 가능해야 했는데요,
@Profile 애너테이션을 이용해 local, dev 프로파일에만 CORS 설정이 적용되도록 구성했습니다.

관련 테스트한 영상을 캡쳐해봤습니다

https://www.youtube.com/watch?v=7GaXw-d4fMs 

프로파일에 따른 CORS 설정

 

 

 

Same-Origin은 과연 얼마나 가치있는가

---

이러한 구성에 대해 현재로선 만족하고 있지만, 아쉬움이 있는 것도 사실입니다.

하나의 프론트컨트롤러와 같은 NGINX하나를 두고,
그 안에 백엔드와 프론트엔드가 함께 구성된다면
완전히 분리되진 않은 모습인데.. 분리하고 싶은데.. 하는 생각이 드는 거죠.

하지만 그 분리가 얼마나 의미있는지, 
실제적인 유익은 무엇이 있을지 등에 대해서 역시 흐릿합니다.

한편, 현재 구성이 Same-Origin 유지 및 CORS 설정 불필요 등의 장점으로 채택됐는데,
과연 Same-Origin은 얼마나 가치있는 것인가 라는 지점에 대해서도
고민이 필요한 것 같습니다.

계속해서 고민하고 학습해가는 과정속에 서버 아키텍처가 앞으로 어떻게 바뀌게 될까요?

Same-Origin과 Same-Site의 차이가 궁금하신 분들은 아래 링크가 도움이 되실 것 같습니다.
https://web.dev/same-site-same-origin/