[Web]Same-Origin Policy(동일 출처 정책)와 CORS에 대해서

Same-Origin Policy(이하 SOP) 및 CORS(Cross-Origin Resource Sharing)는 한 도메인의 웹 페이지가 다른 도메인의 리소스(ex. 데이터 또는 스크립트)를 요청하고 엑세스하는 방법을 제어하기 위해 웹 브라우저에서 사용되는 보안 매커니즘이다.
이런 매커니즘은 웹 사용자의 보안과 개인정보를 유지하는데 중요하다.

각각에 대해서 자세하게 알아보도록 하자.

1. SOP(동일 출처 정책)

정의

SOP(Same-Origin Policy)는 웹 보안 모델의 중요한 개념 중 하나로, 웹 브라우저에서 실행되는 웹 페이지에서 다른 출처(Origin)로부터의 리소스에 대한 접근을 제한하는 보안 정책을 나타낸다.
SOP는 웹 애플리케이션의 보안을 유지하기 위해 사용된다.

본질적으로는 "한 출처의 스크립트가 다른 출처의 데이터에 엑세스할 수 없어야 한다"는 원칙을 시행한다.

SOP의 핵심

출처(Origin)는 프로토콜(ex. http, https), 호스트(ex. www.example.com), 포트번호(ex, 80, 443)로 정의된다.
동일한 출처를 갖는 리소스들은 동일한 출처로 간주되며 서로에게 자유롭게 접근할 수 있다.

SOP에 따르면 스크립트, AJAX요청, 이미지, 스타일 시트 등의 웹 페이지 리소스는 동일한 출처에서만 접근 가능하다.
즉, 다른 출처로부터의 리소스에는 직접 접근할 수 없다.

SOP는 악의적인 웹페이지나 악성 스크립트로부터 공격을 방지하기 위해 설계되었다.
만약 SOP가 없다면 악성 스크립트가 사용자의 개인 데이터에 접근하거나 다른 웹사이트로부터 데이터를 훔치는 등의 공격이 빈번하게 발생할 수 있다.

SOP는 웹 보안의 기본 원칙 중 하나이며, 웹 브라우저는 이를 엄격하게 시행한다.
그러나 필요한 경우, CORS(Cross-Origin Resource Sharing)와 같은 매커니즘을 사용하여 다른 출처로의 리소스 접근을 명시적으로 허용할 수 있다.

http://www.example.com = http://www.ezample.com 의 경우 SOP이다.
http://example.com:443 에서 http://example.com:80으로 AJAX요청을 보내는 경우, 포트 번호가 다르기 때문에 브라우저에서는 다른 출처로 간주하고 접근을 제한하게 된다.
http://example.com:443에서 https://example.com:443으로 AJAX요청을 보내는 경우, 프로토콜이 달라 브라우저에서 다른 출처로 간주하고 접근을 제한하게 된다.

http, https의 차이?

http는 HyperText Tranfer Protocol의 약자이고, https는 HyperText Transfer Protocol Secure의 약자이다.

차이점에 대해서 알아보자

1. 보안(Encryption)

• HTTP : HTTP는 데이터를 평문으로 전송한다. 이것은 해커가 데이터를 가로채거나 도청할 수 있는 보안상의 취약점을 가지고 있다. 중요한 데이터(ex. 로그인 정보, 결제 정보 등)를 전송할 때 안전하지 않다.
• HTTPS : HTTPS는 보안 소켓 계층(SSL, TLS)을 사용하여 데이터를 암호화하고 보호한다. 이로써 데이터가 전송되는 동안 중간에서 가로채어도 해독하기 어렵다. 따라서 중요한 데이터의 안전성을 보장한다.

2. 데이터 무결성(Integrity)

• HTTP : HTTP는 데이터의 무결성을 확인하지 않는다. 따라서 데이터가 전송되는 동안 변조될 수 있다.
• HTTPS : HTTPS는 데이터 무결성을 보장하기 위해 암호화와 함께 전송중인 데이터를 검증한다. 데이터가 변경되었는지 여부를 확인하여 데이터 무결성을 유지한다.

