기술사 학습노트 | imt-log

기술사 학습노트›시스템아키텍처›CORS

System Architecture · 정보관리기술사 / 컴퓨터시스템응용기술사

CORS 교차 출처 리소스 공유 동작 원리와 보안 아키텍처

브라우저 동일 출처 정책, Preflight 요청, Access-Control-Allow-* 헤더, 인증정보 포함 요청, 운영 보안 설정을 답안형 구조로 정리한다.

정보관리기술사컴퓨터시스템응용기술사CORSSOPPreflightOriginHTTP헤더웹보안API보안인증쿠키

Ⅰ. 개요 및 등장배경

가. 개념

CORS(Cross-Origin Resource Sharing)는 브라우저가 적용하는 동일 출처 정책(SOP)을 전제로, 서버가 신뢰 가능한 다른 출처의 접근을 HTTP 응답 헤더로 허용하는 웹 보안 메커니즘이다. 출처는 프로토콜, 호스트, 포트의 조합으로 판단하며, 셋 중 하나라도 다르면 다른 출처로 본다. 예를 들어 https://app.example.com에서 https://api.example.com으로 호출하면 호스트가 다르므로 교차 출처 요청이 된다.

중요한 점은 CORS가 서버 간 통신 제한 기능이 아니라는 것이다. 서버에서 curl, 배치, 백엔드 API로 다른 서버를 호출하는 행위는 CORS 차단 대상이 아니다. CORS 오류는 브라우저가 자바스크립트에 응답을 노출할지 판단하는 과정에서 발생한다. 따라서 기술사 답안에서는 브라우저 정책 + 서버 허용 헤더 + 클라이언트 요청 조건의 결합 구조로 설명해야 한다.

나. 특징

• 브라우저 중심 통제: 요청은 전송될 수 있으나 응답을 스크립트에 노출할지는 브라우저가 판단한다.
• 서버 명시 허용: Access-Control-Allow-Origin, Allow-Methods, Allow-Headers 등 응답 헤더로 허용 범위를 표현한다.
• Preflight 기반 검증: PUT, DELETE, JSON, 커스텀 헤더 등 위험도가 높은 요청은 OPTIONS 사전 요청으로 허용 여부를 확인한다.
• 인증정보 제약: 쿠키·Authorization 헤더를 포함하려면 Credentials 설정과 특정 Origin 허용이 함께 필요하며, 와일드카드(*)와 병행할 수 없다.
• 최소 권한 원칙: 운영 환경에서는 전체 허용보다 도메인, 메서드, 헤더, 캐시 시간을 제한해야 한다.

CORS는 프론트엔드와 백엔드가 분리된 웹 구조에서 SOP를 안전하게 완화하는 장치이다.
고득점 답안은 “브라우저가 차단한다”에서 끝내지 말고 Origin, Preflight, 응답 헤더, 인증정보 조건을 함께 설명해야 한다.

Ⅱ. 구성도 및 구성요소

가. 구성도

나. 구성요소

구분	요소	설명
정책	SOP	동일 출처가 아닌 자원 접근을 기본 차단하는 브라우저 보안 정책이다.
요청	Origin Header	브라우저가 요청 출처를 서버에 전달하여 서버가 허용 여부를 판단하게 한다.
사전검증	Preflight OPTIONS	실제 요청 전 메서드와 헤더가 허용되는지 확인하는 사전 질의이다.
응답	Access-Control-Allow-Origin	응답을 노출할 수 있는 출처를 명시한다. 인증정보 포함 시 * 사용이 제한된다.
응답	Access-Control-Allow-Methods	교차 출처에서 허용할 GET, POST, PUT, DELETE 등 HTTP 메서드를 지정한다.
응답	Access-Control-Allow-Headers	Authorization, Content-Type 등 클라이언트가 사용할 수 있는 요청 헤더를 지정한다.
성능	Access-Control-Max-Age	Preflight 결과 캐시 시간을 지정하여 OPTIONS 요청 빈도를 줄인다.
인증	Credentials	쿠키, 인증 헤더, 클라이언트 인증서 포함 여부를 제어하며 서버의 명시 허용이 필요하다.

