CORS 완전 정복: 자바스크립트 프리플라이트(Preflight) 요청 핸들링 심층 분석

끊임없이 확장하는 웹 개발의 세계에서 보안은 가장 중요합니다. 교차 출처 리소스 공유(CORS)는 웹 페이지가 해당 페이지를 제공한 도메인과 다른 도메인으로 요청하는 것을 제한하기 위해 웹 브라우저에 의해 구현된 중요한 보안 메커니즘입니다. 이것은 악의적인 웹사이트가 민감한 데이터에 접근하는 것을 방지하기 위해 설계된 기본적인 보안 기능입니다. 이 종합 가이드에서는 CORS의 복잡성을 깊이 파고들어, 특히 프리플라이트 요청 핸들링에 초점을 맞출 것입니다. 우리는 전 세계 개발자들이 직면하는 일반적인 문제에 대한 실용적인 예제와 해결책을 제공하며 CORS의 '이유', '무엇', '방법'을 탐구할 것입니다.

동일 출처 정책(Same-Origin Policy) 이해하기

CORS의 핵심에는 동일 출처 정책(Same-Origin Policy, SOP)이 있습니다. 이 정책은 한 출처에서 실행되는 스크립트가 다른 출처의 리소스에 접근하는 것을 제한하는 브라우저 수준의 보안 메커니즘입니다. 출처(Origin)는 프로토콜(예: HTTP 또는 HTTPS), 도메인(예: example.com), 그리고 포트(예: 80 또는 443)에 의해 정의됩니다. 두 URL은 이 세 가지 구성 요소가 정확히 일치할 때 동일한 출처를 가집니다.

예를 들면 다음과 같습니다:

• https://www.example.com/app1/index.html와 https://www.example.com/app2/index.html는 동일한 출처를 가집니다 (프로토콜, 도메인, 포트 동일).
• https://www.example.com/index.html와 http://www.example.com/index.html는 다른 출처를 가집니다 (프로토콜 다름).
• https://www.example.com/index.html와 https://api.example.com/index.html는 다른 출처를 가집니다 (서브도메인은 다른 도메인으로 간주됨).
• https://www.example.com:8080/index.html와 https://www.example.com/index.html는 다른 출처를 가집니다 (포트 다름).

SOP는 한 웹사이트의 악의적인 스크립트가 다른 웹사이트의 쿠키나 사용자 인증 정보와 같은 민감한 데이터에 접근하는 것을 방지하기 위해 설계되었습니다. 보안에 필수적이지만, SOP는 합법적인 교차 출처 요청이 필요할 때 제한적일 수도 있습니다.

교차 출처 리소스 공유(CORS)란 무엇인가?

CORS는 서버가 어떤 출처(도메인, 스킴 또는 포트)가 자신의 리소스에 접근할 수 있는지 명시할 수 있게 하는 메커니즘입니다. 이는 본질적으로 SOP를 완화하여 통제된 교차 출처 접근을 허용합니다. CORS는 클라이언트(일반적으로 웹 브라우저)와 서버 간에 교환되는 HTTP 헤더를 사용하여 구현됩니다.

브라우저가 교차 출처 요청(즉, 현재 페이지와 다른 출처로의 요청)을 할 때, 먼저 서버가 해당 요청을 허용하는지 확인합니다. 이는 서버 응답의 Access-Control-Allow-Origin 헤더를 검사하여 수행됩니다. 만약 요청의 출처가 이 헤더에 명시되어 있거나 헤더가 모든 출처를 허용하는 *로 설정되어 있다면, 브라우저는 요청을 계속 진행하도록 허용합니다. 그렇지 않으면 브라우저는 요청을 차단하여 자바스크립트 코드가 응답 데이터에 접근하는 것을 막습니다.

프리플라이트 요청(Preflight Request)의 역할

