CORS 제대로 설정하기 — 와일드카드(*) 대신 허용 도메인 명시하는 방법

1. CORS가 왜 자주 문제로 보일까

1) 브라우저가 요청을 막는 이유

웹 개발을 하다 보면 화면은 정상인데 API 호출만 실패하는 상황을 자주 만나게 됩니다. 이때 가장 먼저 떠올리는 개념이 바로 CORS설정입니다. CORS는 서로 다른 출처에서 보내는 요청, 즉 크로스오리진 요청을 브라우저가 어떻게 허용할지 정하는 방식입니다. 서버가 응답을 보내더라도 브라우저가 보안 규칙에 맞지 않으면 결과를 차단할 수 있습니다.

2) 단순한 연결 문제로 보이지만 사실은 보안 정책

겉으로는 “API가 안 된다”처럼 보여도 실제로는 브라우저의 기본 보안 정책과 연결된 경우가 많습니다. 특히 프론트엔드와 백엔드가 분리된 구조에서는 CORS설정이 빠지기 쉽고, 배포 후에야 문제가 드러나기도 합니다. 그래서 개발자들은 Access-Control-Allow-Origin 같은 헤더를 자주 확인하게 됩니다. 이 값이 어떻게 설정되느냐에 따라 API보안 수준도 달라질 수 있습니다.

3) 와일드카드(*)가 편하지만 항상 안전한 것은 아님

개발 초기에는 *를 넣어 모든 도메인에서 접근하게 만들면 빠르게 테스트할 수 있습니다. 하지만 운영 환경에서 이런 방식은 권한 범위를 지나치게 넓힐 수 있어 주의가 필요합니다. 특히 인증 정보가 포함된 요청이나 민감한 데이터를 다루는 서비스라면, 크로스오리진 허용 범위를 더 세심하게 정해야 합니다.

2. CORS의 기본 구조를 이해해야 하는 이유

1) Access-Control-Allow-Origin의 역할

CORS를 이해할 때 가장 먼저 보는 항목이 Access-Control-Allow-Origin입니다. 이 헤더는 어떤 출처의 요청을 허용할지 브라우저에 알려주는 역할을 합니다. 예를 들어 특정 프런트엔드 도메인만 허용하고 싶다면 해당 도메인을 명시하는 방식으로 설정하는 경우가 많습니다. 이 과정이 바로 실무에서 말하는 핵심적인 CORS설정입니다.

2) 단일 값, 다중 값, 와일드카드의 차이

Access-Control-Allow-Origin은 *로 열어둘 수도 있고, 특정 도메인 하나를 지정할 수도 있습니다. 다만 환경에 따라 여러 도메인을 허용해야 할 때는 단순한 와일드카드보다 서버 로직으로 Origin을 확인하는 방식이 필요할 수 있습니다. 여기서 중요한 점은 무조건 넓게 열어두는 것보다, 필요한 범위만 허용하는 것이 API보안에 더 유리하다는 점입니다.

3) 인증 쿠키와 함께 사용할 때 더 조심해야 함

쿠키나 세션 기반 인증을 사용하는 경우에는 *와 함께 사용할 수 없는 조건들이 있습니다. 즉, 크로스오리진 요청을 허용하더라도 자격 증명까지 포함할지 여부를 함께 검토해야 합니다. 이런 부분을 놓치면 로컬에서는 동작하지만 실제 서비스에서는 예상과 다르게 동작하는 일이 생깁니다.

3. 와일드카드(*) 대신 허용 도메인을 명시해야 하는 이유

1) 예상치 못한 도메인 접근을 줄일 수 있음

운영 환경에서 가장 중요한 것은 “누가 접근할 수 있는가”를 명확하게 정하는 일입니다. Access-Control-Allow-Origin: *는 편리하지만, 허용 범위를 넓게 잡는 만큼 관리 부담도 커집니다. 허용 도메인을 명시하면 불필요한 접근을 줄일 수 있어 API보안 관점에서 더 안정적인 편입니다.

2) 프론트엔드와 백엔드 분리 구조에 적합

최근에는 프론트엔드와 API 서버를 서로 다른 도메인으로 운영하는 경우가 많습니다. 이때는 실제 서비스 도메인만 골라 CORS설정을 하는 방식이 일반적입니다. 예를 들어 운영용 프런트엔드, 스테이징 환경, 내부 테스트용 도메인을 각각 분리해 관리하면 문제 발생 시 원인을 더 쉽게 추적할 수 있습니다.

3) 보안 이슈를 점검하는 출발점이 됨

허용 도메인을 명시하는 습관은 단순히 CORS 문제를 해결하는 데서 끝나지 않습니다. API가 어디까지 노출되는지, 쿠키가 어디로 전송되는지, 브라우저에서 민감한 정보가 잘못 공유되는지까지 함께 점검하게 만들기 때문입니다. 이런 점에서 크로스오리진 정책 정리는 전체 보안 점검의 시작점처럼 활용될 수 있습니다.

4. 실제로 점검해야 하는 CORS 항목

1) 허용 출처가 실제 서비스와 일치하는지

가장 먼저 확인할 것은 Access-Control-Allow-Origin에 적힌 도메인이 실제 운영 도메인과 맞는지입니다. 개발용 도메인이 운영 환경에 남아 있거나, 테스트용 주소가 그대로 노출되는 경우가 의외로 많습니다. 이런 실수는 단순 설정 오류처럼 보여도 API보안 측면에서는 중요하게 봐야 합니다.

2) OPTIONS 프리플라이트 응답이 올바른지