3. 인증(Authentication)

• HTTP : HTTP는 통신 상대방의 정체성을 확인하지 않는다. 따라서 공격자가 가짜 웹 사이트를 만들어 사용자를 속일 수 있다.
• HTTPS : HTTPS는 인증된 SSL/TLS인증서를 사용하여 서버의 신원을 확인한다. 사용자가 정식 웹 사이트와 통신하고 있는지 확인하여 중간자 공격을 방지한다.

4. 포트번호

• HTTP : 기본적으로 80번 포트를 사용한다.
• HTTPS : 기본적으로 443 포트를 사용한다.

5. 속도와 성능

• HTTPS의 암호화와 복호화 작업으로 인해 약간의 성능 오버헤드가 발생할 수 있다. 그러나 현대의 하드웨어와 암호화 기술은 이러한 오버헤드를 크게 줄여서 웹 사이트의 속도 저하를 거의 느끼지 못할 수 있다.

정리하자면, HTTP는 데이터 보안 및 무결성, 인증을 제공하지 않고, HTTPS는 이러한 보안 기능을 제공하여 웹 통신을 안전하게 만든다.
그래서 민감한 정보를 다루거나 사용자의 개인정보를 수집하는 웹 사이트에서는 HTTPS를 사용하는 것이 권장된다.

SOP의 주요 측면

웹 페이지에서 실행되는 자바스크립트는 동일한 출처에 대해서만 XMLHttpRequest 또는 FetchAPI요청을 할 수 있다.
쿠키, 로컬스토리지, 기타 웹 저장 매커니즘은 동일한 오리진 정책을 적용받는다.
즉, 웹 페이지는 동일한 오리진에서 페이지별로 저장된 데이터만 접근할 수 있다.
SOP는 사이트 간 요청 위조(CSRF), 사이트 간 스크립팅(XSS)과 같은 일반적인 웹 보안 취약성을 방지한다.

CSRF, XSS란?

CSRF(Cross-Site Request Forgery / 사이트 간 요청 위조)는 공격자가 사용자가 알지 못하거나 동의하지 않은 채 웹 사이트에서 작업을 수행하도록 속이는 웹 공격 유형이다.
공격은 사용자가 웹 사이트에서 인증될 때 발생하며, 공격자는 사용자가 자신도 모르게 해당 웹사이트에서 작업을 실행하도록 유도한다.
이런 작업은 계정 설정 변경부터 금융 거래까지 다양하다.

CSRF의 작동 방식은 공격자가 일반적으로 사용자의 이메일 주소 변경과 같이 대상 웹사이트에 대한 요청이 포함된 악성 웹페이지나 이메일을 만든다.
피해자가 공격자의 페이지를 방문하거나 악성 이메일을 열면 사용자가 이미 인증을 받았기 때문에 브라우저는 자동으로 대상 웹사이트에 요청을 보낸다.
요청은 사용자 세션에서 발생하므로 웹 사이트에서는 이를 합법적인 작업으로 잘못 가정하여 수행할 수 있다.

CSRF에 대한 가장 일반적인 방어는 Anti-CSRF토큰을 사용하는 것이다.
이러한 토큰은 세션별로 생성되며 양식 또는 API요청에 포함된다.
서버는 요청을 처리하기 전에 토큰의 유효성을 확인한다.
이렇게 하면 공격자가 일반적으로 얻을 수 없는 유효한 토큰을 통해서만 요청을 수행할 수 있다.
혹은 적절한 SOP를 설정하고 쿠키에 SameSite 속성을 사용하면 쿠키 범위를 동일한 출처로 제한하여 CSRF공격을 방지하는데 도움이 될 수 있다.

XSS(Cross-Site Scripting / 교차 사이트 스크립팅)은 공격자가 웹 애플리케이션의 출력에 악성 스크립트(일반적으로 자바스크립트)를 삽입한 후 해당 콘텐츠를 보는 다른 사용자에 의해 실행될 때 발생하는 취약점이다.
이로 인해 민감한 정보(ex. 쿠키 또는 세션 데이터)가 도용되거나 사용자의 탐색 세션이 조작될 수 있다.

