>  기사  >  웹 프론트엔드  >  웹 브라우저에서 CORS가 작동하는 방식 이해

웹 브라우저에서 CORS가 작동하는 방식 이해

DDD
DDD원래의
2024-09-19 01:57:03161검색

Understanding How CORS Works in Web Browsers

CORS(Cross-Origin Resource Sharing)는 웹 애플리케이션이 다른 도메인의 리소스(예: 데이터, 이미지 또는 스크립트)를 요청할 수 있는 방법을 제어하는 ​​웹 브라우저의 중요한 보안 기능입니다. 초기 웹페이지를 제공한 것보다 이는 주로 다른 웹사이트의 민감한 정보에 접근하려는 악의적인 사이트로부터 사용자를 보호하도록 설계되었습니다. 이 블로그에서는 CORS의 작동 방식과 CORS가 웹 개발에 중요한 이유를 설명합니다.
CORS란 무엇인가요?
간단히 말해서 CORS는 웹 페이지가 다양한 도메인에서 요청할 수 있는 리소스를 제어하는 ​​브라우저 메커니즘입니다. 기본적으로 브라우저는 웹 페이지가 페이지가 로드된 도메인이 아닌 다른 도메인에 요청하는 것을 제한하는 SOP(Same-Origin Policy)를 구현합니다. 이 정책은 웹사이트 간의 잠재적으로 유해한 상호 작용을 방지하는 기본적인 보안 기능입니다.

그러나 합법적인 교차 출처 요청이 필요한 경우가 많이 있습니다. 예를 들어 웹 애플리케이션이 다른 서버에 호스팅된 API에서 데이터를 가져와야 하는 경우입니다. CORS는 서버가 리소스에 액세스할 수 있는 도메인을 지정할 수 있도록 하여 이러한 요청을 안전한 방식으로 활성화합니다.

CORS는 어떻게 작동하나요?
CORS는 서버의 응답에 HTTP 헤더를 추가하여 교차 원본 요청이 허용되는지 여부를 나타내는 방식으로 작동합니다. CORS 작동 방식에 대한 단계별 분석은 다음과 같습니다.

클라이언트의 요청
웹페이지가 다른 원본(도메인, 프로토콜 및 포트로 정의됨)에 요청(예: XMLHttpRequest, 가져오기 또는 스크립트 포함을 통해)을 시도하면 브라우저는 요청이 동일 원본 정책을 위반하는지 확인합니다.

CORS 실행 전 요청(복잡한 요청의 경우)
일부 요청, 특히 PUT, DELETE와 같은 메소드 또는 사용자 정의 헤더가 있는 요청은 "복잡한" 것으로 간주됩니다. 실제 요청을 보내기 전에 브라우저는 실행 전 요청이라고 알려진 OPTIONS 요청을 보냅니다. 이 실행 전 요청은 서버에 실제 요청을 허용하는지 묻고 허용되는 HTTP 메소드, 헤더 및 출처를 확인합니다.

서버가 CORS 헤더로 응답
실행 전 요청이나 실제 요청을 받은 서버는 요청이 허용되는지 여부를 나타내는 특정 헤더가 포함된 응답을 다시 보냅니다. 주요 헤더에는 다음이 포함됩니다.

Access-Control-Allow-Origin: 이 헤더는 리소스에 액세스하도록 허용되는 도메인을 지정합니다. 이 헤더에 요청 원본이 포함되어 있으면 브라우저는 응답을 허용합니다. 예를 들어 서버는 다음과 같이 응답할 수 있습니다.

Access-Control-Allow-Origin: https://example.com

Access-Control-Allow-Methods: 이 헤더는 서버가 교차 출처 요청을 허용하는 HTTP 메소드(GET, POST, PUT 등)를 지정합니다.

Access-Control-Allow-Methods: GET, POST

Access-Control-Allow-Headers: 실제 요청에 포함될 수 있는 사용자 정의 헤더를 지정합니다.

Access-Control-Allow-Headers: Content-Type, Authorization

Access-Control-Allow-Credentials: 서버가 자격 증명(쿠키, HTTP 인증)을 허용하는 경우 이 헤더가 포함되고 true로 설정됩니다.

브라우저가 결정합니다
서버의 응답을 받은 후 브라우저는 헤더를 평가합니다. 서버가 적절한 CORS 헤더를 통해 권한을 부여하면 브라우저는 교차 출처 요청을 허용하고 응답을 처리합니다. 그렇지 않은 경우 브라우저가 요청을 차단하고 웹페이지에서 리소스에 액세스할 수 없습니다.

간단한 CORS 요청 예시
https://example.com에 호스팅된 웹 페이지가 https://api.example.com/data에 호스팅된 API에 GET 요청을 시도하는 시나리오를 생각해 보세요.

fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

이 경우 브라우저는 https://api.example.com으로 요청을 보냅니다. API 서버가 https://example.com의 요청을 허용하도록 구성된 경우 헤더로 응답합니다:

Access-Control-Allow-Origin: https://example.com

헤더가 없거나 잘못된 경우 CORS 정책에 따라 브라우저에서 응답을 차단합니다.

CORS 비행 전 예시
더 복잡한 요청의 경우 브라우저는 교차 출처 요청이 허용되는지 확인하기 위해 실행 전 요청을 시작합니다. 다음은 프리플라이트를 트리거하는 PUT 요청의 예입니다.

fetch('https://api.example.com/update', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ key: 'value' })
});

브라우저는 다음과 같이 OPTIONS 요청을 보냅니다.

OPTIONS /update HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

서버는 이 요청이 허용되는지 여부를 나타내는 헤더로 응답해야 합니다.

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: Content-Type

이러한 헤더가 존재하고 유효하면 브라우저는 실제 PUT 요청을 진행합니다.

CORS의 중요성
CORS는 웹 서버가 리소스에 대한 액세스를 제어할 수 있도록 세분화된 메커니즘을 제공하는 보안 기능입니다. CORS가 없으면 악성 웹사이트가 사용자 동의 없이 다른 도메인에서 민감한 데이터를 쉽게 가져올 수 있어 CSRF(Cross-Site Request Forgery)와 같은 보안 취약성이 발생할 수 있습니다.

결론
CORS를 이해하는 것은 API 및 타사 리소스를 사용하는 웹 개발자에게 필수적입니다. 서버에 적절한 CORS 정책을 구성함으로써 개발자는 적법한 교차 출처 상호 작용을 활성화하는 동시에 애플리케이션의 보안을 유지할 수 있습니다.

웹 앱을 개발하는 중 CORS 오류가 발생하는 경우 서버 구성을 확인하고 필요한 헤더가 응답으로 전송되고 있는지 확인하는 것이 중요합니다.

위 내용은 웹 브라우저에서 CORS가 작동하는 방식 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.