보안 정책 : SOP와 CORS

우리가 웹 서핑을 하다 보면 무조건 신뢰할 수 있는 사이트만 들어가는 것은 아니다. 잘 알려진 사이트 말고 한 번도 들어본 적 없는 사이트에 들어갈 수도 있고, 보이스피싱 용도로 URL만 비슷하게 만든 사이트에 접근하게 될 수도 있다.

그런데 만약에 내가 구글에 로그인한 상태에서 피싱 사이트에 들어갔는데 해당 사이트에서 내 구글 로그인 정보에 마음대로 접근할 수 있다면 나의 개인정보가 유출되어 막대한 피해를 일으킬 수도 있다. 때문에 브라우저에서는 기본적으로 SOP라는 보안 정책을 사용한다.

 

그렇다면 SOP란 무엇인가?

동일 출처 정책(Same-Origin Policy)

동일 출처 정책이란 특정 출처(출처 A : 구글)에서 로드된 문서나 스크립트가 다른 출처(출처 B : 티스토리)의 리소스와 상호작용하는 것을 제한하는 정책이다. 즉, 동일 출처 정책이란 이 출처를 기준으로 보안의 적용을 결정하는 정책인 것이다.

또한 이러한 보안적 요소는 브라우저 자체에서 적용되는 거라서 개발자가 따로 적용하지 않음에도 기본적으로 적용되는 보안 정책이기도 하다.

그렇다면 출처란 무엇인가?

웹 보안에서 말하는 출처(Origin)는 웹 콘텐츠(문서, 이미지, 스크립트 등)가 어디에서 왔는지 식별하는 고유한 주소 또는 신분증과 같다고 할 수 있다. 브라우저는 이 출처 정보를 기준으로 서로 다른 출처 간의 상호작용을 제한하여 보안을 유지한다. 

출처를 구성하는 요소

출처를 구성하는 요소는 프로토콜, 호스트, 포트의 3가지 요소인데 이 3가지 요소 중 하나라도 다르다면 다른 출처로 취급한다. 구체적으로 출처(Origin)는 다음 세 가지 요소의 조합으로 결정된다.

• 프로토콜 (Protocol) : http, https 등
• 호스트 (Hostname/Domain) : http://www.naver.com, http://www.google.com, http://www.daum.net 등
• 포트 (Port) : 웹사이트 주소 뒤에 붙는 번호 (예: :80, :443, :8080).
  • 명시적으로 포트 번호가 없으면 프로토콜의 기본 포트가 사용된다. (http는 80, https는 443)
  • 예시 : https://www.naver.com, http://mail.google.com:8080, https://news.daum.net:443
  • 대부분 http나 https라서 포트 번호가 생략된다.

예를 들어 https://www.example.com:443 이라는 출처는

• 프로토콜 : https
• 호스트 : www.example.com
• 포트 : 443

로 구성됐다고 할 수 있다. 만약에 여기서 하나의 요소라도 다르다면 다른 출처가 된다. 호스트가 www.example.net  이라든지 말이다.

출처는 URL인가?

그렇다면 출처는 URL을 말하는 것인가? 하는 의문이 들 수도 있다. 실제로도 출처는 URL과 상당히 유사하다. 하지만 엄밀히 따지면 다르다. URL은 프로토콜, 호스트, 포트, 경로, 쿼리, 프래그먼트 등 여러 요소로 구성되지만, 이 중에서 오직 프로토콜, 호스트, 포트 세 가지만이 '출처(Origin)'를 결정하기 때문이다. 다시 말하면 출처는 URL에 포함되는 개념이며 전체 URL의 형태가 아무리 달라도 프로토콜, 호스트, 포트 3 부분만 동일하다면 동일 출처다.

 

동일 출처 예시

https://example.com:443/page
https://example.com/api/users (같은 프로토콜, 도메인, 포트)
https://example.com:443/products (명시적 포트 번호)

다른 출처 예시

https://example.com:443/page
http://example.com/api (다른 프로토콜)
https://api.example.com/users (다른 서브도메인)
https://example.com:8080/data (다른 포트)

SOP의 목적

그렇다면 브라우저는 어째서 SOP를 사용할까?

 