특정 유형의 교차 출처 요청에 대해 브라우저는 프리플라이트 요청(preflight request)을 시작합니다. 이는 실제 요청 전에 서버로 전송되는 OPTIONS 요청입니다. 프리플라이트 요청의 목적은 서버가 실제 요청을 수락할 의사가 있는지 확인하는 것입니다. 서버는 허용된 메소드, 헤더 및 기타 제한 사항에 대한 정보와 함께 프리플라이트 요청에 응답합니다.

프리플라이트 요청은 교차 출처 요청이 다음 조건 중 하나라도 충족할 때 트리거됩니다:

• 요청 메소드가 GET, HEAD, 또는 POST가 아닐 경우.
• 요청에 사용자 지정 헤더(즉, 브라우저가 자동으로 추가하는 헤더 이외의 헤더)가 포함된 경우.
• Content-Type 헤더가 application/x-www-form-urlencoded, multipart/form-data, 또는 text/plain 이외의 값으로 설정된 경우.
• 요청 본문에 ReadableStream 객체를 사용하는 경우.

예를 들어, Content-Type이 application/json인 PUT 요청은 허용된 메소드와 다른 메소드를 사용하고 잠재적으로 허용되지 않는 콘텐츠 유형을 사용하기 때문에 프리플라이트 요청을 트리거합니다.

왜 프리플라이트 요청을 사용하는가?

프리플라이트 요청은 서버가 잠재적으로 해로운 교차 출처 요청을 실행하기 전에 거부할 기회를 제공하기 때문에 보안에 필수적입니다. 프리플라이트 요청이 없다면, 악의적인 웹사이트가 서버의 명시적인 동의 없이 서버에 임의의 요청을 보낼 수 있습니다. 프리플라이트 요청은 서버가 해당 요청이 수용 가능한지 검증하고 잠재적으로 해로운 작업을 방지할 수 있게 해줍니다.

서버 측에서 프리플라이트 요청 처리하기

프리플라이트 요청을 올바르게 처리하는 것은 웹 애플리케이션이 정확하고 안전하게 작동하도록 보장하는 데 매우 중요합니다. 서버는 실제 요청이 허용되는지 여부를 나타내기 위해 적절한 CORS 헤더와 함께 OPTIONS 요청에 응답해야 합니다.

다음은 프리플라이트 응답에 사용되는 주요 CORS 헤더에 대한 설명입니다:

