교차출처 관련 백엔드 설정

CORS 에러가 발생하는 상황에서도 서버는 작업을 수행하는 것은 잘 모르겠지만, 혹여나 그런 상황이 발생한다면 무의미한 작업을 처리하는 것보다는 미리 방지하는 게 맞다고 생각합니다. 작업이 실패할 것이 명확함에도 귀중한 서버 자원을 낭비할 이유는 없으니까요. 서버 입장에서 궁금하신 것 같아보이십니다. 아는 선에서 추천드리는 키워드는 Web Server, Web Application Server 두 가지의 차이점을 알아보면 좋을 것 같습니다. 또는 Proxy Server를 활용하여 서버 대 서버 통신 환경을 조성해서, CORS라는 브라우저의 규약을 피할 수도 있겠네요. 코드 수준에서는 어떠한 언어 및 프레임워크를 사용하시는 지는 모르겠으나, 대표적으로는 js의 cors 라이브러리나 spring WebMvcConfigurer 인터페이스의 addCorsMappings를 살펴보시면 좋을 것 같네요. 아니면 아예 nginx 같은 걸 찾아보시는 것도 추천드립니다. 개인적인 경험으로는 CORS와 같이 사전에 Request를 검증하는 것은 다음과 같은 선택지가 있었습니다. 1. Nginx와 같은 Web Server에서 미리 CORS 설정을 한다. 2. ExpressJS, Spring과 같은 Web Application Server(WAS)에서 interceptor를 통해 CORS 설정을 한다. 1번은 WAS까지 가지 않아도 Web Server에서 미리 출처를 검사해서, 더 빠르면서도 WAS의 자원을 낭비하지 않아도 된다는 장점이 있었습니다. 다만 이런 Web Server의 코드는 Github와 같이 온라인에 올리기에는 민감한 정보가 많아서, 각 서버 컴퓨터 인스턴스마다 private하게 구현해야하는 불편함이 있었어요. 반대로 2번은 WAS의 자원을 사용하지만, 코드 관리에 더 용이했었습니다. 최근에 CORS를 직접적으로 건드릴 때 1번과 2번 중 고민이 많았는데, 코드 관리의 이점을 고려해서 2번을 택했었습니다. 과거 구글링 도중 Gateway나 Load balance에서도 CORS 관련해서 잠깐 스쳐지나갔던 것 같은데, 자세히는 모르기 때문에 언급만 드립니다ㅎㅎ 마지막으로 최근 학부 프로젝트에서 구현했던 js cors 코드입니다. 도움이 되었으면 좋겠네요 ☺️ https://github.com/ajou-only-five/server/blob/main/src/utils/cors.js

이미 장성호님이 훌륭한 답변을 주셨지만, 애써 첨언합니다. 같은 내용이라도, 또 여러 자료(?)로 접하면 이해도가 높아지기도 한다는 기대를 해봅니다. 게다가, 엊그제 이 질문을 보았는데, 어딘지 모르게 고민한 흔적도 느껴지고, 어느 부분을 알고 싶은지도 꽤 명료한 것 같아서, 적절한 답변을 하고 싶다는 느낌이 들었습니다. 그런데?! 제가 CORS를 잘 알고 있는 게 아니었던지, 막상 설명하려니까 답변이 써지지 않더군요. 흔히, 남에게 설명할 정도가 아니라면 제대로 이해한 게 아니라고 하는데, 제가 딱 그 경우였나 봅니다. 그래서 질문자님 덕분에, CORS 자료를 다시 한 번 읽어보았습니다. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS 암튼, 제가 질문을 잘 이해한 것이 맞는지 확인해보겠습니다. CORS (+preflight) 검증을 브라우저에서 한다는 것은 알겠는데, 서버에서도, 헤더 설정 말고도 별도의 검증을 하느냐의 궁금증인 것 같습니다. CORS를 다루는 서버 입장에서는 Allow-Origin등의 응답헤더를 내려줄 테고, 클라이언트는 자신의 요청에 Origin 헤더를 붙여서 보낼텐데요, 클라이언트 입장에서는 서버가 내려준 Allow-Origin에 내가 포함되는지를 확인해서 더 진행할지 말지를 거를 수 있고, 반대로 서버 입장에서는 클라이언트가 요청에 담아서 보낸 Origin의 내용으로 거를 수 있겠습니다. 보통의 앞단의 웹서버나, 클라우드환경의 API게이트웨이나 L7로드밸런서등이 이미 CORS 설정을 처리해주는 경우가 많기 때문에, 이런 서비스들이 CORS를 딱 처리해주고 있다면, 내가 다루는 백엔드 웹서비스 입장에서는 크게 신경쓰지 않고 처리하게 될 터입니다. 이미 CORS 검증을 통과한 요청만 내 백엔드로 넘어오는 거죠. 어떠한 이유로, 더 앞단에서는 CORS를 신경쓰지 않고, 내가 개발하는 웹서비스 백엔드 입장에서 CORS를 직접 처리하게 된다고 하더라도, 보통의 웹프레임워크가 CORS를 다루는 레이어를 따로 두고 있기 때문에, 역시 해당 설정을 연결짓고 빠지겠지요. 웹 프레임워크에 따라 부르는 이름이 다르겠지만, 보통 필터나 미들웨어라고 부릅니다. corsMiddleware, corsFilter뭐 이런 식의 모듈/함수 들을 붙이는 식일 겁니다. 해당 미들웨어가 정상적으로 구현했다면, Origin이 내가 허용한 경우가 아니라면, 해당 엔드포인트에 대한 처리를, 그러니까, 백엔드 개발자가 구현한 처리부까지 실행을 넘기지 않고, 끝내버릴 것입니다. 마치 브라우저가, 그 뒤의 요청을 보내지도 않거나, 아니면 헤더만 보고 그 뒤 진행을 잘라버리는 것 처럼요. 그러니까, 질문자님이 궁금하신 것은, 본인이 쓰시는 웹프레임워크에서의 CORS 미들웨어/필터 등으로 찾아보시면 어떨까 합니다.