CORS 테스터 온라인: 교차 출처 리소스 공유 문제 진단
· 12분 읽기
목차
CORS 이해 및 중요성
교차 출처 리소스 공유(CORS)는 웹 브라우저에 구현된 보안 메커니즘으로, 웹 애플리케이션이 다른 출처의 리소스를 요청하는 방법을 제어합니다. 클럽의 경비원처럼 특정 규칙에 따라 누가 들어갈 수 있고 누가 들어갈 수 없는지 결정합니다.
기본적으로 브라우저는 동일 출처 정책(SOP)을 시행하여 한 도메인에서 실행되는 JavaScript가 다른 도메인의 리소스에 액세스하는 것을 방지합니다. 이는 사용자를 악성 스크립트로부터 보호하는 기본적인 보안 기능입니다. 그러나 최신 웹 애플리케이션은 종종 다른 도메인에 호스팅된 API 및 서비스와 통신해야 하며, 이것이 바로 CORS가 필요한 이유입니다.
CORS는 서버가 브라우저에게 "네, 이 특정 웹사이트가 내 리소스에 액세스해도 괜찮습니다"라고 알려주는 표준화된 방법을 제공합니다. 적절한 CORS 구성이 없으면 정당한 교차 출처 요청이 차단되어 웹 애플리케이션의 기능이 중단됩니다.
전문가 팁: CORS는 브라우저에서 시행하는 보안 기능입니다. cURL이나 Postman과 같은 도구는 브라우저가 아니기 때문에 CORS 문제가 발생하지 않습니다. 항상 실제 브라우저 환경에서 CORS 구성을 테스트하세요.
실제 시나리오를 생각해 보세요: 프론트엔드가 https://myshop.com에 호스팅되어 있지만 제품 재고 API는 https://api.inventory-service.com에 있는 전자상거래 플랫폼을 구축하고 있습니다. CORS 헤더가 없으면 프론트엔드 JavaScript가 제품 데이터를 가져올 수 없어 고객이 빈 선반만 바라보게 됩니다.
다음과 같은 경우 CORS는 더욱 중요해집니다:
- 프론트엔드가 직접 액세스해야 하는 타사 API
- 다른 서비스가 다른 도메인에서 실행되는 마이크로서비스 아키텍처
- 다른 출처에서 자산을 제공하는 콘텐츠 전송 네트워크(CDN)
- 백엔드 API와 통신하는 단일 페이지 애플리케이션(SPA)
- 외부 도메인에서 로드되는 웹 폰트, 이미지 또는 기타 리소스
CORS 작동 방식: 기술적 심층 분석
CORS가 내부적으로 어떻게 작동하는지 이해하면 문제를 더 효과적으로 진단할 수 있습니다. CORS 메커니즘에는 단순 요청과 사전 요청의 두 가지 유형이 있습니다.
단순 요청
단순 요청은 다음 조건을 모두 충족하는 요청입니다:
- 다음 HTTP 메서드 중 하나를 사용: GET, HEAD 또는 POST
- Accept, Accept-Language, Content-Language 또는 Content-Type과 같은 CORS 안전 헤더만 포함
- Content-Type을 사용하는 경우 application/x-www-form-urlencoded, multipart/form-data 또는 text/plain이어야 함
단순 요청의 경우 브라우저는 Origin 헤더와 함께 요청을 직접 보냅니다. 서버는 출처가 허용되는지 여부를 나타내는 Access-Control-Allow-Origin 헤더로 응답합니다. 헤더가 요청 출처와 일치하거나 *로 설정된 경우 브라우저는 JavaScript 코드가 응답을 읽을 수 있도록 허용합니다.
사전 요청
단순 요청 기준을 충족하지 않는 요청은 사전 요청을 트리거합니다. 이는 실제 요청 전에 브라우저가 보내는 OPTIONS 요청으로, CORS 프로토콜이 이해되고 실제 요청을 보내도 안전한지 확인합니다.
사전 요청에는 다음과 같은 헤더가 포함됩니다:
Access-Control-Request-Method: 실제 요청의 HTTP 메서드Access-Control-Request-Headers: 실제 요청과 함께 전송될 사용자 정의 헤더Origin: 요청을 하는 출처
서버는 허용되는 항목을 나타내는 적절한 CORS 헤더로 사전 요청에 응답해야 합니다. 사전 요청이 성공해야만 브라우저가 실제 요청을 보냅니다.
빠른 팁: 사전 요청은 성능에 영향을 줄 수 있습니다. Access-Control-Max-Age 헤더를 사용하여 사전 요청 응답을 캐시하고 서버가 처리해야 하는 OPTIONS 요청 수를 줄이세요.
일반적인 CORS 문제 및 오류 메시지
CORS 오류는 개발자가 직면하는 가장 답답한 문제 중 하나입니다. 가장 일반적인 문제와 그 의미를 분석해 보겠습니다.
Access-Control-Allow-Origin 헤더 누락
이것은 가장 흔히 볼 수 있는 CORS 오류입니다. 브라우저 콘솔에 다음과 같이 표시됩니다:
Access to fetch at 'https://api.example.com/data' from origin 'https://myapp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
이는 서버가 응답에 필요한 CORS 헤더를 포함하지 않았음을 의미합니다. 해결 방법은 간단합니다: 특정 출처 또는 공개 API의 경우 *와 함께 Access-Control-Allow-Origin 헤더를 보내도록 서버를 구성하세요.
잘못된 HTTP 메서드
서버가 명시적으로 허용하지 않은 HTTP 메서드를 사용하려고 하면 다음과 같은 오류가 표시됩니다:
Access to fetch at 'https://api.example.com/data' from origin 'https://myapp.com' has been blocked by CORS policy: Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.
이는 사전 요청 단계에서 발생합니다. 서버는 Access-Control-Allow-Methods 헤더에 HTTP 메서드를 포함해야 합니다.
자격 증명 미지원
쿠키나 인증 헤더를 보내려고 하지만 서버가 이를 위해 구성되지 않은 경우 다음과 같은 오류가 발생합니다:
Access to fetch at 'https://api.example.com/data' from origin 'https://myapp.com' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'.
이를 해결하려면 서버가 Access-Control-Allow-Credentials: true를 보내야 하며, 중요한 점은 자격 증명이 포함된 경우 Access-Control-Allow-Origin: *를 사용할 수 없고 정확한 출처를 지정해야 한다는 것입니다.
사용자 정의 헤더 허용 안 됨
최신 애플리케이션은 API 키, 인증 토큰 또는 기타 메타데이터에 사용자 정의 헤더를 자주 사용합니다. 이러한 헤더가 명시적으로 허용되지 않으면 다음과 같이 표시됩니다:
Request header field x-api-key is not allowed by Access-Control-Allow-Headers in preflight response.
해결 방법은 Access-Control-Allow-Headers 응답 헤더에 사용자 정의 헤더를 포함하는 것입니다.
| 오류 유형 | 일반적인 원인 | 빠른 해결 |
|---|---|---|
| Access-Control-Allow-Origin 없음 | CORS용으로 구성되지 않은 서버 | 서버 응답에 헤더 추가 |
| 메서드 허용 안 됨 | 허용 목록에 없는 HTTP 메서드 | Access-Control-Allow-Methods 업데이트 |
| 자격 증명 미지원 | 자격 증명 헤더 누락 | Access-Control-Allow-Credentials: true 설정 |
| 헤더 허용 안 됨 | 화이트리스트에 없는 사용자 정의 헤더 | Access-Control-Allow-Headers에 추가 |
| 자격 증명과 와일드카드 | 자격 증명 모드에서 * 사용 | * 대신 정확한 출처 지정 |
CORS 테스터 효과적으로 사용하기
CORS 테스터는 코드를 작성하지 않고도 교차 출처 문제를 진단하는 데 매우 유용한 도구입니다. 브라우저 요청을 시뮬레이션하고 전송 및 수신되는 CORS 헤더를 정확히 보여줍니다. CORS 테스터를 사용하여 문제를 빠르게 진단할 수 있습니다.
좋은 CORS 테스터가 해야 할 일
효과적인 CORS 테스트 도구는 다음을 제공해야 합니다:
- 대상 URL 및 출처를 지정하는 기능
- 다양한 HTTP 메서드(GET, POST, PUT, DELETE 등)를 선택하는 옵션
- 특정 시나리오를 테스트하기 위한 사용자 정의 헤더 구성
- 요청 및 응답 헤더의 명확한 표시
- CORS 검사 통과 또는 실패 여부 표시
- 무엇이 잘못되었는지 설명하는 상세한 오류 메시지
단계별 테스트 프로세스
CORS 테스터를 효과적으로 사용하는 방법은 다음과 같습니다:
- 테스트할 API 엔드포인트 URL 입력
- 요청을 할 출처 지정 (프론트엔드 도메인)
- 애플리케이션이 사용할 HTTP 메서드 선택
- 애플리케이션이 보내는 사용자 정의 헤더 추가 (Authorization 또는 X-API-Key 등)
- 테스트 실행 및 결과 검토
- 응답 헤더 검토하여 어떤 CORS 정책이 적용되어 있는지 확인
- 서버에서 구성해야 하는 누락되거나 잘못된 헤더 식별
전문가 팁: 항상 프로덕션 애플리케이션이 사용할 정확한 출처로 테스트하세요. 일부 서버는 localhost에서는 작동하지만 프로덕션 도메인에서는 실패할 수 있는 출처별 CORS 구성을 가지고 있습니다.
테스트 결과 해석
CORS 테스트를 실행할 때 다음 주요 지표에 주의하세요:
- 사전 요청 상태: OPTIONS 요청이 성공했나요? 그렇지 않다면 서버가 사전 요청을 올바르게 처리하지 못할 수 있습니다.
- Access-Control-Allow-Origin 값: 출처와 일치하거나 *로 설정되어 있나요? 일치하지 않으면 요청이 실패합니다.
- 허용된 메서드: 의도한 HTTP 메서드가 Access-Control-Allow-Methods에 나열되어 있나요?
- 허용된 헤더: 모든 사용자 정의 헤더가 Access-Control-Allow-Headers에 포함되어 있나요?
- 자격 증명 지원: 쿠키를 보내야 하는 경우 Access-Control-Allow-Credentials가 true로 설정되어 있나요?
HTTP 헤더 분석기를 사용하여 전송 및 수신되는 모든 헤더에 대한 상세한 분석을 얻을 수도 있으며, 이는 CORS 테스트를 완벽하게 보완합니다.
CORS 문제 진단 실용 예제
예제 1: 소셜 미디어 통합
여러 플랫폼의 게시물을 집계하는 소셜 미디어 대시보드를 구축하고 있다고 가정해 봅시다. https://dashboard.example.com의 프론트엔드가 https://api.socialmedia.com에서 데이터를 가져와야 합니다.
새 게시물을 만들기 위해 POST 요청을 하고 있지만 계속 CORS 오류가 발생합니다. 진단 방법은 다음과 같습니다:
- CORS 테스터를 열고
https://api.socialmedia.com/posts입력 - 출처를
https://dashboard.example.com으로 설정 - 메서드로 POST 선택
- Content-Type 헤더 추가:
application/json - Authorization 헤더 추가:
Bearer your-token-here - 테스트 실행
테스트 결과 서버가 GET 요청만 허용하는 것으로 나타났습니다. Access-Control-Allow-Methods 헤더는 GET, HEAD, OPTIONS를 표시합니다. POST 요청을 활성화하려면 API 제공업체에 문의하거나 게시물 생성을 위한 다른 엔드포인트가 있는지 확인해야 합니다.
예제 2: 전자상거래 재고 시스템
https://shop.example.com의 전자상거래 사이트가 https://inventory.example.com에서 재고 데이터를 가져옵니다. API는 어떤 매장이 요청하는지 식별하기 위해 사용자 정의 헤더 X-Shop-ID가 필요합니다.
테스트 결과 오류가 나타납니다: "Request header field x-shop-id is not allowed b