SOP
SOP(Same-Origin Policy)는 같은 출처의 리소스만 공유가 가능하다는 정책이다.
여기서 출처란 프로토콜, 호스트, 포트의 조합으로, 이 중 하나라도 다르면 동일한 출처로 보지 않는다.
어떤 출처에서 가져온 문서, 스크립트 등을 다른 출처의 리소스와 상호작용하는 것을 막는다.
이를 통해 잠재적으로 해로울 수 있는 문서, 스크립트를 분리함으로써 공격받을 수 있는 경로를 줄인다.
예를 들어 로그인과 관련한 리소스를 가진 사용자가 그 리소스를 노리는 스크립트가 있는 사이트에 방문했다.
이 사용자는 SOP가 아니라면 그 리소스를 악용당할 여지가 있다는 것이다.
이러한 이점으로 거의 모든 브라우저가 SOP를 채택하고 있다.
하지만, WEP API를 사용하는 등 출처가 다른 리소스를 사용할 일이 너무나도 많다.
CORS
CORS(Cross-Origin Resource Sharing - 교차 출처 리소스 공유)는 추가적인 HTTP 헤더를 사용하여
다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 할 수 있다.
이를 통해 브라우저는 기본적으로 다른 출처의 리소스를 차단하지만, 권한을 부여함으로 상호작용할 수 있다.
CORS 요청
CORS 요청은 3가지 방법이 있다.
1. 프리플라이트 요청 (Preflight Request)
실제 요청을 보내기 전, OPTIONS 메서드로 사전 요청을 보내 해당 출처 리소스에 접근 권한이 있는지부터 확인하는 것이다. 만약 요청을 보낸 출처가 접근 권한이 없다면 브라우저에서 CORS 에러를 출력한다. 요청 역시 처리되지 않는다.
이는 실제 요청을 보내기 전에 권한을 확인하기 때문에 처음부터 보내는 것보다 효율적이다.
CORS에 대한 조치가 없더라도 프리 플라이트 요청을 통해 먼저 접근 권한을 확인한다면 CORS 에러를 띄운다.
2. 단순 요청 (Simple Request)
단순 요청은 특정 조건이 만족되면 프리플라이트 요청을 생략하고 요청을 보낸다.
- GET, HEAD, POST 요청 중 하나여야 한다.
- 자동으로 설정되는 헤더 외에, Accept, Accept-Language, Content-Language, Content-Type 헤더의 값만 수동으로 설정할 수 있다.
- Content-Type 헤더에는 application/x-www-form-urlencoded, multipart/form-data, text/plain 값만 허용된다.
3. 인증정보를 포함한 요청 (Credentialed Request)
요청 헤더에 인증 정보를 담는다. 출처가 다를 경우에는 별도의 설정을 하지 않으면 쿠키를 보낼 수 없다.이 경우에는 프론트, 서버 양측 모두 CORS 설정이 필요하다.
프론트 측 요청 헤더 withCredentials : true
서버 측 응답 헤더 Access-Control-Allow-Credentials : true
서버 측에서 Access-Control-Allow-Origin 을 설정할 때, 모든 출처를 허용한다는 뜻의 와일드카드(*)로 설정하면 에러가 발생한다. 정확한 출처를 적는다.
