Options

CORS(교차 출처 리소스 공유)는 클라이언트(브라우저)가 다른 도메인에서 제공하는 리소스에 접근할 수 있도록 허용하는 메커니즘입니다. 다음은 CORS의 주요 구성 요소에 대한 설명입니다.

1. Access-Control-Allow-Origin

• 설명: 이 헤더는 요청을 허용할 외부 도메인(출처)을 지정합니다. 지정된 출처만이 리소스에 접근할 수 있습니다.
• 예시:
  • 특정 출처 허용: Access-Control-Allow-Origin: https://example.com
  • 모든 출처 허용: Access-Control-Allow-Origin: * (이 경우 보안상 주의가 필요)

2. Access-Control-Allow-Methods

• 설명: 이 헤더는 외부 도메인에서 사용할 수 있는 HTTP 메소드를 정의합니다. 특정 엔드포인트에 대해 사용할 수 있는 메소드만 허용합니다.
• 예시:
  • 예를 들어, example.com에서 GET 요청만을 허용하고 싶다면:

    Access-Control-Allow-Methods: GET

3. Access-Control-Allow-Headers

• 설명: 이 헤더는 요청에서 사용할 수 있는 특정 헤더를 제한합니다. 클라이언트가 서버에 요청할 때 사용할 수 있는 헤더를 지정할 수 있습니다.
• 예시:
  • 예를 들어, Content-Type과 Authorization 헤더를 허용하려면:

    Access-Control-Allow-Headers: Content-Type, Authorization

CORS 설정 예시

Spring Boot에서 CORS를 설정하는 예시는 다음과 같습니다:

import org.springframework.context.annotation.Bean;
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 WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**") // 모든 엔드포인트에 대해
                .allowedOrigins("https://example.com") // 허용할 외부 도메인
                .allowedMethods("GET") // 허용할 HTTP 메소드
                .allowedHeaders("Content-Type", "Authorization"); // 허용할 헤더
    }
}

위의 설정은 example.com에서 오는 GET 요청에 대해 허용하며, 요청에서 Content-Type과 Authorization 헤더를 사용할 수 있도록 허용합니다. CORS 설정은 클라이언트와 서버 간의 보안을 유지하면서 외부 도메인에 대한 적절한 접근을 제공하는 데 중요합니다.

 

CORS 관련 헤더들이 서버에서 클라이언트에게 전송되는 시점은 주로 두 가지 경우로 나눌 수 있습니다. 각 경우에 대해 자세히 설명하겠습니다.

1. Preflight 요청

Preflight 요청은 클라이언트가 서버에 실제 요청을 보내기 전에 CORS 정책을 확인하기 위해 서버에 보내는 OPTIONS 요청입니다. 이 요청은 다음과 같은 상황에서 발생합니다:

• 클라이언트가 비단순 요청(non-simple request)을 보낼 때. 비단순 요청은 다음 중 하나라도 해당되는 경우입니다:
  • HTTP 메소드가 GET, POST, HEAD 이외의 메소드인 경우 (예: PUT, DELETE)
  • 요청 헤더에 사용자 정의 헤더가 포함된 경우
  • Content-Type이 application/x-www-form-urlencoded, multipart/form-data, 또는 text/plain 이외의 값인 경우

Preflight 요청 예시

클라이언트에서 비단순 요청을 보낼 때, 먼저 다음과 같은 OPTIONS 요청을 보냅니다:

OPTIONS /api/resource HTTP/1.1
Host: server.com
Origin: https://client.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

서버 응답:
서버는 Preflight 요청에 대한 응답으로 CORS 관련 헤더를 포함하여 응답합니다:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://client.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type

이 응답을 통해 클라이언트는 요청을 보낼 수 있는지 확인할 수 있습니다.

2. 실제 요청

Preflight 요청이 성공적으로 처리된 후, 클라이언트는 서버에 실제 요청을 보냅니다. 이 요청은 다음과 같은 상황에서 발생합니다:

• Preflight 요청이 성공적으로 응답받았을 때
• 또는 비단순 요청이 아닌 단순 요청일 경우에는 Preflight 요청 없이 직접적으로 요청을 보냅니다.

실제 요청 예시

클라이언트에서 서버에 실제 요청을 보냅니다:

POST /api/resource HTTP/1.1
Host: server.com
Origin: https://client.com
Content-Type: application/json

{"key":"value"}

서버 응답:
서버는 요청 처리 후 응답을 보낼 때 CORS 관련 헤더를 포함합니다:

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

{"message":"Success"}

요약

CORS 관련 헤더는 주로 다음과 같은 상황에서 서버에서 클라이언트로 전송됩니다:

1. Preflight 요청에 대한 응답: 클라이언트가 비단순 요청을 보내기 전에 CORS 정책을 확인하기 위해 OPTIONS 요청을 보냄.
2. 실제 요청에 대한 응답: Preflight 요청이 성공적으로 처리되었거나 비단순 요청이 아닌 경우 클라이언트가 서버에 직접 요청을 보냄.

이러한 헤더는 클라이언트가 서버의 리소스에 접근할 수 있는 권한이 있는지를 판단하는 중요한 역할을 합니다.