-
---
https://finepiz.tistory.com/240
웹이라는 것이 리소스를 쉐어하기 위해 쓰는 것
근데 보안규칙 SOP라는게 생겼다, 다른서버에 있는걸 연동할 이유가 별로 없었다. 그래서 script를 이용해서 가져오는건 같은 origin으로 한정한다. 흔히 말하는 ajax할 때 자원을 가져오는건 같은 동네것만 가능하다. 보안 때문에.
CORS는 SOP정책을 완화하기 위한 정책이다. 도메인끼리 협약을 해-> 이쯤 sop cors라고 검색하면 되겠다 싶어서 검색
https://hudi.blog/sop-and-cors/
(이어서)다른 출처로 요청을 보내는것이 악의적인 행위로 간주됐어. 그래서 브라우저 차원에서 막음
근데 이제 웹 기술의 발전으로 프론트엔드 레이어와 백엔드 레이어가 별도로 구성되고, 다른 출처로 요청을 하고 응답을 받아오는 수요가 증가 -> CORS가 등장
리소스 호출이 허용된 출처를 서버가 명시해 놓는 것.
---
▽아니 잠깐 그래서 어떤게 위험한거고 그걸 누가 어디서 막는건데?
: 페이스북 자동로그인한 사용자가 어떤 악의적인 서버에 접속하면 자기 페이스북에 광고 컨텐츠가 올라간다 이걸 브라우저가 막아.
▽그럼 브라우저가 막는 상태에서 뭘 어떻게 하면 브라우저가 막는 효과를 가져가면서 또 안전한건 브라우저가 허용되게 할 수 있을지?
---
https://hudi.blog/sop-and-cors/ : 다시 여기로 와서
(1)단순 요청
브라우저가 다른 출처로의 요청을 보낼 때 자동으로 HTTP 헤더에 Origin을 추가하여 보낸다
이 응답을 받은 서버는 응답헤더에 Access-Control-Allow-Origin을 실어 보낸다. 이 헤더에는 허가된 출처 정보가 담겨있다
▽아 어쨌든 자원은 서버가 들고 있는거고 나쁜 행위는 서버와 서버사이에서 일어나는데,
브라우저가 물어보는거네 얘가 너것 이거 쓴대요~
그럼 페이스북에서 내 컨텐츠를 사용할 수 있는 Origin에 대해서 나열을 해놓겠네. 얘네가 아니면 하게 하지 마세요 브라우저님~! 하는거고
(2) Pre-flight Request : Content-Type이 application/json인 경우와 Cookie, Authorization같은 추가 헤더가 있을 때. 브라우저가 허용하고 파기하는 것이기 때문에 서버는 그냥 오는 요청을 다 처리하는데, get같은건 상관없지만 post put delete는 그냥 요청을 처리한다. POST도 조건만 만족하면 단순 요청으로 전송될 수 있으므로 백엔드에서도 이에 대한 처리가 필요하다.
실제 요청 보내기 전에 먼저 확인하는 방식, OPTIONS메소드로 요청
+실제 요청의 메소드를 Access-Control-Request-Method 헤더에
+실제 요청의 추가 헤더 목록을 Access-Control-Request-Headers 헤더에 담아 보내야 한다
=>이런 메소드와 헤더로 요청을 보낼 예정인데, 너희 서버의 CORS 정책에서 허용하는 요청이니?
응답은
Access-Control-Allow-Origin 헤더가 전송돼야하고
+허용하는 메서드 목록 Access-Control-Allow-Methods
+허가 헤더 목록이 담긴 Access-Control-Allow-Headers
+Preflight의 캐시기간인 Access-Control-Max-Age를 보낸다 --요청을 두번 보내야 하는 일이 발생하므로 이런 오버헤드를 줄이기 위해 캐시기간을 보낸다
(3)인증정보를 포함한 요청
쿠키, 토큰과 같이 사용자 식별 정보가 담긴 요청은 좀 더 엄격하게 처리하는데, 클라이언트가 요청할 때 credentials 옵션을 별도로 설정해줘야 한다. fetch API의 경우 same-origin, include, omit등의 옵션을 제공한다.
서버도 응답할 때 Access-Control-Allow-Credentials라는 헤더를 true로 설정해줘야 한다. 이때 Access-Control-Allow-Origin은 와일드 카드가 될 수 없다. 명확한 출처를 명시해줘야 한다.
---
https://hudi.blog/sop-and-cors/
이 블로그의 참고에 있는 사이트들 ㄱㄱ
---
이 문서들을 이해해보기
SOP
https://developer.mozilla.org/ko/docs/Web/Security/Same-origin_policy
동일 출처 정책 - 웹 보안 | MDN
동일 출처 정책(same-origin policy)은 어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식입니다. 동일 출처 정책은 잠재적으로
developer.mozilla.org
CORS
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://developer.mozilla.org/ko/docs/Web/HTTP/CORS
교차 출처 리소스 공유 (CORS) - HTTP | MDN
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라
developer.mozilla.org
'기타' 카테고리의 다른 글
Markdown (1) 2022.12.29 왜 서버 거쳐서 DB연결? (1) 2022.12.28 WordPress 강의 (1) 2022.12.08 행렬 (0) 2022.06.04 DDD와 이벤트 스토밍 (0) 2022.03.11