교차 출처 보안 구현: 자바스크립트 통신 모범 사례

오늘날 상호 연결된 웹 환경에서 자바스크립트 애플리케이션은 종종 다른 출처(도메인, 프로토콜 또는 포트)의 리소스와 상호 작용해야 합니다. 이 상호 작용은 브라우저의 동일 출처 정책(Same-Origin Policy)에 의해 제어됩니다. 이는 악성 스크립트가 도메인 경계를 넘어 민감한 데이터에 접근하는 것을 방지하기 위해 설계된 중요한 보안 메커니즘입니다. 하지만 합법적인 교차 출처 통신이 필요한 경우도 많습니다. 바로 이 지점에서 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)가 사용됩니다. 이 글에서는 CORS에 대한 포괄적인 개요, 구현 방법, 그리고 자바스크립트에서 안전한 교차 출처 통신을 위한 모범 사례를 제공합니다.

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

동일 출처 정책(SOP)은 웹 브라우저의 근본적인 보안 개념입니다. 이 정책은 한 출처에서 실행되는 스크립트가 다른 출처의 리소스에 접근하는 것을 제한합니다. 출처는 프로토콜(예: HTTP 또는 HTTPS), 도메인 이름(예: example.com), 포트 번호(예: 80 또는 443)의 조합으로 정의됩니다. 두 URL은 이 세 가지 구성 요소가 모두 정확하게 일치할 때만 동일한 출처를 가집니다.

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

• http://www.example.com와 http://www.example.com/path: 동일 출처
• http://www.example.com와 https://www.example.com: 다른 출처 (프로토콜이 다름)
• http://www.example.com와 http://subdomain.example.com: 다른 출처 (도메인이 다름)
• http://www.example.com:80와 http://www.example.com:8080: 다른 출처 (포트가 다름)

SOP는 웹사이트에 주입된 악성 스크립트가 사용자 데이터를 훔치거나 사용자를 대신하여 무단 작업을 수행할 수 있는 교차 사이트 스크립팅(XSS) 공격에 대한 중요한 방어 수단입니다.

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

CORS는 HTTP 헤더를 사용하여 서버가 어떤 출처(도메인, 스킴 또는 포트)가 자신의 리소스에 접근할 수 있도록 허용할지를 나타내는 메커니즘입니다. 이는 본질적으로 특정 교차 출처 요청에 대해 동일 출처 정책을 완화하여, 악의적인 공격으로부터는 보호하면서 합법적인 통신을 가능하게 합니다.

CORS는 허용된 출처와 교차 출처 요청에 허용되는 메서드(예: GET, POST, PUT, DELETE)를 지정하는 새로운 HTTP 헤더를 추가하여 작동합니다. 브라우저가 교차 출처 요청을 할 때, 요청과 함께 Origin 헤더를 보냅니다. 서버는 허용된 출처를 지정하는 Access-Control-Allow-Origin 헤더로 응답합니다. 만약 요청의 출처가 Access-Control-Allow-Origin 헤더의 값과 일치하거나 값이 *이면, 브라우저는 자바스크립트 코드가 응답에 접근하도록 허용합니다.

CORS의 작동 방식: 상세 설명

CORS 프로세스는 일반적으로 두 가지 유형의 요청을 포함합니다:

1. 단순 요청(Simple Requests): 특정 기준을 충족하는 요청입니다. 요청이 이 조건들을 만족하면, 브라우저는 요청을 직접 보냅니다.
2. 프리플라이트 요청(Preflighted Requests): 더 복잡한 요청으로, 실제 요청을 보내도 안전한지 판단하기 위해 브라우저가 먼저 서버에 "프리플라이트" OPTIONS 요청을 보내야 합니다.

1. 단순 요청

요청이 다음의 모든 조건을 충족하면 "단순(simple)"하다고 간주됩니다:

• 메서드가 GET, HEAD, 또는 POST입니다.
• 메서드가 POST인 경우, Content-Type 헤더는 다음 중 하나입니다:
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
• 사용자 정의 헤더가 설정되지 않았습니다.

단순 요청의 예:

