서론
프론트앤드 개발팀원과 백엔드 서버 API 연계 작업을 하던 중, 악명높은 CORS 에러에 직면했다. CORS 이슈가 무엇이고, 해결 과정에 대해 기록하고자 한다.
본론
CORS란 ❓
CORS(Cross Origin Resource Sharing)의 약자로, '교차 출처 리소스 공유'를 의미한다.
즉, CORS란 도메인이 다른 서버끼리 리소스를 주고 받을 시에 보안을 위해 설정된 정책이다.
Cross-Origin 판단 기준
두 개의 출처가 같다고 판단하는 로직은, 두 URL의 구성 요소 중 Protocol, Host, Port 이 3가지가 동일해야한다.
예시)
- http://www.domain.com:8080 -> 다른 출처
- https://www.domainA.com:3000 -> 당연히 다른 출처
CORS 정책 검사
위를 판단하는 주체는 브라우저에 구현되어 있는 스펙이다. 즉, 우리가 CORS 정책을 위반하는 리소스를 구성해서 요청하더라도 우리의 서버는 정상적으로 응답을 하지만, 브라우저는 이 응답을 분석해서 CORS 정책 위반이라고 판단해 응답을 버리는 순서로 동작한다.
CORS 트러블 슈팅 관련 글이 많은 이유
해당 이유는 웹의 발달과 관련이 깊다. 예전에는 FE, BE를 따로 구성하지 않고 한 번에 구성해서 모든 처리가 같은 도메인 안에서 가능했다. 그러므로, 다른 출처로 요청을 보내는게 의심스러운 행위로 보일 수 밖에 없었다고 한다. 시간이 지나 이제는 클라이언트에서 API를 직접 호출하는 방식이 자연스러워지고, 클라이언트와 API가 다른 도메인에 있는 경우가 많아서 CORS 정책이 생겼다.
출처가 다르더라도, 요청과 응답을 주고받을 수 있도록 서버에 리소스 호출이 허용된 출처(Origin)을 명시해 주는 방식으로 말이다.
스프링부트에서 전역으로 리소스 호출이 허용되는 출처를 명시해줄 수 있다.
프로젝트에서의 이슈 발생
현재 FE, BE는 각각 Oracle Cloud, AWS에 배포되어있는 상태다. 쿠키의 sameSite 정책 즉, 같은 도메인에서 쿠키가 교환되어야하기 때문에, 이를 위해 FE, BE 서버 각각에 SSL 인증을 적용했다. - https://velog.io/@sung_c/DevOps-EC2-DNS-%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%93%B1%EB%A1%9D-%EB%B0%8F-SSLACM-%EC%A0%81%EC%9A%A9
그런데, SSL인증과 CORS 설정하고, FE에서도 credential 정책을 설정해주었는데, 클라이언트가 서버로부터 쿠키 응답을 받지 못했다.
- React
바로바로, 아까 이야기한 쿠키의 samesite 정책에서 옵션을 none으로 줘서 해결한다. 기존의 스프링에서 제공하는 cookie 객체는 samesite 옵션을 줄 수가 없어서, responseCookie 객체로 코드를 리팩토링했다.
여기서 끝이 아니다. 해당 프로젝트에서는 Spring security로 인증, 인가를 처리하고 있다. 위의 cors 전역 설정은 HttpRequest가 Controller에 들어오고나서의 설정이여서 계속 500 에러를 리턴받았다.
따라서, filter단에서 cors 설정을 해줘야 한다.
결론
cors이 생긴 이유, 해결 방법 그리고 쿠키 정책에 대해 알 수 있는 트러블 슈팅 경험이었다. 단순히 문제를 해결하는 것을 넘어, 왜? 라는 관점에서 접근하니 아~ 이래서 이랬구나가 이해되는 부분이었다.
