티스토리 뷰
이 글에서는 SOP, CORS, CORS 동작 방식에 대해 설명한다. 프로젝트에서 코드로 CORS 정책 설정하는 방법에 대해서는 아래 포스팅을 참고하기 바란다.
Spring boot 환경에서 CORS 정책 설정하기 (Feat. Spring Security)
이번 글에서는 Spring Boot 환경에서 CORS 이슈를 경험하고 해결한 과정을 정리했다. 혹시 CORS를 모르거나 관련된 배경지식에 대해 궁금하다면 아래 포스팅을 참고하면 좋을 것 같다. SOP와 CORS 최근
bool-flower.tistory.com
SOP (Same Origin Policy)
어떤 origin에서 불러온 문서 또는 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 보안 방식
여기서 origin은 출처를 의미한다. 출처에 대한 자세한 내용은 여기를 참고하기 바란다. SOP는 서로 다른 출처 간에 데이터를 주고받을 때는 브라우저가 제한을 한다는 의미다. 같은 출처끼리만 데이터를 주고받을 수 있도록 제한하면, 신뢰할 수 없는 다른 출처로부터 오는 요청은 접근을 못하게 막을 수 있기 때문이다.
이 영상에서는 SOP가 없는 경우 다음과 같은 위험이 있다고 말한다.
- iframe을 이용한 정보 탈취
- XMLHttpRequest를 이용한 정보 탈취
다른 출처 간에 통신을 허용해야 할 때가 있는데, 이때 CORS(Cross-Origin Resource Sharing)를 이용한다.
CORS (Cross-Origin Resource Sharing)
서로 다른 출처의 리소스와 통신할 수 있도록 브라우저에 알려주는 체제
서버에서 응답 헤더의 Access-Control-Allow-Origin에 허용할 origin을 작성해주면 해당 출처의 요청을 허용하게 된다.
아래는 응답 헤더의 Access-Control-Allow-Origin 값으로 https://developer.mozilla.org라는 origin을 추가한 예시이다. 이러면 서버에서는 https://developer.mozilla.org 로부터의 요청을 허용한 것이 된다.
Access-Control-Allow-Origin: https://developer.mozilla.org
이 밖에 다른 헤더 설정들
- Access-Control-Request-Methods
- 리소스 접근을 허용하는 HTTP 메서드를 지정해 주는 헤더 (ex: GET, POST, PUT 등) - Acess-Control-Max-Age
- preflight 요청 결과를 캐시 할 수 있는 시간 설정 (ex : 60)
- 첫 요청 이후 설정한 시간만큼 OPTIONS 메서드를 사용하는 예비 요청을 보내지 않음 - Access-Control-Allow-Credentials
- Credentialed Request에서 인증에 관련된 헤더를 요청에 담기 위해 설정하는 값 (아래의 Credentialed Reqeust 참고)
CORS 시나리오
Preflight Request
Preflight Request는 예비 요청을 의미한다. 위 그림은 클라이언트에서 get 요청을 한다고 가정한 것이다.
- options 요청
- 서버에서 Access-Control-Allow-Origin과 허용된 메서드 등 정책에 관한 정보 응답
- 응답받은 브라우저는 허용 정책 비교
- 본 요청(여기선 get)을 보내기에 안전하다고 판단되면 본 요청을 보냄
- 본 요청에 대한 resource 전달 받음
Simple Request
Simple Request는 본 요청부터 보낸 후, 응답받는 헤더를 통해 바로 CORS 정책을 검사한다. Preflight Request에서 예비 요청만 없을 뿐이다. 하지만 이 동작은 세 가지 조건을 만족해야만 할 수 있다.
- GET, HEAD, POST 만 요청 가능
- Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용 불가능
- Content-Type를 사용하는 경우 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용
사용자 인증에 사용되는 Authorization 헤더나 application/json 콘텐츠 타입이 허용되지 않기 때문에 잘 사용되지 않는 방식이다.
Credentialed Request
인증된 요청을 사용하는 방법이다. 쿠키 정보라든지 인증과 관련된 헤더를 요청에 담기 위해 credentials 옵션을 사용한다. 이 옵션은 아래 세 가지 값을 사용할 수 있다.
- same-origin (기본값) : 같은 출처 간 요청에만 인증 정보를 담는다.
- include : 모든 요청에 인증 정보를 담는다.
- omit : 모든 요청에 인증 정보를 담지 않는다.
이 중 include를 사용한 경우 다음 두 가지를 조건을 충족하는지 추가로 검사한다.
- Access-Control-Allow-Origin에는 *를 사용할 수 없으며, 명시적인 URL 이어야 함
- 응답 헤더에는 반드시 Access-Control-Allow-Credentials: true가 존재해야 함