• Access-Control-Allow-Origin: 이 헤더는 리소스에 접근할 수 있도록 허용된 출처를 명시합니다. 특정 출처(예: https://www.example.com) 또는 모든 출처를 허용하는 *로 설정할 수 있습니다. 그러나 서버가 민감한 데이터를 처리하는 경우, 보안상의 이유로 * 사용은 일반적으로 권장되지 않습니다.
• Access-Control-Allow-Methods: 이 헤더는 교차 출처 요청에 허용되는 HTTP 메소드(예: GET, POST, PUT, DELETE)를 명시합니다.
• Access-Control-Allow-Headers: 이 헤더는 실제 요청에서 허용되는 비표준 HTTP 헤더 목록을 명시합니다. 이는 클라이언트가 X-Custom-Header 또는 Authorization과 같은 사용자 지정 헤더를 보내는 경우에 필요합니다.
• Access-Control-Allow-Credentials: 이 헤더는 실제 요청에 쿠키나 인증 헤더와 같은 자격 증명을 포함할 수 있는지 여부를 나타냅니다. 클라이언트 측 코드가 자격 증명을 보내고 서버가 이를 수락해야 하는 경우 true로 설정해야 합니다. 참고: 이 헤더가 `true`로 설정되면, `Access-Control-Allow-Origin`은 `*`로 설정될 수 *없습니다*. 출처를 반드시 명시해야 합니다.
• Access-Control-Max-Age: 이 헤더는 브라우저가 프리플라이트 응답을 캐시할 수 있는 최대 시간(초)을 명시합니다. 이는 전송되는 프리플라이트 요청의 수를 줄여 성능을 향상시키는 데 도움이 될 수 있습니다.

예제: Node.js와 Express에서 프리플라이트 요청 처리하기

다음은 Express 프레임워크를 사용하는 Node.js 애플리케이션에서 프리플라이트 요청을 처리하는 방법의 예제입니다:

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

// 모든 출처에 대해 CORS 활성화 (개발 목적으로만 사용!)
// 프로덕션 환경에서는 보안 강화를 위해 허용된 출처를 명시해야 합니다.
app.use(cors()); // 또는 app.use(cors({origin: 'https://www.example.com'}));

// OPTIONS 요청(프리플라이트)을 처리하는 라우트
app.options('/data', cors()); // 단일 라우트에 대해 CORS 활성화. 또는 출처 명시: cors({origin: 'https://www.example.com'})

// GET 요청을 처리하는 라우트
app.get('/data', (req, res) => {
  res.json({ message: '이것은 교차 출처 데이터입니다!' });
});


// 프리플라이트 및 삭제 요청을 처리하는 라우트
app.options('/resource', cors()); // DELETE 요청에 대한 프리플라이트 요청 활성화
app.delete('/resource', cors(), (req, res, next) => {
  res.send('리소스 삭제')
})


const port = 3000;
app.listen(port, () => {
  console.log(`서버가 ${port} 포트에서 수신 대기 중입니다`);
});

이 예제에서는 cors 미들웨어를 사용하여 CORS 요청을 처리합니다. 더 세분화된 제어를 위해 라우트별로 CORS를 활성화할 수 있습니다. 참고: 프로덕션 환경에서는 모든 출처를 허용하는 대신 origin 옵션을 사용하여 허용된 출처를 명시하는 것이 강력히 권장됩니다. *를 사용하여 모든 출처를 허용하면 애플리케이션이 보안 취약점에 노출될 수 있습니다.

예제: Python과 Flask에서 프리플라이트 요청 처리하기

다음은 Flask 프레임워크와 flask_cors 확장을 사용하는 Python 애플리케이션에서 프리플라이트 요청을 처리하는 방법의 예제입니다:

from flask import Flask, jsonify
from flask_cors import CORS, cross_origin

app = Flask(__name__)
CORS(app)  # 모든 라우트에 대해 CORS 활성화

@app.route('/data')
@cross_origin()
def get_data():
    data = {"message": "이것은 교차 출처 데이터입니다!"}
    return jsonify(data)

if __name__ == '__main__':
    app.run(debug=True)

이것이 가장 간단한 사용법입니다. 이전과 마찬가지로 출처를 제한할 수 있습니다. 자세한 내용은 flask-cors 문서를 참조하십시오.

예제: Java와 Spring Boot에서 프리플라이트 요청 처리하기

다음은 Spring Boot를 사용하는 Java 애플리케이션에서 프리플라이트 요청을 처리하는 방법의 예제입니다:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@SpringBootApplication
public class CorsApplication {

    public static void main(String[] args) {
        SpringApplication.run(CorsApplication.class, args);
    }

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/data").allowedOrigins("http://localhost:8080");
            }
        };
    }
}

그리고 해당 컨트롤러는 다음과 같습니다:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DataController {

    @GetMapping("/data")
    public String getData() {
        return "이것은 교차 출처 데이터입니다!";
    }
}

일반적인 CORS 문제와 해결책

중요성에도 불구하고 CORS는 종종 개발자들에게 좌절의 원인이 될 수 있습니다. 다음은 일반적인 CORS 문제와 그 해결책입니다:

1. 오류: "No 'Access-Control-Allow-Origin' header is present on the requested resource."

   이 오류는 서버가 응답에 Access-Control-Allow-Origin 헤더를 반환하지 않음을 나타냅니다. 이를 해결하려면 서버가 헤더를 포함하도록 구성되었는지, 그리고 올바른 출처 또는 *(적절한 경우)로 설정되었는지 확인해야 합니다.

   해결책: 서버가 응답에 `Access-Control-Allow-Origin` 헤더를 포함하도록 설정하고, 요청하는 웹사이트의 출처나 모든 출처를 허용하는 `*`(주의해서 사용)로 설정되었는지 확인합니다.

2. 오류: "Response to preflight request doesn't pass access control check: Request header field X-Custom-Header is not allowed by Access-Control-Allow-Headers in preflight response."

   이 오류는 서버가 교차 출처 요청에서 사용자 지정 헤더(이 예에서는 X-Custom-Header)를 허용하지 않음을 나타냅니다. 이를 해결하려면 서버가 프리플라이트 응답의 Access-Control-Allow-Headers 헤더에 해당 헤더를 포함하도록 해야 합니다.

   해결책: 서버의 프리플라이트 응답에서 `Access-Control-Allow-Headers` 헤더에 사용자 지정 헤더(예: `X-Custom-Header`)를 추가합니다.

3. 오류: "Credentials flag is 'true', but the 'Access-Control-Allow-Origin' header is '*'."

   Access-Control-Allow-Credentials 헤더가 true로 설정된 경우, Access-Control-Allow-Origin 헤더는 *가 아닌 특정 출처로 설정되어야 합니다. 이는 모든 출처로부터의 자격 증명을 허용하는 것이 보안 위험이 되기 때문입니다.

   해결책: 자격 증명을 사용할 때는 `Access-Control-Allow-Origin`을 `*` 대신 특정 출처로 설정합니다.

4. 프리플라이트 요청이 전송되지 않습니다.

   자바스크립트 코드에 `credentials: 'include'` 속성이 포함되어 있는지 다시 확인하십시오. 또한 서버가 `Access-Control-Allow-Credentials: true`를 허용하는지 확인하십시오.

5. 서버와 클라이언트 간의 설정 충돌.

   서버 측 CORS 구성과 클라이언트 측 설정을 신중하게 확인하십시오. 불일치(예: 서버는 GET 요청만 허용하는데 클라이언트가 POST를 보내는 경우)는 CORS 오류를 유발합니다.

CORS와 보안 모범 사례

CORS가 통제된 교차 출처 접근을 허용하지만, 취약점을 방지하기 위해 보안 모범 사례를 따르는 것이 중요합니다:

• 프로덕션 환경에서는 Access-Control-Allow-Origin 헤더에 *를 사용하지 마십시오. 이는 모든 출처가 리소스에 접근하도록 허용하여 보안 위험이 될 수 있습니다. 대신 허용되는 정확한 출처를 명시하십시오.
• 허용할 메소드와 헤더를 신중하게 고려하십시오. 애플리케이션이 올바르게 작동하는 데 엄격하게 필요한 메소드와 헤더만 허용하십시오.
• 적절한 인증 및 권한 부여 메커니즘을 구현하십시오. CORS는 인증 및 권한 부여를 대체하지 않습니다. API가 적절한 보안 조치로 보호되는지 확인하십시오.
• 모든 사용자 입력을 검증하고 살균 처리하십시오. 이는 교차 사이트 스크립팅(XSS) 공격 및 기타 취약점을 방지하는 데 도움이 됩니다.
• 서버 측 CORS 구성을 최신 상태로 유지하십시오. 정기적으로 CORS 구성을 검토하고 업데이트하여 애플리케이션의 보안 요구 사항과 일치하는지 확인하십시오.

다양한 개발 환경에서의 CORS

CORS 문제는 다양한 개발 환경과 기술에서 다르게 나타날 수 있습니다. 몇 가지 일반적인 시나리오에서 CORS에 접근하는 방법을 살펴보겠습니다:

로컬 개발 환경