CORS 구성도는 단순히 클라이언트와 서버 연결을 그리는 것보다 Preflight와 실제 요청을 분리해야 점수가 높다.
구성요소 표에서는 Origin, Allow-Origin, Allow-Methods, Allow-Headers, Max-Age, Credentials의 역할을 구분한다.

Ⅲ. 동작방식 및 아키텍처

가. 요청 유형별 동작

CORS 요청은 단순 요청, Preflight 요청, 인증정보 포함 요청으로 나누어 설명할 수 있다. 단순 요청은 GET, HEAD, 일부 POST와 제한된 헤더·MIME 타입을 사용할 때 발생하며, 브라우저가 바로 실제 요청을 전송한 뒤 응답 헤더를 검사한다. 반면 JSON 전송, PUT·DELETE, Authorization 헤더, 커스텀 헤더가 포함되면 브라우저는 실제 요청 전에 OPTIONS 요청을 보내 서버가 해당 조건을 허용하는지 확인한다.

• 단순 요청: Origin을 포함한 실제 요청을 보내고 응답의 Allow-Origin으로 노출 여부를 결정한다.
• Preflight 요청: OPTIONS 요청에 Access-Control-Request-Method, Access-Control-Request-Headers를 담아 사전 허용 여부를 질의한다.
• 실제 요청: 사전 요청이 통과하면 본 요청을 보내고, 최종 응답에서도 CORS 헤더를 확인한다.
• 인증정보 포함 요청: 클라이언트의 credentials 옵션과 서버의 Access-Control-Allow-Credentials: true가 함께 필요하다.

나. 보안 아키텍처 관점

CORS는 인증·인가 자체를 대체하지 않는다. CORS가 허용되더라도 서버는 세션, 토큰, 권한, CSRF 방어를 별도로 수행해야 한다. 반대로 CORS가 차단되어도 악성 사용자가 서버로 직접 요청을 보낼 수 있으므로, API 서버는 브라우저 차단에 의존하지 않는 서버 측 접근통제를 갖추어야 한다. 운영 구조에서는 API Gateway, WAF, 인증 서버, 백엔드 서비스가 함께 적용되며, Gateway에서 Origin 화이트리스트와 메서드 정책을 공통 적용하는 방식이 관리에 유리하다.

시험 답안 포인트: “CORS 에러 해결 = 프론트 코드 수정”으로 쓰면 감점 가능성이 높다. 본질은 서버가 응답 헤더로 허용 범위를 명시하고, 브라우저가 SOP 기준으로 응답 노출 여부를 결정하는 구조이다.

CORS 동작은 OPTIONS 사전 확인과 실제 요청 처리의 2단계로 설명하는 것이 명확하다.
보안 아키텍처에서는 CORS, 인증·인가, CSRF 방어, API Gateway 정책을 분리하여 서술해야 한다.

Ⅳ. 실무적용 및 사례

가. 프론트엔드·백엔드 분리 환경

SPA, 모바일 웹, MSA 기반 서비스에서는 화면 애플리케이션과 API 서버의 도메인이 분리되는 경우가 많다. 예를 들어 프론트엔드는 cdn.example.com, API는 api.example.com, 인증은 auth.example.com으로 나뉠 수 있다. 이때 API 서버는 허용할 Origin 목록을 환경별로 분리해야 한다. 개발 환경에서는 localhost를 허용하더라도 운영 환경에서는 실제 서비스 도메인만 허용하고, 임시 테스트 도메인이나 전체 와일드카드를 남겨두지 않아야 한다.

나. 운영 설정 원칙

