CORS를 제대로 이해하기: 브라우저가 막는 것과 서버가 허용하는 것 빠른 답 CORS 오류는 서버 요청 자체가 실패했다기보다, 브라우저가 응답을 JavaScript에 노출하지 않았다는 뜻인 경우가 많습니다. Access-Control-Allow-Origin 은 클라이언트가 요청에 붙여 해결하는 헤더가 아니라 서버가 응답으로 내려줘야 하는 헤더입니다. 쿠키나 인증 정보를 포함하는 요청은 Access-Control-Allow-Origin: * 와 함께 쓸 수 없고, 클라이언트와 서버의 credentials 설정이 함께 맞아야 합니다. 디버깅할 때는 콘솔 메시지뿐 아니라 OPTIONS preflight 응답과 실제 요청의 응답 헤더를 나눠서 확인해야 합니다. 목차 흐름으로 보기 CORS가 필요한 배경 실제로 막히는 지점 서버 CORS 기준선 요청 코드에서 확인할 부분 디버깅과 운영 검증 품질 기준으로 보는 점검 순서 CORS와 CSRF의 차이 흐름으로 보기 흐름 다이어그램 브라우저에서 요청이 발생하면, 브라우저는 현재 페이지의 출처와 요청 대상의 출처를 비교합니다. 출처는 프로토콜, 호스트, 포트의 조합입니다. https://app.example.com 과 https://api.example.com 은 호스트가 다르므로 다른 출처이고, http://localhost:3000 과 http://localhost:8080 은 포트가 다르므로 다른 출처입니다. 출처가 다르면 브라우저는 동일 출처 정책을 기준으로 응답을 JavaScript에 보여줘도 되는지 판단합니다. 요청 자체가 서버까지 도달할 수는 있지만, 서버 응답에 올바른 CORS 헤더가 없으면 브라우저가 응답 본문과 일부 헤더를 코드에 숨깁니다. 요청 메서드나 헤더가 단순 요청 범위를 벗어나면 실제 요청 전에 OPTIONS preflight 요청이 먼저 나갑니다. 예를 들어 Content-Type: application/json 으로 POST 를 보내거나 Authorization 헤더를...