XSS 공격은 일반적으로 사용자 생성 콘텐츠(ex. 댓글, 게시글)에 스크립트를 삽입하거나 웹 애플리케이션의 취약점을 악용하여 스크립트를 직접 삽입하는 것을 포함한다.
다른 사용자가 손상된 콘텐츠를 보면 해당 브라우저는 웹 애플리케이션의 컨텍스트에서 삽입된 스크립트를 실행하여 공격자가 피해자를 대신하여 데이터를 훔치거나 작업을 수행할 수 있도록 한다.

XSS공격을 완화하는 방법으로는 우선, 모든 사용자 입력이 검증되고 적절하게 삭제 되었는지 확인하는 방법이 있다.
이렇게 하면 악성 스크립트가 처음에 삽입되는 것을 방지할 수 있다.
그 다음, 사용자 생성 콘텐츠를 브라우저에서 렌더링하기 전에 인코딩한다. 이것은 잠재적으로 위험한 문자를 해당 HTML 또는 자바스크립트 엔티티로 변환하여 스크립트 실행을 방지한다.
또, 웹 페이지에서 로드할 수 있는 콘텐츠 소스(ex. 스크립트, 스타일, 이미지 등)를 지정하려면 콘텐츠 보안 정책(CSP)헤더를 구현하자.
이것은 악성 스크립트의 실행을 방지하는 데 도움이 된다.
마지막으로, HTML, 자바스크립트, 기타 콘텍스트에 동적 데이터를 포함할 때 컨텍스트 별 탈출 방법을 사용하여 데이터 코드가 아닌 데이터로 처리되도록 한다.

정리해보자면 CSRF와 XSS는 서로 다른 공격 벡터와 완화 전략을 가진 서로 다른 두가지 웹 보안 취약점이다.
CSRF는 사용자를 속여 승인되지 않은 요청을 하도록 하는 반면에, XSS는 웹 애플리케이션에 악성 스크립트를 주입하여 데이터를 훔치거나 다른 사용자를 대신하여 작업을 수행한다.
이러한 취약점으로부터 보호하려면 적절한 코딩 방법과 보안 매커니즘, 사용자 교육이 결합되어야 한다.

SOP의 장점

• 보안 강화 : SOP는 다른 출처로부터의 접근을 제한함으로써 웹 페이지와 사용자의 데이터를 보호한다. 이는 악의적인 웹 사이트나 스크립트로부터의 공격을 방지하고 개인 정보 누출 및 데이터 도난을 방어한다.
• 신뢰성 : 웹 페이지가 다른 출처로부터의 리소스를 마음대로 접근하지 못하므로 웹 페이지가 예상대로 작동하고 사용자 경험을 파괴하지 않도록 보장한다.
• 독립성 : 다른 출처의 리소스에 대한 접근을 제한하면 다른 도메인의 변경 사항이 애플리케이션에 영향을 미치지 않도록 보호한다. 이는 웹 애플리케이션의 독립성을 유지하고 안정성을 향상시킨다.
• 웹 환경 분리 : 다른 출처로의 접근을 허용하지 않음으로써 웹 페이지 간의 상호 작용을 제어한다. 이것은 웹 페이지간의 보안 문제를 방지하고 웹 페이지의 신뢰성을 높인다.
• 규모 확장성 : SOP는 웹에서 다양한 도메인과 애플리케이션 간의 통신을 안전하게 관리하도록 도와준다. 이로써 대규모 웹 애플리케이션의 개발과 관리가 더욱 쉬워진다.

SOP의 단점