출처 A의 입장에서 다른 출처 B란 나와 다르며 내가 알지 못하는 무언가다. 출처 B가 악의적인 존재인지 내게 도움이 되는 존재인지는 A의 입장에서는 알 수 없다. 때문에 약간의 편의성을 희생하더라도 기본적으로 접근을 제한해서 근본적인 위험을 제거하는 것이다. 이것은 현실의 집이 열쇠나 비밀번호 같은 보안장치가 불편함에도 사용하는 것과 동일한 맥락이라고 할 수 있다. 집에 문이 없다면 나도 쉽게 들어갈 수 있겠지만 반대로 도둑이 들기도 쉬운 것이다.

 

웹 브라우저의 여러 탭에 각기 다른 출처를 가진 여러 웹페이지가 동시에 열려 있는 상황을 생각해 보면, 이 정책이 왜 중요한지 알 수 있다.

만약에 내가 신뢰할 수 있는 사이트 A(예 : 구글)에 로그인한 상황에서 실수로 신뢰할 수 없는 사이트 B의 URL을 눌러서 새로운 사이트의 탭이 생겼다고 하자. 그런데 이 사이트 B는 악의적인 해커가 다양한 해킹툴을 심어놓은 사이트였다. 이때 SOP가 없어서 다른 사이트간의 리소스 교류가 자유롭다면? 최악의 경우 사이트 A의 아이디와 비밀번호를 비롯한 개인 정보가 모두 해커에게 넘어가서 큰 피해를 입을 수도 있다. 하지만 근본적으로 다른 사이트끼리의 리소스 교류를 막는다면 그 사이트가 아무리 위험한 곳이라도  함부로 사이트 A의 리소스에 접근할 수 없기 때문에 피해를 최소화하거나 특정 유형의 직접적인 피해를 막을 수 있는 것이다.

 

때문에 SOP의 주요 목적이란 다음과 같다고 할 수 있다.

• 악의적인 웹사이트가 사용자의 민감한 정보(예: 쿠키, 개인 데이터)를 다른 사이트에서 임의로 탈취하거나 조작하는 것을 방지한다.
• 예를 들어, 사용자가 은행 웹사이트에 로그인한 상태에서 악성 스크립트가 포함된 다른 웹사이트를 방문했을 때, 해당 스크립트가 은행 웹사이트의 DOM에 직접 접근하거나 데이터를 요청하는 것을 막는다.

SOP는 왜 필요할까? 실제 사례로 보는 보안의 중요성

잘 생각해보면 현실의 웹사이트들은 SOP가 서로 다른 출처 간의 리소스 교류를 막는다고 한 것과 다르게 다양한 출처의 리소스를 자유롭게 사용하고 있는 것 같은 경우가 많다. 예를 들면 블로그에 유튜브의 동영상이 올라와 있는 경우라든지 말이다. 그렇다면 현재 블로그의 사이트와 유튜브의 사이트는 다른 출처를 가지고 있다. 그럼에도 불구하고 멀쩡하게 유튜브의 동영상이 재생된다. 그렇다면 어째서 멀쩡할까? SOP에 따라서 아예 작동이 안 해야 하는 것이 아닌가?

 

사실 이것이야말로 SOP가 영리하게 동작하는 방식이다. 블로그는 유튜브 영상을 <iframe>이라는 액자틀을 통해 화면에 표시할 뿐, SOP 정책 때문에 액자 안의 내용물(사용자의 유튜브 정보 등)을 마음대로 읽거나 조작할 수는 없다. 반대로 유튜브 측에서도 블로그 쪽의 데이터에 접근하는 것이 불가능하다.

물론 유튜브 자체는 신뢰할 수 있는 사이트기 때문에 SOP가 없어도 별 문제가 없었을 수도 있다. 하지만 만약에 유튜브 사이트 자체가 해킹당해서 악성 코드를 유포한다고 쳐보자. 만약에 SOP가 없어서 상호 간 데이터 접근이 자유로웠다면 사용자의 개인 정보를 탈취하거나 블로그의 DOM을 조작하는 등의 피해를 입을 수 있을 것이다.

즉, SOP 덕분에 우리는 다른 사이트의 콘텐츠(유튜브 영상, 구글 지도, 소셜미디어 위젯 등)를 안전하게 가져다 사용할 수 있으면서도, 동시에 보안 위험으로부터 보호받을 수 있는 것이다."