GET /resource HTTP/1.1
Origin: http://www.example.com

출처를 허용하는 서버 응답의 예:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Content-Type: application/json

{
  "data": "Some data"
}

Access-Control-Allow-Origin 헤더가 존재하고 그 값이 요청의 출처와 일치하거나 *로 설정된 경우, 브라우저는 스크립트가 응답 데이터에 접근하도록 허용합니다. 그렇지 않으면 브라우저는 응답에 대한 접근을 차단하고 콘솔에 오류 메시지를 표시합니다.

2. 프리플라이트 요청

요청이 단순 요청의 기준을 충족하지 못하면 "프리플라이트(preflighted)" 요청으로 간주됩니다. 이는 일반적으로 요청이 다른 HTTP 메서드(예: PUT, DELETE)를 사용하거나, 사용자 정의 헤더를 설정하거나, 허용된 값 이외의 Content-Type을 사용하는 경우에 발생합니다.

실제 요청을 보내기 전에, 브라우저는 먼저 서버에 OPTIONS 요청을 보냅니다. 이 "프리플라이트" 요청에는 다음 헤더가 포함됩니다:

• Origin: 요청하는 페이지의 출처.
• Access-Control-Request-Method: 실제 요청에서 사용될 HTTP 메서드 (예: PUT, DELETE).
• Access-Control-Request-Headers: 실제 요청에서 전송될 사용자 정의 헤더의 쉼표로 구분된 목록.

프리플라이트 요청의 예:

OPTIONS /resource HTTP/1.1
Origin: http://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header, Content-Type

서버는 OPTIONS 요청에 다음 헤더로 응답해야 합니다:

• Access-Control-Allow-Origin: 요청을 보낼 수 있도록 허용된 출처 (또는 모든 출처를 허용하는 *).
• Access-Control-Allow-Methods: 교차 출처 요청에 허용되는 HTTP 메서드의 쉼표로 구분된 목록 (예: GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: 요청에 전송될 수 있도록 허용된 사용자 정의 헤더의 쉼표로 구분된 목록.
• Access-Control-Max-Age: 프리플라이트 응답이 브라우저에 의해 캐시될 수 있는 시간(초).

프리플라이트 요청에 대한 서버 응답의 예:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: X-Custom-Header, Content-Type
Access-Control-Max-Age: 86400

만약 프리플라이트 요청에 대한 서버의 응답이 실제 요청이 허용됨을 나타내면, 브라우저는 실제 요청을 보냅니다. 그렇지 않으면 브라우저는 요청을 차단하고 오류 메시지를 표시합니다.

서버 측에서 CORS 구현하기

CORS는 주로 서버 측에서 응답에 적절한 HTTP 헤더를 설정하여 구현됩니다. 구체적인 구현 세부 사항은 사용되는 서버 측 기술에 따라 달라집니다.

Node.js와 Express를 사용한 예제:

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

// 모든 출처에 대해 CORS 활성화
app.use(cors());

// 또는 특정 출처에 대해 CORS 구성
// const corsOptions = {
//   origin: 'http://www.example.com'
// };
// app.use(cors(corsOptions));

app.get('/resource', (req, res) => {
  res.json({ message: 'This is a CORS-enabled resource' });
});

app.listen(3000, () => {
  console.log('Server listening on port 3000');
});

cors 미들웨어는 Express에서 CORS 헤더를 설정하는 과정을 단순화합니다. cors()를 사용하여 모든 출처에 대해 CORS를 활성화하거나, cors(corsOptions)를 사용하여 특정 출처에 대해 구성할 수 있습니다.

Python과 Flask를 사용한 예제:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/resource")
def hello():
    return {"message": "This is a CORS-enabled resource"}

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

flask_cors 확장은 Flask 애플리케이션에서 CORS를 활성화하는 간단한 방법을 제공합니다. CORS()에 app을 전달하여 모든 출처에 대해 CORS를 활성화할 수 있습니다. 특정 출처에 대한 구성도 가능합니다.

Java와 Spring Boot를 사용한 예제:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/resource")
                .allowedOrigins("http://www.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "X-Custom-Header")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

Spring Boot에서는 WebMvcConfigurer를 사용하여 CORS를 구성할 수 있습니다. 이를 통해 허용된 출처, 메서드, 헤더 및 기타 CORS 설정에 대한 세밀한 제어가 가능합니다.

직접 CORS 헤더 설정하기 (일반적인 예제)

프레임워크를 사용하지 않는 경우, 서버 측 코드(예: PHP, Ruby on Rails 등)에서 직접 헤더를 설정할 수 있습니다:

CORS 모범 사례

안전하고 효율적인 교차 출처 통신을 보장하려면 다음 모범 사례를 따르십시오:

1. 프로덕션 환경에서 Access-Control-Allow-Origin: * 사용 피하기: 모든 출처가 리소스에 접근하도록 허용하는 것은 보안 위험이 될 수 있습니다. 대신 허용되는 정확한 출처를 지정하십시오.
2. HTTPS 사용: 전송 중인 데이터를 보호하기 위해 요청하는 출처와 제공하는 출처 모두에 항상 HTTPS를 사용하십시오.
3. 입력 유효성 검사: 주입 공격을 방지하기 위해 교차 출처 요청으로부터 받은 데이터를 항상 검증하고 살균(sanitize)하십시오.
4. 적절한 인증 및 권한 부여 구현: 승인된 사용자만 민감한 리소스에 접근할 수 있도록 하십시오.
5. 프리플라이트 응답 캐싱: Access-Control-Max-Age를 사용하여 프리플라이트 응답을 캐시하고 OPTIONS 요청 수를 줄이십시오.
6. 자격 증명(Credentials) 사용 고려: API가 쿠키나 HTTP 인증을 요구하는 경우, 서버에서 Access-Control-Allow-Credentials 헤더를 true로 설정하고, 자바스크립트 코드(예: fetch 또는 XMLHttpRequest 사용 시)에서 credentials 옵션을 'include'로 설정해야 합니다. 이 옵션을 사용할 때는 매우 신중해야 합니다. 올바르게 처리하지 않으면 보안 취약점을 유발할 수 있습니다. 또한, Access-Control-Allow-Credentials가 true로 설정되면 Access-Control-Allow-Origin은 "*"로 설정할 수 없습니다. 허용된 출처를 명시적으로 지정해야 합니다.
7. 정기적으로 CORS 구성 검토 및 업데이트: 애플리케이션이 발전함에 따라 정기적으로 CORS 구성을 검토하고 업데이트하여 보안을 유지하고 요구 사항을 충족하는지 확인하십시오.
8. 다양한 CORS 구성의 영향 이해: 다양한 CORS 구성의 보안적 영향을 인지하고 애플리케이션에 적합한 구성을 선택하십시오.
9. CORS 구현 테스트: CORS 구현이 예상대로 작동하고 보안 취약점을 유발하지 않는지 철저히 테스트하십시오. 브라우저 개발자 도구를 사용하여 네트워크 요청과 응답을 검사하고, 자동화된 테스트 도구를 사용하여 CORS 동작을 확인하십시오.

예제: Fetch API와 CORS 사용하기

다음은 fetch API를 사용하여 교차 출처 요청을 하는 예제입니다:

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors', // 브라우저에 이것이 CORS 요청임을 알림
  headers: {
    'Content-Type': 'application/json',
    'X-Custom-Header': 'value'
  }
})
.then(response => {
  if (!response.ok) {
    throw new Error('Network response was not ok');
  }
  return response.json();
})
.then(data => {
  console.log(data);
})
.catch(error => {
  console.error('There was a problem with the fetch operation:', error);
});

mode: 'cors' 옵션은 브라우저에 이것이 CORS 요청임을 알립니다. 서버가 출처를 허용하지 않으면 브라우저는 응답에 대한 접근을 차단하고 오류가 발생합니다.

자격 증명(예: 쿠키)을 사용하는 경우, credentials 옵션을 'include'로 설정해야 합니다:

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors',
  credentials: 'include', // 요청에 쿠키 포함
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => {
  // ...
});

