맨날 헷갈려서 이참에 정리해둠

CORS 정책

무엇을 위한 것인가

• CORS는 브라우저 보안 정책일 뿐, 서버 보안 정책이 아님.
• curl이나 Postman 같은 비브라우저 환경에서는 애초에 CORS 보호를 기대하지 않아.
  (걔네는 아무 요청이나 다 할 수 있어야 하니까.)

즉, CORS는 사용자를 보호하는 거지 서버를 보호하는 건 아님.

서버 자체를 보호하고 싶으면 JWT, OAuth 인증, 서버 측 Access-Control, rate limit 등을 따로 걸어야 한다.

• 즉, CORS는 브라우저를 이용한 보안위반을 막기 위한 것이지, 모든 보안 위협 요청을 차단하려는 목적이 아니다.

누가 정책을 정하는가

• 보통 리소스를 제공하는 백엔드 서버에서 정한다.(고 생각하면 일단 이해가 쉽다)
• CORS 허용 목록은 서버가 응답을 주면서 어느 origin에서 온 요청일 경우에만 응답을 신뢰하라고 브라우저에 알려주는 역할을 한다.
• 즉, 어느 경우에든 서버가 응답은 준다. 근데 cors 정책을 같이 응답에 명시해주면서, 브라우저가 이 정책에 위반되는 경우에는 응답을 클라이언트에 제공하지 않도록 하는 것.

origin이 뭐냐면

• 요청의 출처: 즉 example.com:443에 접속했을 때 제공된 페이지에서 이미지를 api.com:8888에서 가져오라고 했다면, api.com:8888에 보낸 요청의 origin이 example.com:443이다.
• 만약 api.com:8888에서 example.com:443이 origin인 요청을 허용하고 있다면 브라우저는 응답을 받아와 이미지를 표시해 주겠지만, 그렇지 않다면 차단한다.
• Origin은 프로토콜, 도메인, 포트까지 합친 단위로 구분된다. 예: https://example.com:8080

왜 이런 정책을?

• 사용자의 이메일 서버로 응답을 받아와 공격자에게 전달하는 악성 웹페이지가 있다고 하자. 만약 이메일 서버에서 악성 웹페이지를 cors허용하지 않고 있다면 브라우저가 응답을 차단하므로 공격자에게 전달되지 않을 것이다.
  이런 브라우저를 이용한 보안 위반을 차단하기 위한 것이다.

막을 수 없는 것

• 스크립트 삽입을 통한 동일 origin에서의 악성 요청
• 브라우저를 거치지 않고 서버를 목표로 한 거짓/악성 요청