• 출처 제한 : SOP는 다른 출처로부터의 리소스 접근을 제한하기 때문에 웹 개발자가 특정 상황에서 원하는 리소스에 접근하는 것을 어렵게 만들 수 있다. 때로는 필요한 기능을 구현하기 위해 출처를 허용해야 할 때가 있다.
• 외부 API와의 통합 어려움 : SOP는 외부 API와의 통합을 어렵게 만들 수 있다. 다른 도메인의 서비스를 사용하려면 CORS 또는 JSONP와 같은 특수 기술을 사용하여 출처를 허용해야 한다.
• 서버 부담 : CORS정책을 구현하려면 서버 측에서 추가적인 구성이 필요하며, 이는 웹 개발자와 서버 관리자에게 부담을 줄 수 있다.
• 보안 취약점 : SOP는 대부분의 상황에서 보안을 강화하지만, 모든 공격을 완벽하게 막을 수는 없다. 몇가지 보안 취약점과 사소한 회피 방법이 존재할 수 있다.
• 테스트 어려움 : SOP로 인해 리소스 접근이 제한되므로 웹 애플리케이션의 테스트와 디버깅이 어려울 수 있다. 특히 개발 환경과 운영 환경에서의 차이로 인해 문제가 발생할 수 있다.
• 정책의 복잡성 : CORS정책은 다양한 설정 옵션과 헤더를 포함하고 있어 초기에는 혼란스러울수 있지만 적절한 정책 설정을 위해 개발자가 이를 구현해야 한다.

보안 취약점 : 몇가지 보안 취약점이란?

SOP는 대부분의 웹 보안 공격을 효과적으로 방지하지만, 특정 상황에서는 여전히 일부 보안 취약점이 존재할 수 있다.

1. 쿠키 공격(Cookie-based Attacks) : SOP는 다른 출처로부터 쿠키에 대한 접근을 방지하지만, 쿠키 공격을 통해서 쿠키 값을 다른 도메인으로 전송하거나 변경하는 공격이 가능하다. 이것을 방지하기 위해서 웹 애플리케이션은 쿠키에 안전한 플래그를 설정하고, 중요한 데이터를 서버측에서 유지하는 등의 조치를 취해야 한다.
2. JSONP(JSON with Padding)를 이용한 공격 : JSONP는 SOP를 우회하는데 사용될 수 있으며, 악의적인 웹 사이트가 사용자 브라우저를 통해 데이터를 요청하고 다른 도메인에서의 응답을 받아올 수 있게 한다. 이것을 방지하려면 서버측에서 JSONP엔드포인트를 안전하게 구성해야 한다.
3. CSRF 공격 : SOP는 일반적으로 사용자의 동작과 관계없이 다른 출처로의 요청을 보내는 것을 방지하지만, 사용자가 인증된 세션과 함께 악의적인 요청을 전송하는 CSRF공격은 여전히 문제가 될 수 있다. CSRF토큰을 사용하거나 SameSite쿠키 속성을 설정하여 이러한 공격을 방지할 수 있다.
4. DNS 리바인딩 : DNS 리바인딩 공격은 다른 도메인으로 요청을 보내는 공격이다. 이것을 방지하기 위해 브라우저는 DNS 리바인딩 방어 매커니즘을 사용하고 있지만, 완벽한 보호를 제공하지는 않을 수 있다. 따라서 서버측에서 적절한 보안 조치를 취해야한다.
5. 브라우저 확장 기능 : 사용자가 설치한 브라우저 확장 기능은 SOP를 우회하고 추가 기능을 제공할 수 있다. 악의적인 확장 기능이 사용자의 개인 정보에 접근하거나 다른 출처로 데이터를 전송하는 공격이 발생할 수 있다. 따라서 브라우저 확장 기능의 사용을 신중하게 검토하고 관리해야한다.

2. CORS(Cross-Origin Resource Sharing)

정의

CORS는 Cross-Origin Resource Sharing의 약자로, 웹 애플리케이션에서 보안상의 이유로 인해 브라우저가 서로 다른 출처(Origin)에서 오는 HTTP요청에 대한 접근을 제어하는 매커니즘을 나타낸다.
이것은 웹 애플리케이션의 보안을 유지하고 다른 도메인으로부터의 잠재적으로 악성 요청을 방지하기 위한 중요한 보안 정책 중 하나이다.

