CORS의 동작방식
브라우저는 다른 출처로 판단한 리소스에 접근시 HTTP Origin 헤더에 출처를 추가하여 요청합니다. 요청을 받은 서버는 Origin 헤더를 기반으로 리소스 접근 허용 정책을 Access-Control-Allow-Origin 헤더에 추가하여 응답합니다. 이후 브라우저는 Access-Control-Allow-Origin 헤더값을 확인하고 현재 출처와 비교하여 권한 유무를 결정합니다.
Access-Control-Allow-Origin 외에도 좀더 상세한 정책을 위한 CORS 헤더가 있지만 이번 주제에서는 중요하지 않으므로 다루지 않습니다.
중간 캐시로 인한 CORS 에러
정적 리소스는 대부분 중간 캐시를 통해 클라이언트에 전달하는 형태로 설계됩니다. 보통 CDN을 사용하게되고 별도의 도메인을 사용하는 경우가 많습니다. 이 경우 서로 다른 출처 간 리소스 공유가 필요하게 되어 CORS 정책이 필요합니다.
예시를 위해 S3 리소스를 AWS Cloudfront를 통해 중간 캐시한다고 가정해보겠습니다. S3 bucket에 아래 메뉴에서 CORS 정책을 직접 설정할 수 있습니다.
아래처럼 요청 출처마다 다른 CORS 정책을 사용할 수도 있습니다. 예시에서는 https://test-a.com과 https://test-b.com 출처인 경우만 CORS를 허용하지만 허용하는 Method 등의 상세 정책은 다릅니다.
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET"
],
"AllowedOrigins": [
"https://test-a.com"
],
"ExposeHeaders": [],
},
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"POST"
],
"AllowedOrigins": [
"https://test-b.com"
],
"ExposeHeaders": [
"Content-Length"
]
}
]
여기서 주의할 점은 클라이언트는 S3에 직접 접근하는 것이 아닌 Cloudfront를 통한다는 것입니다.
Cloudfront는 cache key를 기반으로 응답을 캐시하고 기본값은 리소스 url입니다. 기본값을 사용한다면 Origin 헤더가 다른 요청이라도 동일한 리소스에 접근한다면 같은 캐시 응답을 받게 됩니다.
출처
http://blog.hwahae.co.kr/all/tech/tech-tech/10550/?ref=codenary
