글을 쓰게 된 동기
최근까지 Nginx를 앞단에 두고 로컬 환경에서 Docker로 개발하면서, 헤더(Header)를 적극적으로 활용하지 않았기 때문에 CORS의 프리플라이트 요청에 대해 깊이 알지 못했습니다. 특히 Spring에서는 프리플라이트 요청을 자동(설정을 해주면)으로 처리해주기 때문에, 이를 인지하지 못한 채 지나쳤던 것 같습니다. 이번에 Nginx 설정에서 Access-Token 헤더를 통해 요청을 보내면서, 다행스럽게(?) 프리플라이트 요청의 개념을 이해하게 되었습니다. 이를 계기로 프리플라이트 요청의 동작 방식과 어떤 상황에서 발생하는지를 정리하고자 이 글을 쓰게 되었습니다.
Cors Preflight
1. CORS란?
CORS는 웹 브라우저에서 교차 출처 요청(다른 도메인, 포트 또는 프로토콜로의 요청)을 제어하는 메커니즘입니다. 기본적으로 브라우저는 보안상 같은 출처(Same-Origin) 정책을 따르지만, CORS를 사용하면 특정 조건에서 다른 출처의 리소스에 접근할 수 있습니다.
2. 프리플라이트 요청(Preflight Request)이란?
프리플라이트 요청은 브라우저가 실제 요청 전에 서버에 미리 OPTIONS 요청을 보내어 해당 서버가 CORS 요청을 허용하는지 확인하는 과정입니다.
3. 프리플라이트 요청이 필요한 경우:
프리플라이트 요청은 클라이언트가 보내는 요청이 안전하지 않다고 간주되는 경우 발생합니다. 여기서 "안전하지 않음"은 서버에 잠재적인 영향을 미칠 수 있는 요청을 의미합니다. 브라우저는 이 요청이 허용될지 여부를 먼저 확인하기 위해 프리플라이트 요청을 전송합니다.
다음과 같은 조건에서 프리플라이트 요청이 발생합니다:
- HTTP 메서드가
GET,POST,HEAD외의 메서드일 때 (PUT,DELETE,PATCH등). - 요청에 비표준 헤더가 포함될 때 (예:
Authorization,Content-Type: application/json등). - 요청에 JSON 또는 바이너리 데이터와 같은 특정 컨텐츠 타입이 포함될 때 (
application/json,multipart/form-data,text/xml등).
4. 프리플라이트 요청의 동작 과정:
- 브라우저는 OPTIONS 메서드로 서버에 프리플라이트 요청을 보냅니다.
- 요청 헤더에는 실제 요청에서 사용될 HTTP 메서드, 헤더, 출처(origin)가 포함됩니다.
- 서버는 CORS 정책에 따라 해당 요청을 허용할지 여부를 결정한 후 응답합니다.
- 서버는 응답 헤더에 허용된 메서드, 헤더, 출처 정보를 담습니다.
- 브라우저는 프리플라이트 요청의 응답을 확인한 후, 허용된다면 실제 요청을 보냅니다.
- 허용되지 않는다면, 실제 요청은 보내지 않고 보안 오류를 발생시킵니다.
5. 프리플라이트 요청의 예시:
프리플라이트 요청은 OPTIONS 메서드를 사용해 전송됩니다.
프리플라이트 요청:
http
코드 복사
OPTIONS /api/resource HTTP/1.1
Host: example.com
Origin: http://my-website.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
서버의 응답:
http
코드 복사
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://my-website.com
Access-Control-Allow-Methods: PUT, GET, POST, DELETE
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Origin: 요청을 허용하는 출처.Access-Control-Allow-Methods: 허용된 HTTP 메서드.Access-Control-Allow-Headers: 허용된 요청 헤더.
6. 프리플라이트 요청을 줄이는 방법:
프리플라이트 요청은 성능에 영향을 미칠 수 있으므로 최대한 줄이는 것이 좋습니다. 이를 위해 다음을 고려할 수 있습니다:
- 단순 요청(Simple Request) 사용:
- HTTP 메서드를
GET,POST,HEAD로 제한. - 표준 헤더만 사용 (
Content-Type을application/x-www-form-urlencoded,multipart/form-data,text/plain중 하나로 설정).
- HTTP 메서드를
- 캐싱:
- 서버는
Access-Control-Max-Age헤더를 사용하여 프리플라이트 응답을 캐시할 수 있습니다. 이로 인해 브라우저가 일정 시간 동안 같은 출처로의 프리플라이트 요청을 다시 보내지 않게 됩니다.
- 서버는
7. 프리플라이트 요청의 목적과 중요성:
- 프리플라이트 요청은 보안 메커니즘입니다. 이는 서버가 교차 출처 요청을 명시적으로 허용했는지 확인하여 서버와 클라이언트 모두의 안전성을 보장합니다.
- 서버는 어떤 요청을 허용하고 어떤 요청을 거부할지 선택할 수 있으므로, API 보안을 강화하는 데 필수적입니다.
결론:
프리플라이트 요청은 브라우저가 교차 출처 HTTP 요청을 보내기 전에 보안을 확인하는 절차로, 서버가 허용하는 메서드와 헤더를 사전에 검증합니다. 이 과정은 보안 강화를 위해 필요하지만, 성능에 영향을 줄 수 있으므로 최대한 단순한 요청으로 구성하거나 캐싱을 활용하여 최소화하는 것이 중요합니다.
