CORS

CORS

• 개발을 하면서 만나게 되는 cors 에러

• 출처에 접근을 하지 못한다는데 무슨 출처를 뜻하는걸까?

출처란?

• 이 url 중에서 출처에 해당하는 부분은

• 여기까지 이다.

• 다른 출처의 예시

• 브라우저는 출처를 구별하고 서버의 리소스를 요청할때 공유를 해도될지 판단하며 판단 기준은 다음 두가지 기준 정책을 따르고 있다.
• SOP(Same-Origin-Policy) : 같은 출처끼리만 공유하는 리소스 정책이다.



• 출처가 다른 사이트간 통신은 보안에 취약할 수밖에 없다 !
• 공유범위를 같은 출처로 만들면 외부의 공격을 원천봉쇄할 수 있기 때문에 SOP을 사용해!
• 하지만 웹은 다른 출처의 리소스를 가져다 쓰는 경우가 많기 때문에 예외조항으로 CORS 정책을 두고있다.

CORS

• http 헤더의 정보를 통해 다른 출처에 접근할 권리를 부여하는 정책

• 브라우저가 중계자가되어 콜스 위반 여부를 따진다.

• 예시 1
• 클라이언트가 다른 출처의 리소스를 달라고하면 브라우저는 헤더의 오리진에 클라이언트 출처를 입력하고 이를 서버로 보낸다.

• 서버는 Access-control-allow-origin : 허가된 출처 목록으로 응답하게 된다.

• 브라우저는 응답된 목록에 클라이언트 출처가 있는지 확인한다. 있다면 접근을 허용하고 없으면 CORS 에러를 띄우게 된다.

• 자신의 요청이 어떤 cors 시나리오에 해당하는지 알아야한다. 그 이유는 어떤 부분때문에 에러가 낫는지 알아야 고치기 쉽기 때문이다.

• 예시 2
• 간단한 요청이 아니면 브라우저는 서버에 요청을 하기 전에 options 메소드를 사용해 preflight 즉 예비 요청을 먼저 보내게된다.
• 예비요청에 성공하면 서버는 응답헤더에 허가정보를 넣어 브라우저에 전송하는데 통과된 경우에만 본 요청을 넣는다.
• 이때 cors 에러가 발생한다면 서버가 header로 보낸 허가정보와 너가 다른가봐..

• 예시 3

• 크레덴셜 리퀘스트 서버의 쿠키나 인증정보를 가져오도록 크레덴셜 설정을 바꿀 수 있는데 이경우 더 엄격한 cors 검사를 한다.

• 서버가 허락했다고 해도 인증정보를 막 줄 수는 없다. 아무곳에나 인증정보를 주기때문에 보안에 문제가 생기며 다음과 같이 응답헤더를 바꿔주어야 한다.

CORS 의 필요성

• 웹은 모두에게 열려있다. 즉 사용자 공격에 취약하다.

• 코드 열람이 가능하고

• 스크립트 조작을 할 수 있다.

• 그러다 보니 CSRF, XSS 같은 사용자 공격에 노출될 수 있다.

• 이러한 상황을 막기위해 이러한 정책이 필요한 것이다.

CORS 에러 해결법

• 프론트엔드 해결법
• CORS 우회하기
• 미들웨어가 시작된 다음 프록시 서버에 백엔드 출처를 넣으면

• 백엔드 해결 방법

• 기본 메소드 Get Post 만 제공하고 다른건 거부된다.

• 이처럼 코드를 변경해주어야 한다.

• 하지만 * 넣으면 모든 출처가 접근 허가가 되기 때문에 보안에 좋지 않다. 직접 입력해주는 것이 좋다.

REF

[2기] CORS - i조 하신영

CORS에 대한 이해와 에러 해결방법 발표

https://present.do/presentations/62510bf112168b359e2e5310?page=0