CORS 및 비행 전 요청!

CORS란 무엇입니까?

CORS - 원본 간 리소스 공유
간단히 말해서 다른 도메인(읽기 원본)에서 서버로 요청을 허용하려는 경우 CORS가 필요합니다. CORS는 브라우저에서 시행하는 정책입니다.

그러나 Cross-Origin이 무엇입니까? 🤔

Dev.to에서 이 게시물을 읽고 있다고 가정해 보겠습니다. Dev.to는 여기에서 오리진이며 오리진에만 있는 리소스(https 호출 만들기)를 요청할 수 있습니다. 다른 오리진, 심지어 하위 도메인을 호출하는 경우 요청을 교차 오리진 요청이라고 합니다.

사용 사례를 보여주세요!

마이크로서비스 세계에서는 심지어 아키텍처 내에서도 여러 서버와 통신하는 서로 다른 서비스가 있을 수 있습니다. CORS는 신뢰할 수 있는 출처만 서버에 Cross-Origin HTTP 요청을 할 수 있도록 하는 메커니즘입니다.
rahul.dev.to에서 실행 중인 애플리케이션이 있고 내 게시물을 편집하는 기능이 있는 순진한 예를 생각해 보십시오. 게시물이 수정되면 모든 블로깅 사이트(dev.to, medium.com, blogger.com)에서 게시물을 업데이트해야 합니다.

이 가상 사례가 작동하려면 dev.to에서 이 패치 API를 눌러야 합니다.

PATCH https://dev.to/rahul_ramfort/post/20
Request-Headers: User-Agent, api_key

(간결함을 위해 매체 및 블로거 API 호출 무시)

내 서버(rahul.dev.to)에서 다른 서버(dev.to)로 데이터를 게시하려고 하는데 실제로 dev.to에서 이 요청을 하는 것이 허용될 수도 있고 허용되지 않을 수도 있습니다.

이것이 당면한 문제입니다. 브라우저는 이 요청을 하는 것이 안전한지 모릅니다.

프리 플라이트 요청을 입력하십시오! ✈️

이를 해결하기 위해 브라우저는 보안상의 이유로 이 출처 간 요청을 직접 허용하지 않습니다. 실제patch 요청을 실행하기 전에 대신 CORS 요청의 모든 세부 정보와 함께 교차 출처(dev.to)에 대한 OPTIONS 요청을 실행합니다.

세부 정보는 다음과 같습니다.

Origin of the requested server - rahul.dev.to
Method rahul.dev.to is trying to hit - PATCH
Headers rahul.dev.to is trying to send - User-Agent, api_key

Dev.to, 크로스 오리진은 OPTIONS 요청을 수신하고 오리진(rahul.dev.to)이 요청을 거부하거나 허용할 수 있습니다.

이 경우 dev.to는 애플리케이션 계층에서 CORS 요청을 할 수 있는 신뢰할 수 있는 출처 목록을 구성했을 것입니다.

#sample configuration at the nginx layer (dev.to)
'Access-Control-Allow-Origin' "https://api.dev.to, https://rahul.dev.to"
'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT, PATCH'
'Access-Control-Allow-Headers' 'User-Agent,Content-Type,access-key,api-key'
'Access-Control-Max-Age' 86400

rahul.dev.to가 신뢰할 수 있는 출처 중 하나로 나열되면 브라우저는 성공적인 204를 수신합니다. 이제 브라우저는 CORS 요청을 허용하는 것이 안전하다는 것을 이해하고 실제 PATCH 요청을 실행합니다.


rahul.dev.to가 allow-origin에 나열되지 않으면 서버는 OPTIONS 요청을 거부합니다.

이를 잠재적인 위협으로 간주하는 브라우저는 오류를 발생시키는 실제PATCH 요청을 실행하지 않습니다.

Preflight response is not successful

CORS 응답 헤더 이해:

실행 전 요청에 대해 받은 헤더입니다.

Access-Control-Allow-Origin - 액세스 권한이 있는 경우 요청된 출처를 지정합니다.

Access-Control-Allow-Methods - CORS에 허용되는 방법을 지정합니다.

Access-Control-Allow-Headers - 실제 CORS 요청과 함께 사용할 수 있는 헤더를 지정합니다.

Access-Control-Max-Age - 실행 전 요청의 응답을 캐시할 수 있는 시간(초)을 지정합니다. 브라우저는 추가 실행 전 요청을 건너뛰고 해당 기간 동안 실제 요청에 직접 도달합니다.

메모:

Access-Control-Allow-Origin: '*'

CORS 요청을 허용하기 위한 해결 방법으로 이와 같이 구성하는 사람들을 보는 것은 매우 일반적입니다.

이것이 본질적으로 의미하는 바는 서버가 모든 오리진이 CORS 요청에 도달하도록 허용한다는 것입니다. 아니, 이러지 마. 🙅🏻‍♂️ 여기에서는 신뢰할 수 있는 출처만 허용하고 '*'를 사용하는 것은 완전히 피해야 합니다.

또한 신뢰할 수 있는 출처에 대한 실행 전 요청 빈도를 줄이려면 Access-Control-Max-Age 헤더를 더 높은 값으로 설정할 수 있습니다.

더 읽어보기: 📖