SOP는 보안에 필수적이지만, 타사 API의 데이터에 접근하거나 다른 도메인의 글꼴이나 스크립트와 같은 리소스를 포함하는 등 합법적인 사용 사례에 서로 다른 출처 간의 통신이 필요한 경우 지나치게 제한적일 수 있다.
하지만 CORS는 서버 관리자가 SOP를 선택적으로 완화할 수 있는 매커니즘이다.
즉, CORS는 SOP의 예외로서 서버 측에서 특정 출처로부터의 요청을 허용하도록 설정할 수 있게 해준다.

어떠한 상황에서 CORS가 사용될까?

1. 서로 다른 출처에서 리소스 요청 : 브라우저에서 스크립트 또는 AJAX요청을 통해 다른 도메인의 웹 서버로 데이터를 가져오려고 할때 CORS정책이 적용된다.
2. 웹 폰트, 이미지, 스타일 시트 등 외부 리소스 요청 : 웹 페이지에서 외부 도메인의 리소스를 불러올 때도 CORS가 관련될 수 있다.

CORS 정책을 통한 보안 작동방식

1. 웹 서버에서 응답 헤더를 설정 : 웹 서버는 응답 헤더에 'Access-Control-Allow-Origin'헤더를 포함하여 어떤 출처에서의 요청을 허용할지 명시한다. 이 헤더는 특정 출처 또는 모든 출처에서의 요청을 허용할 수 있다.
2. 브라우저에서 사전 요청(PreFlight) 확인 : 브라우저는 실제 요청을 보내기 전에 사전 요청을 보내서 서버가 요청을 받아들일 수 있는지 확인한다. 사전 요청은 HTTP메소드가 'OPTIONS'이며, 서버에서는 이에 대한 응답을 해야 한다.
3. 보안 헤더를 확인 : 브라우저는 응답에서 'Access-Control-Allow-Origin'헤더를 확인하여 요청을 수락 또는 거부한다. 만약 허용되지 않은 출처에서의 요청이라면 브라우저는 자바스크립트 코드에서 해당 응답에 접근하는 것을 막는다.

웹 서버에서 응답 헤더를 설정하는 예제 코드

const express = require('express');
const app = express();

// 미들웨어를 사용하여 CORS 헤더를 설정합니다.
app.use((req, res, next) => {
  // "example.com" 출처에서의 요청을 허용하도록 헤더를 설정합니다.
  res.setHeader('Access-Control-Allow-Origin', 'http://example.com');
  // 다른 필요한 CORS 헤더를 설정할 수도 있습니다.
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  // 브라우저에서 사전 요청을 처리하기 위한 헤더를 설정합니다.
  res.setHeader('Access-Control-Allow-Credentials', 'true');

  next();
});

// 실제 라우트 및 미들웨어를 정의합니다.
app.get('/api/data', (req, res) => {
  // 실제 요청을 처리하는 코드
  res.json({ message: 'Hello from the server!' });
});

// 서버를 시작합니다.
const port = 3000;
app.listen(port, () => {
  console.log(`서버가 ${port} 포트에서 실행 중입니다.`);
});

위 예제코드는 자바스크립트를 사용하여 서버측 코드에서 CORS정책을 이용하여 특정 출처에 대한 요청을 허용하는 헤더를 설정하는 예제코드이다.
Node.js의 Express를 사용하는 예제이다.

const express = require('express');
const app = express();

// 미들웨어를 사용하여 CORS 헤더를 설정합니다.
app.use((req, res, next) => {
  // 모든 출처에서의 요청을 허용합니다.
  res.setHeader('Access-Control-Allow-Origin', '*');
  // 다른 필요한 CORS 헤더를 설정할 수도 있습니다.
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  // 브라우저에서 사전 요청을 처리하기 위한 헤더를 설정합니다.
  res.setHeader('Access-Control-Allow-Credentials', 'true');

  next();
});

// 실제 라우트 및 미들웨어를 정의합니다.
app.get('/api/data', (req, res) => {
  // 실제 요청을 처리하는 코드
  res.json({ message: 'Hello from the server!' });
});

// 서버를 시작합니다.
const port = 3000;
app.listen(port, () => {
  console.log(`서버가 ${port} 포트에서 실행 중입니다.`);
});

