백엔드에서는 잘 작동되던 api가 프론트에서 불러올 때 cors문제가 발생한다.
SOP (Same-origin Policy)
동일한 URL출처간 접근만 허용하는 정책이다.
구글에 로그인을 하면 쿠키에 나의 인증정보가 저장되어 구글페이지를 이동 할 때마다 로그인을 하지 않아도 된다. 이 점을 해커가 악용해서 가짜 uri를 열도록 유도하고 악성코드로 무장된 자바스크립트 코드가 구글 인증쿠키를 탈취해서 해커의 서버로 전송시킬 수도 있다. 이 때 브라우저는 cors에러로그를 띄우며 해당 접근을 차단하고 정보를 보호해 준다.
CORS (Cross-Origin Resource Sharing)
sop와 반대되는 개념으로 다른 출처간의 자원을 공유하는 개념이다.
하나의 사이트에서 외부api를 사용하고자 하는 경우가 발생한다면 sop에 걸리지 않도록 cors를 설정해주어야한다. 설정은 브라우저의 기본설정인 타URL간 정보 전송 및 반환금지를 백엔드 코드에서 공유가능하도록 명시 할 수 있다.
이렇게 명시를 해두면 프론트단에서 외부api에 접근 할 때 sop에 의해서 차단되는 것을 피할 수 있다.
CORS 원리 및 데이터 흐름
브라우저가 외부 api를 요청 할 때 Origin이라는 헤더를 request데이터 맨 앞에 붙여서 요청한다. 그럼 response헤더에 acao필드가 정의되어 있고 acao값이 보냈던 origin값과 동일하면 브라우저는 데이터를 받아오게 된다.
Simple request
만약 토큰과 같은 민감한 정보를 요청하면 아래와 같이 추가적인 데이터 전송이 필요하다.
프론트는 쿠키를 정확히 명시하고 백엔드도 true응답을 줘야하는 프론트와 백엔드간의 좀 더 엄격한 기준이 적용된다.
Preflight request
Get Post Head 메소드와 다르게 put delete같은 메소드는 simple보다 엄격한 확인절차가 포함된다. 데이터를 수정하는 메소드는 서버에서 실행만되고 응답에 에러가 날 수 있기 때문에 먼저 Preflight request요청을 보내서 요청이 안전한지 확인한다. 그 후에 본 요청을 보내서 서버 데이터를 수정하고 응답을 받는 방식으로 이루어진다.
출처
https://educatedguesswork.org/posts/web-security-model-cors/
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
