브라우저는 왜 CORS에서 OPTIONS 프리플라이트 요청을 보내나요?
브라우저는 Authorization 헤더나 application/json과 같은 커스텀 속성을 포함하는 비단순 요청(Non-Simple Request)을 전송하기 전에, 대상 서버가 해당 메서드와 헤더를 안전하게 허용하는지 사전 확인하기 위해 OPTIONS 프리플라이트 요청을 전송합니다.
Detailed Technical Explanation
CORS 프리플라이트는 크로스 오리진 요청을 염두에 두지 않았던 과거의 레거시 웹 서버를 보호하기 위해 설계되었습니다. 브라우저는 실제 요청을 보내기 전 OPTIONS 메서드로 사전 질의를 수행하고, 서버가 반환한 Access-Control-Allow-* 응답을 확인한 후에만 본 요청을 전송합니다.
Technical Example & Code
브라우저가 사전 요청을 통해 서버의 허용 정책을 확인한 후 본 요청을 전송합니다.
// 1. Browser sends Preflight Request:
OPTIONS /api/orders HTTP/1.1
Host: api.example.com
Origin: https://app.curious-techie.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization
// 2. Server approves the interaction:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.curious-techie.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
// 3. Browser now automatically sends the actual POST request!Why This Is the Case (Underlying Architectural Rationale)
"예기치 않은 크로스 오리진 요청으로 인해 서버 측 데이터가 무단으로 변경되거나 부작용이 발생하는 것을 사전에 차단하기 위함입니다."
Common Misconception vs Reality
"CORS 프리플라이트는 cURL이나 해커의 스크립트 공격으로부터 서버를 방어해 준다."
CORS는 전적으로 브라우저 내부에서만 강제되는 보안 정책입니다. cURL, Python 스크립트, 백엔드 서버는 프리플라이트를 보내지 않으며 CORS 제약을 받지 않습니다.
Related Curious-Techie Resources
How to Fix CORS Preflight Errors: Step-by-Step Guide →
Diagnose and resolve preflight 403 Forbidden errors, missing headers, and proxy redirection bugs.
Interactive ToolCORS Checker & Header Generator →
Test preflight OPTIONS handling and generate production-ready Express and Nginx CORS rules.
Developer ReferenceCORS Headers Reference & Specifications →
Related Questions in the Q&A Knowledge Base
CORS allows standard GET requests without a preflight check for backward compatibility with the legacy web. Because HTML tags like `<form>`, `<img>`, and `<script>` have always been able to issue cross-origin GET requests without pre-approval, requiring preflights for all GETs would have broken decades of existing web architecture.
HTTP 401 Unauthorized means the user is not authenticated (identity unknown; credentials missing or invalid), whereas HTTP 403 Forbidden means the user is authenticated (identity known), but lacks the necessary permissions to access the requested resource.
Using 'unsafe-inline' in a Content Security Policy defeats XSS protection because it instructs the browser to execute any inline script found in the HTML. Since Cross-Site Scripting works by injecting malicious inline script tags or event handlers, 'unsafe-inline' allows the attacker's payload to run freely.
관련 기술 생태계 및 다음 학습 단계
관련 기술 아티클
What Is CORS (Cross-Origin Resource Sharing)?
The standard protocol enabling controlled cross-origin data access in modern browsers.
CSP vs CORS: Differences in Browser Defense Mechanisms
Distinguishing outbound resource loading restrictions from inbound server access control.
Troubleshooting: No Access-Control-Allow-Origin Header Present
Diagnose and fix the most common browser cross-origin blocking error with production configs.
실습형 진단 랩
개발자 표준 규격 및 레퍼런스
다음 학습 단계
CORS Policy & Preflight Handshake Lab
Simulate preflight OPTIONS probes and adjust Access-Control-Allow-* headers inside the browser sandbox.