---

그런데 만약 출처가 다른 웹사이트끼리 합법적으로 데이터를 교환해야 할 필요가 있을 때는 어떻게 할까? 이때는 CORS(Cross-Origin Resource Sharing) 라는 별도의 정책을 사용한다. 이것은 마치 집주인(서버)이 "이웃집 사람(특정 출처)에게는 내 집 열쇠를 복사해 줘도 괜찮아"라고 명시적으로 허락해 주는 것과 같다.

CORS란 무엇인가?

CORS는 Cross-Origin Resource Sharing의 줄임말로, 웹 브라우저에서 다른 도메인의 리소스에 접근할 수 있도록 허용하는 보안 메커니즘이다. 브라우저의 동일 출처 정책(Same-Origin Policy)의 제한을 완화하여 안전하게 크로스 오리진 요청(Cross-Origin Request)을 처리한다.

크로스 오리진 요청(Cross-Origin Request)이란?

현재 웹 페이지의 출처와 다른 출처로 리소스를 요청하는 것을 의미한다. 사실상 출처가 다른 경우는 보통 호스트가 다른 경우가 많기 때문에 크로스 도메인 요청 (Cross-Domain Request)으로 표현하기도 한다.

CORS가 필요한 이유

현대 웹 애플리케이션은 여러 도메인의 API와 서비스를 활용한다. 예를 들어

• 프론트엔드: https://myapp.com
• API 서버: https://api.myservice.com

SOP만으로는 이러한 정상적인 크로스 도메인 통신도 막히게 된다. CORS는 보안을 유지하면서도 필요한 크로스 도메인 통신을 허용하는 균형점을 제공한다.

CORS는 SOP를 대체하는 새로운 보안 정책인가?

그렇다면 CORS라는 보안 정책이 SOP를 대체하는 방식인지 의문이 들 수 있을 것이다. 서로 다른 출처의 통신을 허용한다? 그렇다면 SOP와 정면으로 대치되는 것이 아닌가? 하고 말이다. 

결론부터 말하면, 아니다. CORS는 SOP를 대체하는 새로운 보안 정책이 아니라, SOP와 함께 작동하는 보완 메커니즘이다.

CORS와 SOP의 관계

SOP는 여전히 기본 보안 정책

• 브라우저는 기본적으로 SOP를 적용하여 다른 출처 간의 리소스 접근을 차단한다
• CORS가 있어도 SOP가 사라지는 것은 아니다
• 모든 크로스 오리진 요청은 먼저 SOP에 의해 검사 된다

CORS는 SOP의 예외 처리 메커니즘

CORS는 "이 요청은 안전하니까 SOP 예외로 허용해도 괜찮다"라고 서버가 브라우저에게 알려주는 방식으로 동작한다.

1. 브라우저: "다른 출처로 요청을 보내려고 하는데..."
2. SOP: "기본적으로는 차단이야!"
3. 브라우저: "서버야, 이 요청 허용해줄래?"
4. 서버: "CORS 헤더로 답변할게. 허용/차단"
5. 브라우저: "서버가 허용한다니까 SOP 예외로 통과시켜줄게"

협력하는 보안 시스템

• SOP : "기본적으로 모든 크로스 오리진 요청을 차단하자"
• CORS : "서버가 명시적으로 허용한 요청만 예외로 통과시키자"

CORS의 혁신적인 점

표준화된 해결책

• W3C 표준으로 제정된 공식적인 방법
• 모든 모던 브라우저에서 지원

세밀한 제어

// 출처별 세밀한 제어 가능
res.header('Access-Control-Allow-Origin', 'https://trusted-site.com');
res.header('Access-Control-Allow-Methods', 'GET, POST');
res.header('Access-Control-Allow-Headers', 'Content-Type');

보안성과 유연성의 균형

• SOP의 보안성을 유지하면서
• 필요한 크로스 도메인 통신은 안전하게 허용

정리 : CORS는 SOP의 파트너

CORS는 SOP를 개선하거나 대체하는 것이 아니라, SOP와 함께 작동하여 더 안전하고 유연한 웹 보안 환경을 만드는 파트너다.

• SOP : "기본적으로 차단" (보수적 보안)
• CORS : "서버가 허용하면 통과" (제어된 유연성)
• 결과 : 보안을 유지하면서도 현대 웹 개발의 요구사항 충족

