CORS(Cross Origin Resource Sharing)는 출처가 다른 곳의 리소스를 요청할 때 접근 권한을 부여하는 메커니즘입니다. 리소스를 주고받는 두 곳의 출처가 다르면 출처가 교차한다고 합니다. 이때 출처에는 프로토콜, 호스트, 포트가 포함됩니다. 만약 클라이언트의 출처가 허용되지 않았다면 CORS 에러가 발생할 수 있습니다.
CORS는 왜 필요한가요?
과거에는 CSRF(Cross Site Request Forgery)라는 사이트 간 요청 위조 문제가 있었습니다. CSRF는 피해자를 사칭해 피해자의 브라우저에서 다른 애플리케이션으로 원치 않는 작업을 수행하게 만드는 공격 기법입니다.
CSRF를 예방하기 위해 브라우저는 SOP(Same Origin Policy)라는 동일 출처 정책을 구현했습니다. SOP가 구현된 브라우저는 클라이언트와 동일한 출처의 리소스로만 요청을 보낼 수 있습니다.
하지만, 웹이 발전함에 따라 다른 출처의 리소스를 사용하는 경우가 많아졌기 때문에 SOP는 한계가 있습니다. 따라서 SOP를 확장한 CORS가 필요합니다.
CORS는 어떻게 작동하나요?
CORS 작동 방식에는 대표적으로 세 가지가 있습니다.
첫 번째는 예비 요청(Preflight Request)입니다. 브라우저는 요청을 한 번에 보내지 않고, 예비 요청과 본 요청으로 나누어 서버에 전달합니다. 이때 브라우저가 예비 요청을 보내는 것을 Preflight라고 하며, 이 예비 요청의 메서드는 OPTIONS가 사용됩니다.
예비 요청은 본 요청을 보내기 전에 브라우저 스스로 안전한 요청인지 확인하는 역할을 합니다.
두 번째는 단순 요청(Simple Request)입니다. 예비 요청 과정 없이 바로 서버에 본 요청을 보낸 후, 서버가 응답 헤더에 Access-Control-Allow-Origin 헤더를 보내주면 브라우저가 CORS 정책 위반 여부를 검사하는 방식입니다.
단순한 방식인 만큼 HTTP Method, Header, Content-Type의 제약 사항을 만족한 경우에만 가능합니다.
마지막 세 번째는 인증된 요청(Credentialed Request)입니다. 클라이언트에서 서버에게 자격 인증 정보를 실어 요청할 때 사용되는 방식입니다. 자격 인증 정보는 쿠키 또는 Authorization 헤더에 설정하는 토큰 값이 될 수 있습니다.
이 방식은 서버에서 Access-Control-Allow-Credentials를 true로 설정해야 하며, Access-Control-Allow-Origin(Method, Headers)에 와일드카드(*)를 사용하지 못한다는 특징이 있습니다. 인증 정보는 민감한 정보이기 때문에 출처를 정확하게 설정해 주어야 한다는 의미입니다.
'백엔드 면접' 카테고리의 다른 글
| private 메서드에 @Transactional을 선언하면 트랜잭션이 동작할까요? (0) | 2024.12.24 |
|---|---|
| 포워드 프록시와 리버스 프록시의 차이에 대해 설명해 주세요. (0) | 2024.12.23 |
| 갭락과 넥스트키 락은 무엇이며, 어떻게 팬텀 리드를 방지하나요? (0) | 2024.12.19 |
| 데이터베이스 시스템에서 동시성을 제어하는 방법에 대해서 설명해주세요. (0) | 2024.12.18 |
| HTTP 메서드에서 멱등성이란 무엇인가요? (0) | 2024.12.17 |