로컬 개발 중에는 CORS 문제가 특히 성가실 수 있습니다. 브라우저는 종종 로컬 개발 서버(예: localhost:3000)에서 원격 API로의 요청을 차단합니다. 이 문제를 완화하는 몇 가지 기술이 있습니다:

• 브라우저 확장 프로그램: "Allow CORS: Access-Control-Allow-Origin"과 같은 확장 프로그램은 테스트 목적으로 CORS 제한을 일시적으로 비활성화할 수 있습니다. 그러나 프로덕션 환경에서는 *절대* 사용하지 마십시오.
• 프록시 서버: 로컬 개발 서버에서 원격 API로 요청을 전달하는 프록시 서버를 구성하십시오. 이는 브라우저 관점에서 요청을 효과적으로 "동일 출처"로 만듭니다. http-proxy-middleware(Node.js용)와 같은 도구가 이에 유용합니다.
• 서버 CORS 구성: 개발 중에도 API 서버가 로컬 개발 출처(예: http://localhost:3000)에서의 요청을 명시적으로 허용하도록 구성하는 것이 가장 좋습니다. 이는 실제 CORS 구성을 시뮬레이션하고 문제를 조기에 발견하는 데 도움이 됩니다.

서버리스 환경 (예: AWS Lambda, Google Cloud Functions)

서버리스 함수는 종종 신중한 CORS 구성이 필요합니다. 많은 서버리스 플랫폼이 내장 CORS 지원을 제공하지만 올바르게 구성하는 것이 중요합니다:

• 플랫폼별 설정: 플랫폼의 내장 CORS 구성 옵션을 사용하십시오. 예를 들어, AWS Lambda는 API Gateway 설정에서 직접 허용된 출처, 메소드 및 헤더를 지정할 수 있도록 합니다.
• 미들웨어/라이브러리: 더 큰 유연성을 위해 서버리스 함수 코드 내에서 미들웨어나 라이브러리를 사용하여 CORS를 처리할 수 있습니다. 이는 전통적인 서버 환경에서 사용되는 접근 방식과 유사합니다(예: Node.js Lambda 함수에서 `cors` 패키지 사용).
• OPTIONS 메소드 고려: 서버리스 함수가 OPTIONS 요청을 올바르게 처리하는지 확인하십시오. 이는 종종 적절한 CORS 헤더를 반환하는 별도의 라우트를 생성하는 것을 포함합니다.

모바일 앱 개발 (예: React Native, Flutter)

CORS는 네이티브 모바일 앱(Android, iOS)에서는 직접적인 관심사가 덜합니다. 왜냐하면 일반적으로 웹 브라우저와 동일한 방식으로 동일 출처 정책을 강제하지 않기 때문입니다. 그러나 모바일 앱이 웹 뷰를 사용하여 웹 콘텐츠를 표시하거나, React Native나 Flutter와 같이 자바스크립트를 활용하는 프레임워크를 사용하는 경우 CORS가 여전히 관련될 수 있습니다:

• 웹 뷰: 모바일 앱이 웹 뷰를 사용하여 웹 콘텐츠를 표시하는 경우 웹 브라우저와 동일한 CORS 규칙이 적용됩니다. 웹 콘텐츠의 출처로부터의 요청을 허용하도록 서버를 구성하십시오.
• React Native/Flutter: 이러한 프레임워크는 자바스크립트를 사용하여 API 요청을 합니다. 네이티브 환경이 CORS를 직접 강제하지 않을 수도 있지만, 기본 HTTP 클라이언트(예: fetch)는 특정 상황에서 여전히 CORS와 유사한 동작을 보일 수 있습니다.
• 네이티브 HTTP 클라이언트: 네이티브 코드에서 직접 API 요청을 할 때(예: Android의 OkHttp 또는 iOS의 URLSession 사용) CORS는 일반적으로 문제가 되지 않습니다. 그러나 적절한 인증 및 권한 부여와 같은 보안 모범 사례는 여전히 고려해야 합니다.

CORS 구성을 위한 글로벌 고려사항

전 세계적으로 접근 가능한 애플리케이션에 대해 CORS를 구성할 때는 다음과 같은 요소를 고려하는 것이 중요합니다:

• 데이터 주권: 일부 지역의 규정은 데이터가 해당 지역 내에 있어야 한다고 규정합니다. 국경을 넘어 리소스에 접근할 때 CORS가 관련될 수 있으며, 이는 데이터 상주법에 저촉될 수 있습니다.
• 지역별 보안 정책: 국가마다 CORS 구현 및 보안 방법에 영향을 미치는 사이버 보안 규정 및 지침이 다를 수 있습니다.
• 콘텐츠 전송 네트워크(CDN): CDN이 필요한 CORS 헤더를 올바르게 통과시키도록 구성되었는지 확인하십시오. 잘못 구성된 CDN은 CORS 헤더를 제거하여 예기치 않은 오류를 유발할 수 있습니다.
• 로드 밸런서 및 프록시: 인프라의 로드 밸런서나 리버스 프록시가 프리플라이트 요청을 올바르게 처리하고 CORS 헤더를 통과시키는지 확인하십시오.
• 다국어 지원: CORS가 애플리케이션의 국제화(i18n) 및 현지화(l10n) 전략과 어떻게 상호 작용하는지 고려하십시오. CORS 정책이 애플리케이션의 다른 언어 버전에서도 일관되게 유지되는지 확인하십시오.

CORS 테스트 및 디버깅

CORS를 효과적으로 테스트하고 디버깅하는 것은 매우 중요합니다. 다음은 몇 가지 기술입니다:

• 브라우저 개발자 도구: 브라우저의 개발자 콘솔이 첫 번째 단계입니다. "네트워크" 탭은 프리플라이트 요청과 응답을 보여주어 CORS 헤더가 존재하고 올바르게 구성되었는지 확인할 수 있습니다.
• `curl` 명령줄 도구: `curl -v -X OPTIONS `을 사용하여 수동으로 프리플라이트 요청을 보내고 서버의 응답 헤더를 검사하십시오.
• 온라인 CORS 검사기: 수많은 온라인 도구가 CORS 구성을 검증하는 데 도움이 될 수 있습니다. "CORS checker"로 검색해 보세요.
• 단위 및 통합 테스트: CORS 구성이 예상대로 작동하는지 확인하기 위해 자동화된 테스트를 작성하십시오. 이러한 테스트는 성공적인 교차 출처 요청과 CORS가 접근을 차단해야 하는 시나리오를 모두 포함해야 합니다.
• 로깅 및 모니터링: 프리플라이트 요청 및 차단된 요청과 같은 CORS 관련 이벤트를 추적하기 위해 로깅을 구현하십시오. 의심스러운 활동이나 구성 오류에 대해 로그를 모니터링하십시오.

결론

교차 출처 리소스 공유(CORS)는 웹 리소스에 대한 통제된 교차 출처 접근을 가능하게 하는 중요한 보안 메커니즘입니다. CORS의 작동 방식, 특히 프리플라이트 요청을 이해하는 것은 안전하고 신뢰할 수 있는 웹 애플리케이션을 구축하는 데 매우 중요합니다. 이 가이드에서 설명한 모범 사례를 따르면 CORS 문제를 효과적으로 처리하고 잠재적인 취약점으로부터 애플리케이션을 보호할 수 있습니다. 항상 보안을 최우선으로 생각하고 CORS 구성의 영향을 신중하게 고려하는 것을 잊지 마십시오.

웹 개발이 발전함에 따라 CORS는 계속해서 웹 보안의 중요한 측면이 될 것입니다. 최신 CORS 모범 사례와 기술에 대한 정보를 유지하는 것은 안전하고 전 세계적으로 접근 가능한 웹 애플리케이션을 구축하는 데 필수적입니다.