---

그렇다면 실제로 CORS는 어떻게 작동해서 SOP를 우회할까?

CORS 동작 방식 : 단순 요청 (Simple Request)

단순 요청은 CORS 명세에 따라 특정 HTTP 메서드(GET, HEAD, POST)와 제한된 헤더 조건을 만족하는 교차 출원 요청을 의미한다. 이러한 요청은 브라우저가 별도의 사전 요청(Preflight Request) 없이 직접 서버에 전송하며, 서버는 응답 시 Access-Control-Allow-Origin 헤더를 통해 해당 요청을 허용할지 결정한다. 현재 웹 개발에서는 이러한 단순 요청을 포함한 모든 네트워크 통신에 fetch API와 Axios 라이브러리가 주로 사용된다. fetch는 브라우저에 내장된 표준 API로 간결한 사용이 장점이며, Axios는 추가적인 기능(인터셉터, 자동 JSON 파싱 등)과 더 편리한 오류 처리를 제공하여 개발자들이 선호하는 외부 라이브러리다.

// 클라이언트 웹 페이지 (https://my-frontend-app.com)에서 실행
fetch('https://api.example.com/weather') // CORS
    .then(response => { // CORS
        // 서버 응답 헤더에 Access-Control-Allow-Origin이 유효하게 있어야 브라우저가 이 응답을 허용한다. // CORS
        if (!response.ok) { // CORS 아님
            throw new Error(`HTTP error! status: ${response.status}`); // CORS 아님
        }
        return response.json(); // CORS 아님
    })
    .then(data => { // CORS 아님
        console.log('날씨 데이터:', data); // CORS 아님
    })
    .catch(error => { // CORS
        // 서버가 CORS 요청을 허용하지 않으면 여기서 CORS 오류가 발생한다. // CORS
        console.error('날씨 데이터를 가져오는 중 오류 발생:', error); // CORS
    });

