CORS preflight 요청은 언제 발생하나요?

CORS preflight 요청은 브라우저가 실제 cross-origin 요청을 보내기 전에 서버가 해당 요청을 허용하는지 확인하기 위해 보내는 OPTIONS 요청입니다. 단순 요청(simple request)이 아닌 메서드, 헤더, 콘텐츠 타입을 사용할 때 주로 발생합니다.

핵심 개념

• 브라우저 보안 모델은 다른 출처 요청을 서버의 CORS 응답 헤더에 따라 제한합니다.
• preflight는 실제 요청이 부작용을 일으키기 전에 권한을 확인하는 안전장치입니다.
• 서버는 Access-Control-Allow-Origin, Allow-Methods, Allow-Headers 등을 응답해야 합니다.

동작 방식 또는 판단 기준

이 주제를 이해할 때는 다음 순서로 보면 실무 적용이 쉬워집니다.

1. 무엇을 해결하려는가: 성능, 표현력, 안정성, 접근성 중 어떤 문제를 줄이려는지 확인합니다.
2. 전제 조건은 무엇인가: 정렬 여부, 브라우저 지원, 네트워크 특성, 동시성 조건처럼 성립해야 하는 조건을 점검합니다.
3. 비용은 어디서 발생하는가: 시간 복잡도, 메모리, 캐시, 재시도, 렌더링 비용처럼 병목 지점을 나눠 봅니다.
4. 실패 시 어떤 문제가 생기는가: 잘못 적용했을 때의 버그나 운영 리스크를 함께 고려합니다.

실제 예시

OPTIONS /api/orders HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: POST, GET
Access-Control-Allow-Headers: authorization, content-type
Access-Control-Max-Age: 600

fetch('https://api.example.com/api/orders', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${token}`,
  },
  body: JSON.stringify(order),
});

실무에서 주의할 점

• CORS는 브라우저 정책입니다. 서버-서버 요청이나 curl에서는 다르게 보일 수 있습니다.
• credentials를 사용할 때 Access-Control-Allow-Origin: *는 사용할 수 없습니다.
• preflight 실패는 실제 API 핸들러까지 도달하지 않을 수 있으므로 미들웨어/프록시 레벨 로그를 확인해야 합니다.

실무 적용 가이드

• 허용 origin을 명시적으로 관리하고 와일드카드는 공개 API에만 신중히 씁니다.
• preflight가 잦은 API는 Access-Control-Max-Age로 비용을 줄일 수 있습니다.
• 인증/쿠키/프록시 환경에서는 CORS, SameSite, Secure 설정을 함께 점검합니다.

함께 연결해서 보면 좋은 키워드

CORS, Preflight, OPTIONS, Origin, Browser Security

정리

CORS preflight 요청은 브라우저가 실제 cross-origin 요청을 보내기 전에 서버가 해당 요청을 허용하는지 확인하기 위해 보내는 OPTIONS 요청입니다. 다만 개념 자체보다 중요한 것은 적용 조건과 한계를 함께 이해하는 것입니다. 작은 예제에서는 단순해 보여도 실제 서비스에서는 성능, 보안, 유지보수성, 접근성 요구사항이 함께 얽히므로, 문제의 성격을 먼저 파악한 뒤 적절한 도구로 선택하는 것이 좋습니다.