CORS란 무엇인가?

Об этом предложении

백엔드 면접 질문 - CORS란 무엇인가? hosts 파일을 수정했더니 CORS 에러가 사라진 이유 ❓ 면접 질문 CORS란 무엇이고 왜 발생하나요? 로컬 개발 중 hosts 파일을 수정했더니 CORS 에러가 해결된 경험이 있는데, 그 이유는 무엇일까요? CORS란? CORS(Cross-Origin Resource Sharing)는 서로 다른 Origin 간의 HTTP 요청을 브라우저가 허용할 수 있도록 서버가 명시하는 메커니즘 이다. CORS를 이해하려면 먼저 Same-Origin Policy(SOP) 를 알아야 한다. Same-Origin Policy란? 브라우저에는 기본적으로 다른 Origin에서 가져온 리소스에 대한 스크립트의 접근을 제한하는 보안 정책 이 있다. 이것을 Same-Origin Policy, 줄여서 SOP라고 한다. 예를 들어 프론트엔드가 http://localhost:3000 에서 실행되고 있고 API 서버가 http://localhost:8080 이라면 두 주소는 서로 다른 Origin이다. 따라서 브라우저에서 JavaScript로 API를 호출할 때 CORS 정책의 영향을 받는다. Origin이란? Origin은 다음 세 가지의 조합이다. Protocol + Host + Port 예를 들어 http://localhost:3000 이라면 Protocol = http Host = localhost Port = 3000 이다. 세 가지 중 하나라도 다르면 서로 다른 Origin이다. 같은 Origin과 다른 Origin 다음 두 주소를 비교해보자. http://localhost:3000 http://localhost:3000 Protocol, Host, Port가 모두 같으므로 같은 Origin이다. 반면 다음은 서로 다른 Origin이다. Port가 다른 경우 http://localhost:3000 http://localhost:8080 Port 3000 ≠ Port 8080 따라서 다른 Origin이다. Protocol이 다른 경우 http://localhost:3000 https://localhost:3000 http ≠ https 따라서 다른 Origin이다. Host가 다른 경우 http://localhost:3000 http://127.0.0.1:3000 둘 다 같은 PC를 가리킬 수 있지만 브라우저가 보는 Host 문자열이 다르기 때문에 Origin도 다르다. 즉, Origin 비교 = 실제 서버가 같은가? ❌ Origin 비교 = Protocol + Host + Port가 같은가? ⭕ 라고 이해하면 된다. CORS 에러는 왜 발생할까? 예를 들어 프론트엔드가 http://localhost:3000 에서 실행되고 있다고 해보자. 그리고 API 서버는 https://api.example.com 이다. 브라우저 입장에서는 http://localhost:3000 → https://api.example.com 이라는 Cross-Origin 요청이 발생한다. 서버가 해당 Origin의 접근을 허용한다면 응답에 CORS 관련 헤더를 포함한다. 예를 들어 Access-Control-Allow-Origin: http://localhost:3000 과 같은 응답이 올 수 있다. 브라우저는 이 정보를 보고 요청한 Origin = http://localhost:3000 서버가 허용한 Origin = http://localhost:3000 → 허용 이라고 판단한다. 반대로 서버가 해당 Origin을 허용하지 않았다면 브라우저가 응답을 JavaScript에 노출하지 않으며 개발자 도구에서는 CORS 관련 오류를 볼 수 있다. 로컬 개발 중 hosts 파일을 수정했더니 CORS 에러가 사라진 이유 실무에서 이런 상황이 발생할 수 있다. 서버가 허용한 Origin이 http://dev.example.com:3000 이라고 가정해보자. 그런데 개발자가 프론트엔드를 http://localhost:3000 으로 실행하고 있다. 브라우저가 보내는 Origin은 Origin: http://localhost:3000 이다. 하지만 서버가 허용한 것은 http://dev.example.com:3000 이다. 따라서 localhost ≠ dev.example.com 이므로 CORS 문제가 발생할 수 있다. 여기서 hosts 파일이 등장한다 hosts 파일은 특정 Hostname을 어떤 IP 주소로 해석할지 로컬 PC에서 지정할 수 있는 파일이다. 예를 들어 hosts 파일에 127.0.0.1 dev.example.com 을 추가했다고 해보자. 그러면 내 PC에서는 dev.example.com → 127.0.0.1 로 해석할 수 있다. 따라서 브라우저에서 http://dev.example.com:3000 으로 접속해도 실제 연결 대상은 내 로컬 PC가 될 수 있다. 하지만 브라우저가 보는 Host는 dev.example.com 이다. 따라서 Origin은 http://dev.example.com:3000 이 된다. 서버에서 허용한 Origin 역시 http://dev.example.com:3000 이라면 서로 일치한다. hosts 등록 → dev.example.com을 127.0.0.1로 해석 → dev.example.com으로 로컬 FE 접속 → Origin이 서버 허용 Origin과 일치 → CORS 통과 가능 즉 hosts 파일이 CORS 기능을 꺼버린 것이 아니다. hosts 파일은 이름을 IP로 해석하는 과정에 영향을 주고, 그 도메인으로 브라우저에 접속하면서 브라우저가 사용하는 Origin이 달라져 서버의 CORS 허용 설정과 일치했을 가능성이 있는 것이다. 실제 당시 원인이 정확히 이것이었는지는 당시 hosts 설정, 브라우저 접속 URL, 서버의 CORS 설정을 함께 확인해야 한다. hosts 파일과 DNS는 무슨 관계일까? 둘 다 도메인 이름 → IP 주소 를 찾는 것과 관련되어 있다. 예를 들어 api.example.com → 10.0.0.20 처럼 Hostname을 IP 주소로 해석해야 실제 네트워크 통신을 할 수 있다. hosts 파일에 해당 정보가 있다면 운영체제의 이름 해석 과정에서 그 정보를 사용할 수 있다. 따라서 개발 환경에서 127.0.0.1 dev.example.com 처럼 등록하면 실제 DNS 서버에 해당 개발용 도메인이 없어도 로컬 PC에서는 dev.example.com 을 127.0.0.1 로 해석하도록 구성할 수 있다. Preflight Request란? CORS를 공부하면 반드시 같이 나오는 것이 Preflight Request 이다. 브라우저가 Cross-Origin 요청을 바로 보내지 않고 먼저 서버에게 "이 요청 보내도 돼?" 라고 확인하는 과정이다. 이때 사용하는 HTTP Method가 OPTIONS 이다. 예를 들어 실제 요청이 PUT /users/1 Authorization: Bearer ... Content-Type: application/json 이라면 특정 조건에서는 브라우저가 먼저 OPTIONS 요청을 보낼 수 있다. Browser → OPTIONS 요청 → Server가 CORS 허용 여부 응답 → 허용되면 실제 요청 전송 서버에서는 다음과 같은 CORS 관련 응답 헤더를 반환할 수 있다. Access-Control-Allow-Origin: https://frontend.example.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Authorization, Content-Type 브라우저가 이를 확인한 후 실제 요청을 보낼지 결정한다. 모든 CORS 요청에서 OPTIONS가 발생할까? 아니다. CORS 요청이라고 해서 무조건 Preflight가 발생하는 것은 아니다. 일정 조건을 만족하는 Simple Request 는 Preflight 없이 실제 요청이 바로 전송될 수 있다. 반대로 특정 Method, Header, Content-Type 등을 사용하는 요청은 Preflight가 필요할 수 있다. 따라서 CORS 요청 = 무조건 OPTIONS 요청 ❌ 이다. CORS 에러가 발생하면 API 요청 자체가 서버에 안 들어간 걸까? 이것도 반드시 구분해야 한다. Preflight에서 실패한 경우 Browser → OPTIONS → CORS 확인 실패 → 실제 요청 전송 안 함 이 경우 실제 API 요청이 서버까지 가지 않을 수 있다. 실제 요청 후 CORS에서 차단된 경우 경우에 따라서는 Browser → 실제 요청 → Server 처리 → Response 반환 → Browser가 CORS 정책 때문에 응답을 JavaScript에 노출하지 않음 이 될 수도 있다. 따라서 "CORS 에러니까 서버에 요청 자체가 안 들어갔다." 라고 단정하면 안 된다. Postman에서는 되는데 브라우저에서는 왜 안 될까? 면접에서 자주 나오는 질문이다. 예를 들어 Postman → API 성공 Browser → CORS Error 가 발생할 수 있다. 그 이유는 CORS가 브라우저의 Same-Origin Policy와 관련된 보안 메커니즘 이기 때문이다. 일반적인 Postman이나 curl 같은 API 클라이언트는 브라우저와 동일한 Same-Origin Policy를 강제하지 않는다. 따라서 Postman/curl → HTTP 요청 → 서버 응답 확인 Browser → HTTP 요청 + Origin/CORS 정책 확인 → 허용되지 않으면 JavaScript의 응답 접근 제한 이라는 차이가 생긴다. 그래서 "Postman에서 성공했으니까 CORS 문제는 아니다." 라고 판단해서는 안 된다. Spring Boot에서는 CORS를 어떻게 설정할까? Spring MVC에서는 전역 CORS 설정을 만들 수 있다. 예를 들어 @Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOrigins("https://frontend.example.com") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*"); } } 특정 Controller에만 적용하려면 @CrossOrigin 을 사용할 수도 있다. @CrossOrigin(origins = "https://frontend.example.com") @RestController public class UserController { } Spring Security를 사용하는 프로젝트라면 CORS 처리가 Security Filter Chain과 어떤 순서로 동작하는지도 함께 확인해야 한다. Access-Control-Allow-Origin: * 이면 다 해결되는 것 아닌가? 개발 중 CORS 에러가 발생하면 Access-Control-Allow-Origin: * 로 설정하고 싶을 수 있다. 하지만 무조건 * 로 허용하는 것은 적절하지 않다. 특히 Credential을 포함하는 CORS 요청에서는 Access-Control-Allow-Credentials: true 와 함께 Access-Control-Allow-Origin: * 를 사용할 수 없으며, 허용할 Origin을 명시적으로 설정해야 한다. 운영 환경에서는 필요한 Origin만 허용하는 것이 기본적인 방향이다. CORS와 CSRF는 같은 것일까? 둘은 서로 다른 개념이다. CORS 다른 Origin의 JavaScript가 응답에 접근할 수 있는가? 와 관련된 브라우저의 Cross-Origin 제어 메커니즘이다. CSRF 사용자가 로그인되어 있다는 점을 이용해 공격자가 사용자의 의도와 다른 요청을 보내게 만드는 공격 과 관련된다. 따라서 CORS = Cross-Origin 접근 제어 CSRF = 사용자의 인증 상태를 악용한 요청 위조 공격 으로 구분해야 한다. CORS를 설정했다고 CSRF가 자동으로 해결되는 것도 아니다. 실무 장애 확인 방법 브라우저에서 CORS 문제가 발생했다면 단순히 에러 메시지만 보지 말고 개발자 도구의 Network 탭을 확인하는 것이 중요하다. 우선 다음 흐름으로 확인할 수 있다. 현재 페이지 Origin 확인 → 요청 URL 확인 → OPTIONS 존재 여부 확인 → OPTIONS 응답 상태 확인 → CORS 응답 Header 확인 → 실제 API 요청 여부 확인 특히 다음 값을 비교한다. 브라우저 Origin 서버의 Access-Control-Allow-Origin 그리고 Preflight가 있다면 다음도 확인한다. Access-Control-Allow-Methods Access-Control-Allow-Headers Access-Control-Allow-Credentials 면접에서 나올 수 있는 추가 질문 CORS란 무엇인가요? Same-Origin Policy란 무엇인가요? Origin을 구성하는 요소는 무엇인가요? localhost 와 127.0.0.1 은 같은 Origin인가요? Port만 달라도 다른 Origin인가요? CORS는 브라우저와 서버 중 어디에서 검사하나요? Postman에서는 되는데 브라우저에서 CORS 에러가 발생하는 이유는 무엇인가요? Preflight Request란 무엇인가요? 왜 OPTIONS 요청을 보내나요? 모든 CORS 요청이 Preflight를 보내나요? CORS 에러가 발생하면 실제 API 요청은 서버에 전달되지 않은 건가요? Access-Control-Allow-Origin 은 무엇인가요? Access-Control-Allow-Credentials 는 무엇인가요? hosts 파일을 수정했더니 CORS 문제가 해결된 이유는 무엇인가요? CORS와 CSRF의 차이는 무엇인가요? 핵심 정리 개념 설명 Origin Protocol + Host + Port SOP 다른 Origin의 리소스에 대한 스크립트 접근을 제한하는 브라우저 보안 정책 CORS 서버가 허용하는 Cross-Origin 접근을 브라우저에 알려주는 메커니즘 Preflight 실제 요청 전에 OPTIONS로 허용 여부를 확인 Access-Control-Allow-Origin 서버가 허용할 Origin을 나타내는 응답 헤더 hosts Hostname을 특정 IP로 해석하도록 로컬에서 설정 가능 localhost / 127.0.0.1 같은 PC를 가리킬 수 있어도 Host가 다르므로 Origin은 다름 Postman / curl 일반적으로 브라우저의 SOP/CORS 제약을 동일하게 적용하지 않음 면접 답변 CORS는 서로 다른 Origin 간의 요청을 허용하기 위해 서버가 허용 범위를 응답 헤더로 알려주고 브라우저가 이를 검사하는 메커니즘입니다. Origin은 Protocol, Host, Port의 조합이며 하나라도 다르면 다른 Origin으로 판단됩니다. 실무에서 로컬 개발 중 hosts 파일을 수정한 뒤 CORS 문제가 해결된 경험이 있는데, hosts 파일 자체가 CORS를 해제한 것은 아닙니다. 예를 들어 서버가 dev.example.com 이라는 Origin을 허용하고 있는데 프론트엔드를 localhost 로 접속하고 있었다면 Origin이 일치하지 않습니다. hosts 파일에 127.0.0.1 dev.example.com 을 등록하고 해당 도메인으로 로컬 프론트엔드에 접속하면 브라우저의 Origin이 서버에서 허용한 Origin과 일치하면서 CORS 문제가 해결될 수 있습니다. 또한 CORS 문제를 확인할 때는 브라우저 개발자 도구에서 Origin과 Access-Control-Allow-Origin 을 비교하고, Preflight가 발생했다면 OPTIONS 요청과 Access-Control-Allow-Methods , Access-Control-Allow-Headers 등의 응답도 함께 확인합니다.