///실제 cors인 부분
fetch('https://api.example.com/weather') // CORS
.then(response
.catch(error

CORS는 보안정책이기 때문에 요청이 성공했냐 실패했냐까지가 CORS가 작동하는 부분이다. 성공과 실패 이후 작동하는 로직은 CORS와 관계없다.

// POST 요청 예시 (GET이 아니므로 method를 명시해야 한다)
fetch('https://api.example.com/submit', {
    method: 'POST', // 📌 여기서 POST 메서드를 명시적으로 지정
    headers: {
        'Content-Type': 'application/json' // 단순 요청 조건이 아닌 경우 프리플라이트 발생
    },
    body: JSON.stringify({ key: 'value' })
});

허용되는 HTTP 메서드

• GET
• HEAD
• POST

허용되는 헤더

• Accept
• Accept-Language
• Content-Language
• Content-Type (특정 값만)

Content-Type 허용 값

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

CORS 동작 방식 : 프리플라이트 요청 (Preflight Request)

프리플라이트 요청은 CORS 명세에 따라 단순 요청 조건을 만족하지 않는 교차 출원 요청이 실행되기 전에 브라우저가 자동으로 전송하는 OPTIONS 메서드 요청이다. 이는 브라우저의 보안 메커니즘으로, 실제 요청을 보내기 전에 서버가 해당 요청을 허용하는지 사전에 확인하는 과정이다. 서버는 프리플라이트 요청에 대해 허용되는 메서드, 헤더, 출처 등을 응답 헤더로 전달하며, 브라우저는 이를 바탕으로 실제 요청의 전송 여부를 결정한다.

프리플라이트가 필요한 경우

HTTP 메서드

• PUT
• DELETE
• PATCH
• OPTIONS
• 기타 표준이 아닌 메드

허용되지 않는 헤더 사용

• Authorization
• X-Custom-Header (사용자 정의 헤더)
• X-Requested-With
• 기타 단순 요청에서 허용되지 않는 헤더

Content-Type 제한 값

• application/json
• application/xml
• text/xml
• 기타 단순 요청에서 허용되지 않는 Content-Type

프리플라이트 요청/응답 과정

프리플라이트 요청/응답은 브라우저가 자동으로 수행하는 것이라 개발자가 별도로 코드를 작성하는 것이 아니다.

1단계: 프리플라이트 요청 (OPTIONS)

브라우저가 자동으로 전송하는 사전 확인 요청

OPTIONS /api/users/123 HTTP/1.1
Host: api.example.com
Origin: https://my-frontend-app.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization

2단계: 프리플라이트 응답

서버가 허용 정보를 응답 헤더로 전달

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://my-frontend-app.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

3단계: 실제 요청

프리플라이트가 성공하면 원래 요청을 전송

PUT /api/users/123 HTTP/1.1
Host: api.example.com
Origin: https://my-frontend-app.com
Content-Type: application/json
Authorization: Bearer token123

{
  "name": "홍길동",
  "email": "hong@example.com"
}

4단계: 실제 응답

서버가 실제 작업 결과를 응답

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://my-frontend-app.com
Content-Type: application/json

{
  "id": 123,
  "name": "홍길동",
  "email": "hong@example.com",
  "updated": "2025-06-06T10:30:00Z"
}

코드 예시

// 클라이언트 웹 페이지 (https://my-frontend-app.com)에서 실행
fetch('https://api.example.com/users/123', { // CORS
    method: 'PUT', // 프리플라이트 필요 (PUT 메서드)
    headers: {
        'Content-Type': 'application/json', // 프리플라이트 필요 (application/json)
        'Authorization': 'Bearer token123' // 프리플라이트 필요 (사용자 정의 헤더)
    },
    body: JSON.stringify({
        name: '홍길동',
        email: 'hong@example.com'
    })
})
.then(response => { // CORS
    // 프리플라이트와 실제 요청이 모두 성공해야 이 부분이 실행된다. // CORS
    if (!response.ok) { // CORS 아님
        throw new Error(`HTTP error! status: ${response.status}`); // CORS 아님
    }
    return response.json(); // CORS 아님
})
.then(data => { // CORS 아님
    console.log('사용자 데이터 업데이트 완료:', data); // CORS 아님
})
.catch(error => { // CORS
    // 프리플라이트 실패 또는 실제 요청에서 CORS 오류가 발생하면 여기서 처리된다. // CORS
    console.error('사용자 데이터 업데이트 중 오류 발생:', error); // CORS
});

// 실제 CORS인 부분
fetch('https://api.example.com/users/123', {
    method: 'PUT',
    headers: { ... }
}) // CORS
.then(response => { // CORS
.catch(error => { // CORS

프리플라이트 요청 헤더

요청 헤더

• Origin: 요청을 보내는 출처 (브라우저가 자동 추가)
• Access-Control-Request-Method: 실제 요청에서 사용할 HTTP 메서드
• Access-Control-Request-Headers: 실제 요청에서 사용할 헤더 목록

응답 헤더

• Access-Control-Allow-Origin: 허용되는 출처
• Access-Control-Allow-Methods: 허용되는 HTTP 메서드
• Access-Control-Allow-Headers: 허용되는 요청 헤더
• Access-Control-Max-Age: 프리플라이트 응답 캐시 시간 (초)
• Access-Control-Allow-Credentials: 인증 정보 포함 요청 허용 여부

개발 시 고려사항

성능 최적화

• 프리플라이트 응답 캐시 시간(Access-Control-Max-Age) 설정
• 가능하면 단순 요청 조건을 만족하도록 설계

보안 고려

• Access-Control-Allow-Origin: *는 인증 정보와 함께 사용 불가
• 필요한 헤더만 Access-Control-Allow-Headers에 포함

디버깅

• 브라우저 개발자 도구 Network 탭에서 OPTIONS 요청 확인
• 프리플라이트 실패 시 실제 요청은 전송되지 않음

CORS는 브라우저의 보안 정책이기 때문에 프리플라이트 요청의 성공/실패와 실제 요청의 성공/실패까지가 CORS가 작동하는 부분이다. 응답 데이터 처리나 비즈니스 로직은 CORS와 무관하다.

CORS 구현 예시

Node.js/Express 서버

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

// 모든 출처 허용
app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', '*');
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});

// 특정 출처만 허용
app.use((req, res, next) => {
  const allowedOrigins = ['https://myapp.com', 'https://localhost:3000'];
  const origin = req.headers.origin;
  
  if (allowedOrigins.includes(origin)) {
    res.header('Access-Control-Allow-Origin', origin);
  }
  
  res.header('Access-Control-Allow-Credentials', 'true');
  next();
});

// CORS 라이브러리 사용
const cors = require('cors');

const corsOptions = {
  origin: ['https://myapp.com', 'https://localhost:3000'],
  credentials: true,
  optionsSuccessStatus: 200
};

app.use(cors(corsOptions));

Spring Boot 서버

@Configuration
public class CorsConfig {
    
    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration configuration = new CorsConfiguration();
        configuration.setAllowedOrigins(Arrays.asList("https://myapp.com"));
        configuration.setAllowedMethods(Arrays.asList("GET", "POST", "PUT", "DELETE"));
        configuration.setAllowedHeaders(Arrays.asList("*"));
        configuration.setAllowCredentials(true);
        
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration);
        return source;
    }
}

// 컨트롤러에서 개별 설정
@RestController
@CrossOrigin(origins = "https://myapp.com", allowCredentials = "true")
public class ApiController {
    // API 메서드들
}

클라이언트 JavaScript

// 단순 요청
fetch('https://api.example.com/data', {
  method: 'GET',
  headers: {
    'Content-Type': 'text/plain'
  }
})
.then(response => response.json())
.then(data => console.log(data));

// 프리플라이트가 필요한 요청
fetch('https://api.example.com/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer token123'
  },
  body: JSON.stringify({ name: 'John', age: 30 })
})
.then(response => response.json())
.then(data => console.log(data));

