이미 장성호님이 훌륭한 답변을 주셨지만, 애써 첨언합니다. 같은 내용이라도, 또 여러 자료(?)로 접하면 이해도가 높아지기도 한다는 기대를 해봅니다. 게다가, 엊그제 이 질문을 보았는데, 어딘지 모르게 고민한 흔적도 느껴지고, 어느 부분을 알고 싶은지도 꽤 명료한 것 같아서, 적절한 답변을 하고 싶다는 느낌이 들었습니다. 그런데?! 제가 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 미들웨어/필터 등으로 찾아보시면 어떨까 합니다.