기타

CORS

finepiz 2022. 12. 20. 11:00

---

https://finepiz.tistory.com/240

웹이라는 것이 리소스를 쉐어하기 위해 쓰는 것

근데 보안규칙 SOP라는게 생겼다, 다른서버에 있는걸 연동할 이유가 별로 없었다. 그래서 script를 이용해서 가져오는건 같은 origin으로 한정한다. 흔히 말하는 ajax할 때 자원을 가져오는건 같은 동네것만 가능하다. 보안 때문에.
CORS는 SOP정책을 완화하기 위한 정책이다. 도메인끼리 협약을 해

-> 이쯤 sop cors라고 검색하면 되겠다 싶어서 검색

 

https://hudi.blog/sop-and-cors/

(이어서)다른 출처로 요청을 보내는것이 악의적인 행위로 간주됐어. 그래서 브라우저 차원에서 막음

근데 이제 웹 기술의 발전으로 프론트엔드 레이어와 백엔드 레이어가 별도로 구성되고, 다른 출처로 요청을 하고 응답을 받아오는 수요가 증가 -> CORS가 등장

리소스 호출이 허용된 출처를 서버가 명시해 놓는 것.

 

---

▽아니 잠깐 그래서 어떤게 위험한거고 그걸 누가 어디서 막는건데?

https://itstory.tk/entry/CSRF-%EA%B3%B5%EA%B2%A9%EC%9D%B4%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-CSRF-%EB%B0%A9%EC%96%B4-%EB%B0%A9%EB%B2%95

 : 페이스북 자동로그인한 사용자가 어떤 악의적인 서버에 접속하면 자기 페이스북에 광고 컨텐츠가 올라간다 이걸 브라우저가 막아.

 

▽그럼 브라우저가 막는 상태에서 뭘 어떻게 하면 브라우저가 막는 효과를 가져가면서 또 안전한건 브라우저가 허용되게 할 수 있을지?

 

---

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