위 예제코드는 헤더에 *(와일드 카드)를 사용하여 모든 출처에 대한 요청을 허용하는 예제 코드이다.
하지만 이렇게 모든 출처를 허용하면 보안상의 이슈가 발생할 수 있으므로 주의해서 사용해야 한다.
실제 서비스에서는 가능한한 특정 출처에 대해서만 요청을 허용하는 것이 권장된다.

사전 요청(Preflight Request) 예제 코드

사전요청은 브라우저가 실제 요청을 보내기 전에 서버가 요청을 받아들일 수 있는지 확인하기 위해 보내는 HTTP OPTIONS 메서드를 사용한 요청이다.
서버는 이러한 사전 요청에 대한 응답을 제공해야한다.

사전 요청 예쩨

var xhr = new XMLHttpRequest();
xhr.open('POST', 'http://example.com/api/data', true);
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.setRequestHeader('Authorization', 'Bearer <token>');

xhr.onreadystatechange = function () {
  if (xhr.readyState === 4) {
    if (xhr.status === 200) {
      console.log('실제 요청 성공:', xhr.responseText);
    } else {
      console.error('실제 요청 실패:', xhr.status, xhr.statusText);
    }
  }
};

xhr.send(JSON.stringify({ key: 'value' }));

브라우저는 위와 같은 자바스크립트 코드를 실행하여 사전 요청을 보낼 수 있다.
이 코드는 'POST'메서드로 'http://example.com/api/data'엔드포인트에 대한 요청을 보내기 전에 사전 요청을 보낸다.

서버 응답(Server Response) 예제

const express = require('express');
const app = express();

// 사전 요청에 대한 응답을 설정합니다.
app.options('/api/data', (req, res) => {
  // 필요한 CORS 헤더를 설정합니다.
  res.setHeader('Access-Control-Allow-Origin', 'http://example.com');
  res.setHeader('Access-Control-Allow-Methods', 'POST');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  // 브라우저에서 사전 요청을 보낸 후에는 204 No Content 상태 코드로 응답합니다.
  res.status(204).end();
});

// 실제 요청을 처리하는 라우트 및 미들웨어를 정의합니다.
app.post('/api/data', (req, res) => {
  // 실제 요청을 처리하는 코드
  res.json({ message: 'Hello from the server!' });
});

// 서버를 시작합니다.
const port = 3000;
app.listen(port, () => {
  console.log(`서버가 ${port} 포트에서 실행 중입니다.`);
});

위 예제코드는 사전 요청에 대한 응답으로 'OPTIONS'메서드에 대한 헤더를 설정하는 것이다.
Node.js의 Express를 사용하여 서버에서 사전 요청에 대한 응답을 설정하는 예제이다.

'Access-Control-Allow-Origin'헤더를 확인하여 요청을 수락 또는 거부하는 예제 코드

const xhr = new XMLHttpRequest();
xhr.open('GET', 'http://example.com/api/data', true);

xhr.onreadystatechange = function () {
  if (xhr.readyState === 4) {
    if (xhr.status === 200) {
      // 응답이 허용된 출처에서 온 것인지 확인
      const allowedOrigin = xhr.getResponseHeader('Access-Control-Allow-Origin');
      if (allowedOrigin === 'http://example.com') {
        // 허용된 출처에서의 요청인 경우 응답을 처리
        const responseData = xhr.responseText;
        console.log('허용된 출처에서의 응답:', responseData);
      } else {
        // 허용되지 않은 출처에서의 요청인 경우 처리
        console.error('허용되지 않은 출처에서의 요청입니다.');
      }
    } else {
      console.error('요청 실패:', xhr.status, xhr.statusText);
    }
  }
};

xhr.send();

위 예제코드는 브라우저에서 자바스크립트 코드로 응답에 접근하는 경우에 'Access-Control-Allow-Origin'헤더를 확인하여 요청이 허용된 출처에서 온 경우와 그렇지 않은 경우를 처리하는 예제 코드이다.
위 코드에서는 브라우저 콘솔에 메세지를 출력한다.