CORS와 JSONP

JSON with Padding (JSONP)는 동일 출처 정책을 우회하기 위한 오래된 기술입니다. 다른 도메인에서 데이터를 로드하는 <script> 태그를 동적으로 생성하여 작동합니다. JSONP는 특정 상황에서 유용할 수 있지만, 심각한 보안 제한이 있으므로 가능하면 피해야 합니다. CORS는 더 안전하고 유연한 메커니즘을 제공하므로 교차 출처 통신에 선호되는 솔루션입니다.

CORS와 JSONP의 주요 차이점:

• 보안: CORS는 서버가 어떤 출처가 리소스에 접근할 수 있는지 제어할 수 있기 때문에 JSONP보다 더 안전합니다. JSONP는 출처 제어를 제공하지 않습니다.
• HTTP 메서드: CORS는 모든 HTTP 메서드(예: GET, POST, PUT, DELETE)를 지원하지만, JSONP는 GET 요청만 지원합니다.
• 오류 처리: CORS는 JSONP보다 더 나은 오류 처리를 제공합니다. CORS 요청이 실패하면 브라우저는 상세한 오류 메시지를 제공합니다. JSONP의 오류 처리는 스크립트가 성공적으로 로드되었는지 감지하는 것으로 제한됩니다.

CORS 문제 해결하기

CORS 문제는 디버깅하기 어려울 수 있습니다. 다음은 일반적인 문제 해결 팁입니다:

• 브라우저 콘솔 확인: 브라우저 콘솔은 일반적으로 CORS 문제에 대한 상세한 오류 메시지를 제공합니다.
• 네트워크 요청 검사: 브라우저의 개발자 도구를 사용하여 요청과 응답 모두의 HTTP 헤더를 검사하십시오. Origin과 Access-Control-Allow-Origin 헤더가 올바르게 설정되었는지 확인하십시오.
• 서버 측 구성 확인: 서버 측 CORS 구성을 다시 확인하여 올바른 출처, 메서드, 헤더를 허용하고 있는지 확인하십시오.
• 브라우저 캐시 지우기: 때때로 캐시된 프리플라이트 응답이 CORS 문제를 일으킬 수 있습니다. 브라우저 캐시를 지우거나 시크릿 브라우징 창을 사용해 보십시오.
• CORS 프록시 사용: 경우에 따라 CORS 제한을 우회하기 위해 CORS 프록시를 사용해야 할 수도 있습니다. 그러나 CORS 프록시를 사용하면 보안 위험이 발생할 수 있다는 점에 유의하십시오.
• 잘못된 구성 확인: Access-Control-Allow-Origin 헤더 누락, 잘못된 Access-Control-Allow-Methods 또는 Access-Control-Allow-Headers 값, 요청의 잘못된 Origin 헤더와 같은 일반적인 잘못된 구성을 찾아보십시오.

결론

교차 출처 리소스 공유(CORS)는 자바스크립트 애플리케이션에서 안전한 교차 출처 통신을 가능하게 하는 필수적인 메커니즘입니다. 개발자는 동일 출처 정책, CORS 워크플로우, 그리고 관련된 다양한 HTTP 헤더를 이해함으로써, 합법적인 교차 출처 요청을 허용하면서도 보안 취약점으로부터 애플리케이션을 보호하기 위해 CORS를 효과적으로 구현할 수 있습니다. CORS 구성에 대한 모범 사례를 따르고 정기적으로 구현을 검토하는 것은 안전하고 견고한 웹 애플리케이션을 유지하는 데 매우 중요합니다.

이 종합 가이드는 CORS를 이해하고 구현하기 위한 견고한 기반을 제공합니다. CORS를 정확하고 안전하게 구현하려면 사용 중인 특정 서버 측 기술에 대한 공식 문서와 자료를 참조하는 것을 잊지 마십시오.

추가 자료

• MDN 웹 문서: 교차 출처 리소스 공유 (CORS)
• W3C: 교차 출처 리소스 공유 (CORS)
• PortSwigger 웹 보안 아카데미: CORS