CORS 이해하기: 현대 사이트를 위한 안전한 크로스 오리진 설정

크로스 오리진 리소스 공유(CORS)는 많은 팀이 브라우저 보안을 처음 만나는 곳입니다 — 대개 뭔가 깨졌고 가장 빠른 검색 결과가 '그냥 모든 오리진을 허용하라'고 하기 때문입니다. 그 해결책은 동작하며 조용히 취약점이 됩니다. 이 글은 CORS가 실제로 하는 일과, API를 인터넷의 모든 사이트에 열지 않고 설정하는 법을 설명합니다.

CORS가 실제로 통제하는 것

CORS는 서버 측 접근 제어가 아닙니다. 오리진 A에서 실행되는 JavaScript가 오리진 B의 응답을 *읽도록* 허용할지 결정하는 브라우저 메커니즘입니다. curl, 서버, 또는 브라우저를 무시하는 스크립트의 직접 요청은 전혀 막지 못합니다. 브라우저 클라이언트를 위한 가드레일로 보고, 실제 인가는 어떻든 서버에 두세요.

와일드카드+자격 증명의 함정

가장 위험한 단일 CORS 설정은 요청 오리진을 반사하면서 자격 증명도 허용하는 것입니다:

Access-Control-Allow-Origin: https://evil.example
Access-Control-Allow-Credentials: true

서버가 받은 Origin을 그대로 돌려주고 Allow-Credentials: true를 설정하면, 어떤 사이트든 로그인한 사용자로서 인증된 요청을 보내 응답을 읽을 수 있습니다. 브라우저가 리터럴 *와 자격 증명의 병용을 금지하는 이유가 이것입니다 — 그러나 오리진 반사는 그 안전장치를 우회해 구멍을 다시 만듭니다.

올바르고 제한적인 설정

들어오는 오리진을 명시적 허용 목록과 대조하고, 그때만 반사하세요:

const allowed = new Set([
  'https://app.example.com',
  'https://admin.example.com',
]);

const origin = req.headers.get('origin');
if (origin && allowed.has(origin)) {
  res.setHeader('Access-Control-Allow-Origin', origin);
  res.setHeader('Vary', 'Origin');
  res.setHeader('Access-Control-Allow-Credentials', 'true');
}

Vary: Origin 헤더는 잊기 쉽지만 중요합니다. 이것이 없으면 캐시가 한 오리진의 허용 헤더를 다른 오리진에 제공할 수 있습니다.

메서드와 헤더도 좁히세요

Access-Control-Allow-Origin은 정책의 절반일 뿐입니다. 나머지도 빡빡하게 유지하세요:

• 엔드포인트가 쓰는 메서드만 허용하세요. 예: Access-Control-Allow-Methods: GET, POST.
• 예상하는 요청 헤더만 허용하고, 전면 허용은 하지 마세요.
• 합리적인 Access-Control-Max-Age를 설정해 프리플라이트가 캐시되게 하세요.
• Allow-Origin: *와 Allow-Credentials: true를 절대 결합하지 마세요.

와일드카드가 실제로 괜찮을 때

진정으로 공개되고 인증이 없으며 읽기 전용인 API — 환율 피드, 공개 상태 엔드포인트 — 는 Access-Control-Allow-Origin: *를 안전하게 쓸 수 있습니다. 바로 자격 증명이 없고 유출될 비공개 정보가 없기 때문입니다. 위험은 언제나 * 식 개방과 인증의 결합에만 있습니다.

실제 크로스 오리진 환경에서 테스트하세요

CORS는 단순 요청과 프리플라이트 요청에서 다르게 동작하므로, 다른 오리진의 브라우저에서 둘 다 테스트하세요. CORS를 완전히 무시하는 curl만으로는 부족합니다. 스캔은 나머지 보안 검사와 함께 CORS 응답 헤더를 자동으로 확인합니다. CORS 발견 항목이 우선순위 수정 목록에 어떻게 들어가는지는 웹사이트 보안 스캔 보고서 읽는 법을 읽어 보세요.