CORS의 장점

• 보안 강화 : CORS를 통해 웹 애플리케이션은 다른 출처의 리소스에 접근할 때 보안을 강화할 수 있다. 기본적으로 브라우저는 SOP를 적용하여 다른 출처에서의 접근을 제한한다. CORS를 사용하면 이러한 보안 정책을 유연하게 설정할 수 있다.
• 출처 제어 : 웹 서버에서 어떤 출처에서의 요청을 허용할지를 명시적으로 설정할 수 있다. 이를 통해 특정 출처에서만 요청을 허용하고 다른 출처에서의 요청을 차단할 수 있다.
• 규모 확장성 : 웹 애플리케이션의 규모가 커지면 다양한 출처에서의 리소스를 효과적으로 관리해야한다. CORS를 사용하면 여러 출처간의 데이터 교환을 간편하게 할 수 있으므로 웹 애플리케이션의 규모 확장성을 향상시킨다.
• 개발 편의성 : 웹 개발자들은 다른 도메인에서 호스팅된 API나 서비스를 통합하기 위해 CORS를 사용할 수 있다. 이를 통해 다른 서비스의 데이터나 리소스를 활용하여 웹 애플리케이션을 개발할 수 있다.
• 국제화 및 협업 : CORS를 통해 웹 애플리케이션은 다양한 국가와 지역에서 호스팅된 서비스와 협업할 수 있다. 이를 통해 국제화된 웹 애플리케이션을 쉽게 개발하고 유지할 수 있다.
• API공개 : 웹 서비스 제공자는 CORS를 통해 API를 공개하고 다른 개발자들이 쉽게 엑세스할 수 있도록 할 수 있다. 이로써 다양한 애플리케이션이 해당 API를 이용할 수 있다.

CORS의 단점

• 보안 : CORS를 올바르게 구성하지 않으면 보안 문제가 발생할 수 있다. 출처를 올바르게 검증하고 설정하지 않으면 악의적인 출처에서의 요청을 수락할 수 있으며, 이로 인해 보안 취약점이 발생할 수 있다.
• 정책 설정 복잡성 : CORS정책은 다양한 설정 옵션과 헤더를 포함하고 있어 초기에는 혼란스러울 수 있다. 개발자가 올바르게 설정하려면 이러한 정책을 이해하고 구현해야 한다.
• 서버 부담 : CORS정책을 구현하려면 서버측에서 추가적인 구성이 필요하며, 이는 웹 개발자와 서버 관리자에게 추가 부담을 줄 수 있다.
• 외부 API통합 어려움 : 다른 도메인의 외부 API와 통합하기 위해 CORS를 구성해야 하는데, 이를 올바르게 설정하기 위해서는 API제공자의 도움이 필요할 수 있다. 때로는 API제공자가 CORS를 올바르게 설정하지 않아서 통합이 어려울 수 있다.
• 브라우저 지원 : CORS는 브라우저에서 실행되는 매커니즘으로 모든 브라우저에서 완벽하게 지원되지 않을 수 있다. 특히 오래된 브라우저에서 CORS를 제대로 지원하지 않는 경우가 있을 수 있다.
• 테스트 및 디버깅 어려움 : CORS로 인해 리소스 접근이 제한되므로 웹 애플리케이션의 테스트와 디버깅이 어려울 수 있다. 특히 개발환경과 운영환경에서의 차이로 인해 문제가 발생할 수 있다.
• 외부 종속성 : 외부 API에 의존하는 경우, 해당 API에 문제가 발생하면 애플리케이션에 영향을 줄 수 있다. 이러한 종속성을 관리하는 것이 중요하다.

CORS는 웹 개발자들이 자신의 웹 애플리케이션을 다른 출처와 상호 작용할 수 있도록 하기 위한 중요한 도구이며, 서버측과 클라이언트 측에서 설정 및 구성해야 한다.
또한 보안을 유지하면서 필요한 리소스에 대한 접근을 허용하기 위해 조심스럽게 구성해야한다.