// 인증 정보 포함 요청
fetch('https://api.example.com/profile', {
  method: 'GET',
  credentials: 'include' // 쿠키 포함
})
.then(response => response.json())
.then(data => console.log(data));

일반적인 CORS 문제와 해결방법

"Access to fetch at 'URL' from origin 'ORIGIN' has been blocked by CORS policy"

원인: 서버에서 해당 출처를 허용하지 않음

해결방법:

• 서버에 적절한 Access-Control-Allow-Origin 헤더 설정
• 개발 환경에서는 프록시 설정 사용

"Request header field content-type is not allowed by Access-Control-Allow-Headers"

원인: 서버에서 해당 헤더를 허용하지 않음

해결방법:

• 서버의 Access-Control-Allow-Headers에 필요한 헤더 추가

인증 정보 관련 오류

원인: credentials: 'include'와 Access-Control-Allow-Origin: '*' 동시 사용

해결방법:

• 인증 정보를 사용할 때는 구체적인 출처 지정
• Access-Control-Allow-Credentials: true 설정

보안 고려사항

와일드카드 사용 주의

Access-Control-Allow-Origin: *는 편리하지만 보안상 위험할 수 있다. 가능한 한 구체적인 출처를 지정한다.

인증 정보 처리

쿠키나 Authorization 헤더를 포함하는 요청의 경우, 반드시 구체적인 출처를 지정하고 Access-Control-Allow-Credentials를 true로 설정한다.

헤더 노출 제한

Access-Control-Expose-Headers를 통해 필요한 헤더만 클라이언트에 노출한다.

개발 환경에서의 CORS 우회

개발 서버 프록시 설정

Webpack Dev Server:

module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:3001',
        changeOrigin: true
      }
    }
  }
};

Create React App:

// package.json
{
  "name": "my-app",
  "proxy": "http://localhost:3001"
}

브라우저 확장 프로그램

개발 중에만 CORS를 비활성화하는 브라우저 확장 프로그램을 사용할 수 있지만, 실제 사용자 환경과 다르므로 주의해야 한다.

모범 사례

최소 권한 원칙

필요한 최소한의 출처, 메서드, 헤더만 허용한다.

환경별 설정

개발, 스테이징, 프로덕션 환경에 따라 다른 CORS 설정을 사용한다.

정기적인 검토

허용된 출처 목록을 정기적으로 검토하고 불필요한 항목을 제거한다.

로깅과 모니터링

CORS 관련 요청과 오류를 로깅하여 문제를 빠르게 파악한다.

결론

CORS는 현대 웹 개발에서 필수적인 개념이다. 보안을 유지하면서도 필요한 크로스 도메인 통신을 가능하게 하는 중요한 메커니즘이다. 적절한 이해와 구현을 통해 안전하고 효율적인 웹 애플리케이션을 개발할 수 있다.