• [10분 테코톡] 🌳 나봄의 CORS
• https://developer.mozilla.org/ko/docs/Web/HTTP/CORS
• https://vvshinevv.tistory.com/60

---

✅Origin

Origin(출처)
특정 페이지에 접근할 때 사용되는 URL의 Scheme(프로토콜), host(도메인), 포트를 말한다.

• same-origin : scheme(프로토콜), host(도메인), 포트가 같다는 말
• cross-origin : 이 3가지 중 하나라도 다른 경우

📌예시

1. https://localhost
2. http://localhost:80
3. http://127.0.0.1
4. http://localhost/api/cors
   에서 2,4번만 같은 출처이다.

• 1번 👉 프로토콜이 https이다
• 2,4번 👉 프로토콜 http, 호스트 localhost, 포트 80 이 동일하므로 동일출처이다. (4번에서 path/api/cors는 출처판단에 의미없는 정보이다)
• 3번 👉 호스트 127.0.0.1의 ip는 localhost가 맞지만, 브라우저는 호스트 정보의 String Value만으로 비교하기때문에 localhost와 다른 출처라 여긴다

✅SOP

SOP(Same Origin Policy)
다른 출처의 리소스를 사용하는 것에 제한하는 보안 방식

📌SOP 방식

1. 사용자가 페이스북에 로그인 👉 인증토큰을 받는다
2. 해커는 사용자에게 http://hacker.ck 링크를 보낸다
3. 사용자는 http://hacker.hk 링크를 누른다 👉 자신의 페이스북 인증 토큰을 약탈당한다
4. http://hacker.hk 링크를 통해 페이스북 포스트 게시 요청을 한다
5. 페이스북은 자신의 Origin(https://www.facebook.com/)과Origin(http://hacker.ck)가 서로 다른 출처임을 판단한다
   👉 Cross Origin
   👉 SOP에 위반된다
   👉 해당 요청을 받아들이지 않는다.

✅CORS

CORS(Cross-origin Resource Sharing)
교차 출처 리소스 공유(CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 어플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.
👉 다른 출처의 자원에 접근한다는 사실을 브라우저에게 알려주는 체제이다
👉 다른 출처의 리소스를 공유하는 방법인 CORS를 이용하여 다른 출처의 리소스를 사용한다

📌CORS 접근제어 시나리오

👏Preflight Request

Preflight Request
OPTION 메소드를 통해 다른 도메인의 리소스에 대한 요청이 가능한지 확인한 뒤, 가능한 경우 실제 요청(Actual Request)를 보내는 작업.

🥦 Preflight 과정

🥦 Preflight Request 포맷

OPTIONS /resources/post-here/ HTTP/1.1
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

• 3가지 정보
  👉 요청 출처(Origin),
  실제 요청의 메소드(Access-Control-Request-Method),
  실제 요청의 추가 헤더(Access-Control-Request-Headers)

🥦 Preflight Response 포맷

Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

• 4가지 정보
  👉 서버 측 허가 출처(Access-Control-Allow-Origin),
  서버 측 허가 메소드(Access-Control-Allow-Methods),
  서버 측 허가 헤더(Access-Control-Allow-Headers),
  preflight 응답 캐시 기간(Access-Control-Max-Age)
• 응답 코드는 200대여야 한다
• 응답 body는 비어있는 것이 좋다

👏Simple Request

Simple Request
preflight 요청없이 바로 요청을 날린다.

🥦 Simple Request 과정

🥦 Simple Request가 만족해야하는 조건

1. 서버 측 허가 메소드(Access-Control-Allow-Methods)
   👉 GET, POST, HEAD만 가능
2. 유저 에이전트가 자동으로 설정한 헤더 외에, 수동으로 설정 가능한 헤더
   👉 Accept, Accept-Language, Content-Language, Content-Type 만 허용
3. Content-Type 헤더로 허용된 값
   👉 application/x-www-form-urlencoded, multipart/form-data, text/plain

❓ 그럼 Preflight는 왜 필요할까 ❓

CORS spec이 생기기 이전에 만들어진 서버들은
브라우저의 SOP(same origin policy) request만 가능하다는 가정하에 만들어졌었다.
cross-site request가 CORS로 인해서 가능해졌기 떄문에
이런 서버들은 cross-site request에 대한 security mechanism이 없다보니 보안적으로 문제가 생길수 있으니, 이런 것들로 보호하기 위해 CORS spec에 preflight request를 포함한 것이다.
👉 Preflight request로 서버가 CORS를 인식하고 핸들할 수 있는지 먼저 확인을 함으로써 CORS를 인식하지 못하는 서버들을 보호할 수 있게 된다.

🥦 Preflight 없이 바로 Actual Request를 보낼 경우의 문제

• 클라이언트는 CORS 관련 설정이 없는 서버에 request를 보낸다
• 브라우저는 클라이언트의 origin (bom.com) 정보를 서버에게 전달한다
• 서버는 브라우저를 통해 받은 클라이언트의 request에 맞는 작업을 수행한다(심각한 문제)
• 하지만 서버는 allow-origin 정보가 없는 response를 브라우저에 보낸다
• ❗❗ 그제서야 브라우저에서 CORS 에러를 발생시킨다.
  
• preflight를 통해, 서버에서 의도치 않은 작업이 수행되는 것을 막을 수 있다

👏Credentialed Request

Credentialed Request
인증 관련 헤더를 포함할 때 사용하는 요청이다. (쿠키, JWT 토큰을 클라이언트에서 헤더에 담아서 서버로 전달할 때 사용하는 요청방식)

🥦 Credentialed Request을 사용하기 위한 조건

• 클라이언트 측
  • Credentialed Request을 보내기 위해서 credentials : include 설정한다
• 서버 측
  • Credentialed Request을 받기 위해서 Accestt-Control-Allow-Credentials : true 설정해야 한다.
  • Accestt-Control-Allow-Credentials : true 설정을 하면, Access-Control-Allow-Origin : *으로 설정하면 안된다. 특정한 origin을 설정해줘야한다.

📢 CORS 정책 위반 에러 해결방법

👏프론트 프록시 서버 설정

• 브라우저는 클라이언트의 8081포트의 request를 front server에 보낸다
• front server에 proxy 설정한다
  • bom.com:8081/api/~와 같이 path에 api가 포함된 경우 포트번호를 8080으로 변경한뒤 서버로 요청을 전달한다
    👉 포트를 8080, 8081로 바꿔가면서 request하지 않고 8081으로 통일하여 request하기 때문에 CORS 에러가 발생하지 않는다.
    

👏스프링 부트에서 설정

•