• Origin 화이트리스트: 운영 도메인, 관리자 도메인, 파트너 도메인을 명시적으로 관리한다.
• 메서드 최소화: 조회 API는 GET 중심, 변경 API는 필요한 POST·PUT·DELETE만 허용한다.
• 헤더 제한: Authorization, Content-Type 등 필요한 헤더만 허용하고 불필요한 커스텀 헤더를 줄인다.
• Credentials 관리: 쿠키 기반 인증은 SameSite, Secure, HttpOnly 속성과 함께 검토한다.
• Preflight 캐시: Max-Age를 활용해 성능을 높이되 정책 변경 시 영향 범위를 고려한다.
• 로그·모니터링: Origin 불일치, 허용되지 않은 메서드, 반복 OPTIONS 실패를 보안 이벤트로 확인한다.

다. 대표 오류와 조치

구분	현상	조치
Origin 미허용	No Access-Control-Allow-Origin 오류	서버 또는 Gateway에서 허용 Origin 추가
메서드 불일치	PUT/DELETE 요청 실패	Allow-Methods에 실제 요청 메서드 반영
헤더 불일치	Authorization 또는 커스텀 헤더 실패	Allow-Headers에 필요한 헤더만 명시
인증정보 오류	쿠키 포함 요청 차단	Credentials true, 특정 Origin, 쿠키 속성 동시 검토
프록시 혼선	개발에서는 정상, 운영에서 실패	개발 프록시 의존 설정을 운영 CORS 정책으로 전환

실무에서는 CORS를 개발 편의 설정이 아니라 API 노출면을 통제하는 운영 정책으로 관리해야 한다.
Origin, Method, Header, Credentials, Max-Age를 환경별로 분리하면 장애와 보안 위험을 줄일 수 있다.

Ⅴ. 비교분석 및 발전전망

가. SOP, CORS, CSRF 비교

구분	요소	설명
SOP	동일 출처 정책	브라우저가 다른 출처의 응답을 스크립트에 노출하지 않는 기본 보안 모델이다.
CORS	교차 출처 허용	서버가 허용 출처와 조건을 명시하여 SOP를 통제적으로 완화한다.
CSRF	요청 위조 공격	사용자 인증 상태를 악용해 원치 않는 요청을 보내는 공격으로, CORS와 별도 방어가 필요하다.
SameSite	쿠키 전송 제어	교차 사이트 요청에서 쿠키 전송 범위를 제한하여 CSRF 위험을 낮춘다.
API Gateway	중앙 정책 집행	여러 서비스의 CORS 정책을 일관되게 적용하고 인증·라우팅·로깅과 결합한다.

나. 발전전망

웹 애플리케이션이 SPA, BFF, MSA, 클라우드 네이티브 구조로 확장되면서 CORS 설정은 단일 서버 옵션이 아니라 아키텍처 정책으로 다뤄지고 있다. 특히 API Gateway와 Ingress Controller에서 Origin 정책을 중앙화하고, 인증 서버와 쿠키 속성을 함께 설계하는 방식이 중요해졌다. 또한 브라우저 보안 정책은 SameSite 쿠키, COOP, COEP, CSP 등과 결합되어 더 세밀한 격리 모델로 발전하고 있다.

향후에는 서비스 간 API 호출, 외부 파트너 연동, 클라우드 API 노출, 프론트엔드 배포 자동화가 늘어나면서 CORS 정책도 코드형 인프라와 보안 검증 파이프라인에 포함될 가능성이 높다. 따라서 기술사 답안에서는 CORS를 단순 오류 해결 주제가 아니라 웹 보안 아키텍처, API 거버넌스, 프론트엔드·백엔드 분리 구조의 연결 주제로 제시하는 것이 바람직하다.

CORS는 SOP를 무력화하는 기능이 아니라 서버가 허용한 범위 안에서 교차 출처 접근을 통제하는 방식이다.
향후 API Gateway, CSP, SameSite, 인증·인가 정책과 결합된 웹 보안 아키텍처 요소로 중요성이 커진다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← 시스템아키텍처 목록