#5

 

 

CORS (Cross-Origin Resource Sharing)

 

교차 출처 리소스 공유

 

 

브라우저에서 토큰 탈취 등의 나쁜 목적을 위해 외부 프론트엔드 가상 사이트 운용을 통해 다른 웹 서버로의 잘못된 요청을 막아내기 위해 만들어진 SOP (Same Origin Policy) 동일 출처 정책을 위반할 때 나타나는 오류이다

 

브라우저에서 막고 있는 것이기 때문에 웹 서버끼리의 통신은 아무 문제 없다

(ex. Tomcat => Naver server)

 

브라우저는 기본적으로 동일한 출처(통신 방식[http,ftp,telent], 도메인[~.com], 앱포트[:8080])가 아닌 다른 출처의 API로부터의 데이터 요청을 막는 것이 디폴트 값인데 이것을 풀어주고 특정 출처(프론트)로부터의 요청에는 교차 출처 리소스를 허용시켜주는 것이 CORS 이다

 

(예를 들어 로컬환경이라면 localhost:3000 = 요청 => localhost:8080 으로 요청을 보낼 때 CORS 뿜뿜)

 

프론트에서도 CORS를 할 수 있는 방법이 있지만 편법이고, 웹 서버에서 해당 출처의 CORS 요청을 풀어주는 방법이 합법적이다 (프론트에서 네이버 등의 API로 데이터를 요청할 때 CORS가 필요하고 네이버에서 해당 API에 대해 따로 CORS 허용을 해두지 않았다면, 관련 네이버 CORS 페이지에 자신의 출처를 등록해야한다)

 

특히 GET, POST 등을 제외한 PUT, DELETE 등의 DB에 변화를 줄 수 있는 요청에는 추가적으로 preflight 설정을 해줘야만 CORS가 가능하다 (보안 정책이라 조건이 빡빡하다)

 

모두 웹 서버에서 해줘야 할 일이므로 만약 외부 API(네이버, 카카오 등)에서의 데이터가 필요한 경우라면 서버에서 통신해 데이터를 끌어와 CORS를 허가한 프론트에 뿌려주는 것이 좋다

 

서버 사이드 렌더링 해서 배포할 목적이라면 이딴 거 무시해도 됨

결국 같은 포트에서 정적 파일이고 동적파일이고 다 뿌려주니 SOP에 위반되지 않는다

 

스프링부트에서는 그냥 세큐리티 설정 클레스에서 webmvcconfigurer 상속받고 CORS 뭐시기 서비스 메소드 오버라이드 한담에 풀어주고 싶은 애들 체인메소드로 풀어주면 된다