브라우저는 특정 요청을 보내기 전에 미리 확인 요청을 보낼 수 있습니다. 이때 서버가 올바른 헤더로 응답하지 않으면 본 요청이 막힙니다. 그래서 CORS설정은 단순히 GET 요청만 되는지 보는 것이 아니라, 실제 브라우저 흐름 전체를 확인해야 합니다.

3) 쿠키, 인증 헤더, 노출 범위가 적절한지

세션이나 토큰을 사용하는 경우에는 허용 도메인과 자격 증명 설정을 함께 점검해야 합니다. 또한 API 응답에 불필요한 헤더가 포함되어 있거나, 민감한 정보가 클라이언트로 전달되는지도 확인할 필요가 있습니다. 이런 점검은 크로스오리진 환경에서 특히 중요합니다.

5. 설정할 때 자주 하는 실수

1) 개발 편의성 때문에 모든 도메인을 허용하는 경우

초기 테스트에서는 빠르지만, 운영 단계로 넘어가도 *를 유지하는 경우가 있습니다. 이 방식은 접근 통제가 느슨해질 수 있어 주의해야 합니다. 특히 로그인 상태를 활용하는 서비스라면 더 신중한 CORS설정이 필요합니다.

2) 프록시나 CDN 뒤에서 실제 Origin을 놓치는 경우

서버 앞단에 프록시나 CDN이 있으면, 실제 요청 출처를 다르게 해석하는 경우가 있습니다. 이때 Access-Control-Allow-Origin이 기대와 다르게 동작할 수 있습니다. 그래서 배포 환경에서는 로컬 테스트와 별개로 실제 도메인 기준으로 확인하는 과정이 필요합니다.

3) 브라우저에서만 막히고 서버는 정상이라고 착각하는 경우

서버 로그에는 요청이 들어왔는데 브라우저에서만 실패하는 상황도 흔합니다. 이 경우 서버 로직보다 CORS설정을 먼저 점검해야 할 수 있습니다. 브라우저는 보안 정책을 엄격하게 적용하므로, 서버가 정상 응답을 줘도 화면에서는 실패처럼 보일 수 있습니다.

6. 기본 보안 점검 도구를 함께 활용하면 좋은 이유

1) CORS만이 아니라 전체 보안 상태를 함께 보기 쉬움

웹사이트 보안은 CORS 하나만 보고 끝나는 문제가 아닙니다. HTTPS 적용 여부, 인증서 상태, 보안 헤더, 쿠키 설정, API 접근 방식까지 함께 살펴야 실제 위험을 줄일 수 있습니다. 이런 관점에서 URL만 입력해 웹사이트의 기본 보안 상태를 빠르게 점검하는 도구는 초반 진단용으로 도움이 될 수 있습니다.

2) 정보 노출과 브라우저 취약점도 같이 확인 가능

실무에서는 .env 파일이나 소스코드, API 키가 의도치 않게 노출되는 경우도 있습니다. 또한 브라우저에서 실제로 발생하는 XSS, Mixed Content 같은 문제도 함께 봐야 합니다. API보안과 크로스오리진 정책을 정리하는 과정에서 이런 항목까지 함께 점검하면, 놓치기 쉬운 기본 리스크를 줄이는 데 도움이 됩니다.

3) 복잡한 보안 툴 전에 기본 상태를 보는 용도

고가의 복잡한 보안 설정 툴이 아니어도, 기본적인 보안 상태를 먼저 확인하는 것만으로도 초기에 방향을 잡기 좋습니다. 특히 프로젝트 초반이나 배포 직후처럼 빠르게 현황을 보고 싶은 상황에서 유용한 편입니다. Access-Control-Allow-Origin 값이 제대로 들어갔는지, 불필요하게 열린 정책은 없는지 확인하는 데도 연결됩니다.

7. CORS를 제대로 관리해야 하는 상황과 마무리

1) 어떤 서비스에서 특히 중요할까

프론트엔드와 백엔드가 분리된 서비스, 외부 도메인에서 API를 호출하는 서비스, 로그인과 쿠키 인증을 함께 쓰는 서비스라면 CORS설정을 더 꼼꼼히 봐야 합니다. 특히 운영 도메인과 테스트 도메인이 섞여 있거나, 여러 환경에서 같은 API를 공유하는 경우에는 Access-Control-Allow-Origin을 명시적으로 관리하는 편이 좋습니다.

2) 허용 도메인 명시는 보안과 유지보수 모두에 도움

와일드카드(*)는 간편하지만, 실제 서비스에서는 허용 도메인을 분명히 적는 방식이 더 관리하기 쉽습니다. 허용 범위를 좁히면 불필요한 노출을 줄일 수 있고, 나중에 문제를 추적할 때도 원인을 찾기 쉽습니다. 이런 점에서 API보안을 기본부터 정리하는 습관은 장기적으로 유리한 편입니다.

3) 직접 전화보다 도구를 먼저 보는 것이 빠를 때도 있음

운영 중인 사이트를 점검할 때는 팀원에게 직접 물어보는 것보다, 먼저 도구로 현재 상태를 확인하는 편이 더 빠른 경우가 많습니다. 직접 전화로 확인하면 배경 설명이 필요하고 기록도 남기기 어렵지만, 기본 보안 점검 도구를 활용하면 URL 기준으로 현재 상태를 바로 확인할 수 있습니다. 따라서 크로스오리진 허용 범위나 Access-Control-Allow-Origin 설정처럼 즉시 확인이 필요한 항목은, 먼저 도구로 점검한 뒤 필요한 경우에만 담당자와 추가 확인하는 방식이 효율적입니다.