CORS 동작 원리를 알아보자
CORS는 클라이언트와 서버 간의 안전한 데이터 전송을 보장하기 위해 Preflight 요청과 CORS 헤더를 사용하여 서로 다른 출처 간의 리소스 접근을 제어한다.
1. header
CORS는 HTTP 헤더를 통해 동작하며, 서버가 클라이언트의 요청을 수락할 수 있는지 여부를 결정한다.
1.1. Access-Control-Allow-Origin
이 헤더는 어떤 출처의 요청을 허용할지를 지정
EX)
Access-Control-Allow-Origin : * : 모든 출처의 요청을 허용
Access-Control-Allow-Origin: https://example.com: 특정 출처에만 요청을 허용
이 헤더가 없거나 잘못 설정되어 있으면 브라우저는 요청을 차단합니다.
1.2. Access-Control-Allow-Methods
이 헤더는 클라이언트가 허용된 HTTP 메서드를 명시
Access-Control-Allow-Methods: GET, POST, PUT : GET, POST, PUT 메서드의 요청을 허용
클라이언트는 이 헤더를 통해 어떤 메서드로 요청할 수 있는지를 알 수 있음
1.3. Access-Control-Allow-Headers
이 헤더는 클라이언트가 요청 시 사용할 수 있는 커스텀 헤더를 명시
Access-Control-Allow-Headers: Content-Type, Authorization: Content-Type과 Authorization 헤더를 사용할 수 있도록 허용
브라우저는 이 정보를 기반으로 요청을 보내기 전에 적절한 헤더를 포함할 수 있음
Preflight?
동작 원리 (3-way handshake)
CORS의 동작 원리를 TCP/IP 프로토콜의 3-way handshake와 비교하여 설명할 수 있습니다.
3-way handshake?
TCP 통신을 이용하여 데이터를 전송하기 위해 네트워크 연결을 설정(Connection Establish) 하는 과정.
양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기 전에 한 쪽이 다른 쪽이 준비되었다는 것을 알 수 있도록 한다.
즉, TCP/IP 프로토콜을 이용해서 통신을 하는 응용 프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미한다.
- Preflight 요청: 클라이언트가 서버에 OPTIONS 요청을 보내어 CORS 정책을 확인
- 서버 응답: 서버가 클라이언트의 출처와 요청된 메서드, 헤더를 확인하고, 허용된 경우 적절한 CORS 헤더와 함께 200 OK 응답을
- 실제 요청: 클라이언트가 서버에 실제 요청을 보내고, 서버는 해당 요청에 대한 응답을 반환
이 과정을 통해 CORS는 서로 다른 출처 간의 안전한 데이터 전송을 보장하게 됨
Preflight 요청
Preflight 요청은 서버에 실제 요청을 보내기 전에 브라우저가 보내는 OPTIONS 메서드의 요청. 이 요청의 목적은 실제 요청이 안전한지를 확인하는 것. 브라우저는 다음과 같은 정보를 포함하여 서버에 요청을 보냄.
Origin: 요청을 보내는 출처.
Access-Control-Request-Method: 실제 요청에서 사용할 HTTP 메서드.
Access-Control-Request-Headers: 실제 요청에서 사용할 커스텀 헤더들.
서버는 이 Preflight 요청에 대해 적절한 CORS 헤더를 포함하여 응답해야 한다. 만약 허용된 출처와 메서드가 확인되면, 브라우저는 실제 요청을 보냄.
