CORS
교차 출처 리소스 공유 \(CORS\) 메커니즘은 브라우저와 웹 서버 간의 안전한 교차 도메인 요청 및 데이터 전송을 지원합니다. CORS 표준은 서버가 해당 정보를 읽을 수 있는 출처 집합을 설명할 수 있는 새로운 HTTP 헤더를 추가하는 방식으로 작동합니다. 이 정책은 클라이언트 또는 애플리케이션이 선택한 리소스에 액세스할 수 있는 권한을 얻기 위해 추가 HTTP 헤더를 사용하는 CORS 지원을 제공합니다. 애플리케이션이나 클라이언트가 현재 요청이 시작된 도메인, 프로토콜 또는 포트가 아닌 다른 도메인, 프로토콜 또는 포트에서 리소스를 요청할 때 교차 출처 HTTP 요청을 합니다.
API 수준에서 이 정책을 적용하려면 webMethods API Gateway 에 이 정책을 적용하려면 watt.server.cors.enabled 속성을 false 으로 설정했는지 확인하세요.
이 정책은 REST, SOAP 및 ODATA API에 적용됩니다. 이 표에는 이 정책에 대해 지정할 수 있는 CORS 응답 사양이 나열되어 있습니다:
| 특성 | 설명 |
|---|---|
| 허용된 오리진 | 응답이 시작되는 원본을 지정합니다. 오리진 구문: scheme://host:port 추가 버튼을 클릭하여 여러 출처를 추가할 수 있습니다. 허용된 출처에 정규식을 제공할 수도 있습니다. 허용되는 출처는 애플리케이션의 고급 섹션에서도 지정할 수 있습니다. 이 API에 등록된 애플리케이션의 허용된 출처도 이 API에 액세스할 수 있습니다. |
| 헤더 허용 | 요청에 허용되는 헤더를 지정합니다.
|
| 헤더 노출 | 요청 실패 시 사용자에게 노출되는 헤더를 지정합니다.
|
| 신임 정보 허용 | 포함 여부를 지정합니다 webMethods API Gateway 에 액세스 제어 허용 자격 증명 헤더를 포함할지 여부를 지정합니다. |
| 허용되는 메소드 | 요청에 허용되는 메소드를 지정합니다. 다음 중 하나 이상을 지정합니다: GET, POST, PUT, DELETE, PATCH. |
| 최대 유효 기간 | 비행 전 응답이 유효한 연령을 지정합니다. |
사양에 따라 모든 값에 해당하는 HTTP 헤더가 설정됩니다. 자세한 내용은 https://www.w3.org/TR/cors/.
webMethods API Gateway 는 CORS 비행 전 요청과 CORS 요청을 다르게 처리합니다. CORS 사전 비행 및 CORS 요청의 작업 흐름에 대해 자세히 알아보려면 해당 순서도를 참조하세요.
CORS 사전 비행 요청
CORS 사전 비행 요청은 브라우저가 원래의 CORS 요청 전에 보내는 HTTP 요청으로, 서버가 실제 CORS 요청을 webMethods API Gateway 서버가 실제 CORS 요청을 허용할지 여부를 확인합니다. CORS 사전 비행 요청은 OPTIONS 메서드를 사용하며 브라우저에서 API Gateway 으로 전송되는 요청의 일부로 이러한 헤더를 포함합니다:
- 출처
- 액세스 제어 요청 방법
- 액세스-제어-요청-헤더
다음 흐름도는 API Gateway 에 접수된 CORS 사전 비행 요청의 흐름을 설명합니다:

다음 표는 브라우저에서 발생하는 CORS 비행 전 요청의 다양한 사용 사례와 각 요청에 대한 webMethods API Gateway 가 각 CORS 프리플라이트 요청에 응답하는 방법을 보여줍니다:
| # | 브라우저의 CORS 사전 비행 요청 헤더 | 에서 구성된 CORS 정책 webMethods API Gateway | webMethods API Gateway 각 응답을 브라우저로 전송합니다 |
|---|---|---|---|
| 1 | 출처: http://test.com 접근 제어 요청 방법: POST 액세스-제어-요청-헤더 : test1,test2 |
액세스-제어-허용-오리진 : http://test2.com 접근 제어 허용 방법 : POST,GET,PUT 액세스-제어-허용-헤더 : test1,test2 |
브라우저의 Origin 헤더( http://test.com )가 CORS 정책에 구성된 Access-Control-Allow-Origin( http://test2.com )과 일치하지 않으므로 403 Specified Origin is not allowed 상태를 보냅니다. |
| 2 | 출처: http://test2.com 액세스 제어 요청 방법: 삭제 액세스-제어-요청-헤더 : test1,test2 |
액세스-제어-허용-오리진 : http://test2.com 접근 제어 허용 방법 : POST,GET,PUT 액세스-제어-허용-헤더 : test1,test2 |
Sends 405 Method Not Allowed 상태는 브라우저의 액세스 제어 요청 방법 헤더(DELETE)가 CORS 정책에 구성된 액세스 제어 허용 방법(POST,GET,PUT)과 일치하지 않기 때문입니다. |
| 3 | 출처: http://test2.com 접근 제어 요청 방법: POST 액세스-제어-요청-헤더 : test3 |
액세스-제어-허용-오리진 : http://test2.com 접근 제어 허용 방법 : POST,GET,PUT 액세스-제어-허용-헤더 : test1,test2 |
Sends 403 Header Not Supported브라우저의 액세스 제어 요청 헤더( test3 )가 CORS 정책에 구성된 액세스 제어 허용 헤더( test1,test2 )와 일치하지 않기 때문입니다. |
| 4 | 출처: http://test2.com 접근 제어 요청 방법: POST 액세스-제어-요청-헤더 : test1 |
액세스-제어-허용-오리진 : http://test2.com Access-Control-Allow-Methods : POST 액세스 제어-허용-헤더 : test1, test2 액세스 제어-최대 연령: 100 액세스 제어 허용 자격 증명 : true 액세스-제어-노출-헤더 : header1,header2 |
다음 헤더와 함께 200 OK 상태를 전송합니다:
브라우저의 원본, 메서드 및 헤더가 구성된 CORS 정책과 일치하므로 webMethods API Gateway. |
| 5 | 출처: http://test2.com 접근 제어 요청 방법: POST 액세스-제어-요청-헤더 : test1 |
액세스-제어-허용-오리진 : http://test1.com Access-Control-Allow-Methods : POST 액세스 제어-허용-헤더 : test1, test2 액세스 제어-최대 연령: 100 액세스 제어 허용 자격 증명 : true 액세스-제어-노출-헤더 : header1,header2 또한 애플리케이션에서 자바스크립트 출처를 다음과 같이 지정한 경우 http://test2.com |
다음 헤더와 함께 200 OK 상태를 전송합니다:
브라우저의 오리진 헤더가 구성된 CORS 정책과 일치하지 않더라도 애플리케이션에서 구성된 자바스크립트 오리진과 일치합니다. |
CORS 요청
CORS 요청은 Origin 헤더가 포함된 HTTP 요청입니다. 언제 webMethods API Gateway 가 CORS 요청을 받으면 CORS 요청의 Origin 헤더가 CORS 정책에 구성된 Access-Control-Allow-Origin과 비교하여 확인되며, 일치하면 API Gateway 리소스에 대한 액세스를 허용합니다.
다음 흐름도는 다음에서 수신된 CORS 요청의 흐름을 설명합니다 webMethods API Gateway.

다음 표에서는 브라우저에서 발생하는 CORS 요청의 다양한 사용 사례와 각 CORS 요청에 대한 webMethods API Gateway 가 각 CORS 요청에 응답하는 방법을 자세히 설명합니다.
| # | 브라우저의 CORS 요청 헤더 | 에서 구성된 CORS 정책 webMethods API Gateway | webMethods API Gateway 각 응답을 브라우저로 전송합니다 |
|---|---|---|---|
| 1 | 출처: http://test.com |
액세스-제어-허용-오리진 : http://test2.com 접근 제어 허용 방법 : POST,GET,PUT 액세스-제어-허용-헤더 : test1,test2 액세스 제어-최대 연령: 100 액세스 제어 허용 자격 증명 : true 액세스-제어-노출-헤더 : header1,header2 |
브라우저의 Origin 헤더( http://test.com )가 CORS 정책에 구성된 Access-Control-Allow-Origin( http://test2.com )과 일치하지 않으므로 403 Specified Origin is not allowed 상태를 보냅니다. |
| 2 | 출처: http://test2.com |
액세스-제어-허용-오리진 : http://test2.com 접근 제어 허용 방법 : POST,GET,PUT 액세스-제어-허용-헤더 : test1,test2 액세스 제어-최대 연령: 100 액세스 제어 허용 자격 증명 : true 액세스-제어-노출-헤더 : header1,header2 |
다음 헤더와 함께 200 OK 상태를 전송합니다:
브라우저의 Origin 헤더( http://test2.com )가 액세스 제어-허용-오리진( http://test2.com )에 구성된 CORS 정책과 일치하기 때문에 webMethods API Gateway. |
| 3 | 출처: http://test2.com 액세스 제어 요청 방법: POST 액세스-제어-요청-헤더: test1 |
액세스-제어-허용-오리진 : http://test1.com Access-Control-Allow-Methods : POST 액세스-제어-허용-헤더 : test1,test2 액세스 제어-최대 연령: 100 액세스 제어 허용 자격 증명 : true 액세스-제어-노출-헤더 : header1,header2 또한 애플리케이션에서 자바스크립트 출처를 다음과 같이 지정한 경우 http://test2.com |
다음 헤더와 함께 200 OK 상태를 전송합니다:
브라우저의 오리진 헤더가 구성된 CORS 정책과 일치하지 않더라도 애플리케이션에서 구성된 자바스크립트 오리진과 일치합니다. |
- 네이티브 서비스가 CORS 메커니즘을 지원하며 API Gateway 에서 CORS 정책을 구성하지 않은 경우 webMethods API Gateway 는 통과 보안 모드로 전환되어 CORS 요청을 네이티브 서비스로 전달합니다.
- 네이티브 서비스가 CORS 메커니즘을 지원하고 API Gateway 에서 CORS 정책도 구성한 경우 webMethods API Gateway 가 CORS 요청을 우선적으로 처리합니다.
을 클릭하여 허용할 헤더를 여러 개 추가할 수 있습니다.