[10분 테코톡] 🌳 나봄의 CORS

SOP(Same Origin Policy)

• 다른 출처의 리소스를 사용하는 것에 제한하는 보안 방식

  https: (프로토콜)
  //github.com(호스트)
  :443(포트)
  /cheorhyeon?tab=repositories#example

• 출처(origin)란?
  • Protocol, Host, Port를 통해 같은 출처인지 다른 출처인지 판단할 수 있다.
  • 모두 같아야 동일 출처
  • 인터넷 익스플로러 : Port가 달라도 동일 출처로 인식
• localhost와 127.0.0.1을 브라우저에서는 다르게 인식
  • String Value로 비교하기에 다른 출처로 인식

왜 SOP를 사용해야 할까? 보안에 위함

선량한 사용자
1. 페이스북 서비스 로그인 이후 사용(페이스북에서 인증 토큰을 받아옴)
2. 해커 : 흥미진진한 내용과 링크를 메일을 통해 보냄
3. 링크를 클릭하니 hacker.ck 로 이동됨

• 해당 링크는 페이스북에 나는 바보다 라는 포스트 게시 하라는 코드 내포

4. hacker.ck에서 선량한 사용자의 토큰을 이용해 페이스북에 나는 바보다 포스트 게시
5. origin이 다름
   • 해커 : hacker.ck != 페이스북 : https://www.facebook.com/
   • 즉 다른 Origin -> Cross Origin 이라 판단하고 요청은 받아들여지지 않음

만약 다른 출처의 리소스가 필요하다면?

• CORS 필요!

---

CORS(Cross-Origin Resource Sharing)

• 교차 출처간 리소스 공유
• 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저 알려주는 체제

CORS 접근제어 시나리오

• 단순 요청(Simple Request)
• 프리플라이트 요청(Preflight Request)
• 인증정보 포함 요청(Credentialed Request)

프리플라이트 요청(Preflight Request) : 사전 확인 작업

• OPTIONS 메서드를 통해 다른 도메인의 리소스에 요청이 가능한 지 확인하는 작업
  • (Preflight Request) 요청을 이렇게 보낼건데 가능하니? 라고 물어보는 요청
  • (Preflight Response) 서버측에서 가능한지에 대한 응답
  • 요청이 가능하다면 실제 요청(Actual Request)를 보낸다.

Preflight Request 요청 포맷

• Origin : 요청 출처
• Access-Control-Request-Method : 실제 요청 메서드
• Access-Control-Request-Headers : 실제 요청의 추가 헤더

Preflight Response 응답

• Access-Control-Allow-Origin : 서버측 허가 출처
• Access-Control-Allow-Methods : 서버 측 허가 메서드
• Access-Control-Allow-Headers : 서버 측 허가 헤더
• Access-Control-Max-Age : preflight 응답 캐시 기간

Access-Control-Max-Age 설정 필요 이유

• Preflight 요청을 보내야 할 경우 실질적으로 2번 요청이 보내진다.
  • Preflight로 요청 가능한지 확인 + 실제 요청
  • 매번 2번 보내야하는 것은 비효율
  • 따라서 프리플라이트 응답 캐싱 해두고 요청이 오면 사전 확인 없이 바로 보내는거 받아들임
    • PREFLIGHT RESPONSE 속성 중 Access-Control-Max-Age

Preflight Response가 가져야 하는 특징

• 응답 코드는 200대여야 한다.
• 응답 바디는 비어있는 것이 좋다.

---

단순 요청(Simple Request)

• preflight와 다르게 바로 본 요청을 날리면서 그 즉시 Cross Origin인지 확인하는 절차

아래 조건 모두 충족해야 Simple Request

• GET, POST, HEAD 메서드 만족
• Content-Type 아래 3가지 중 하나
  • application/x-www-form-urlencoded
  • multipart/form-date
  • text/plain
• 헤더는 Accept, Accept-Language, Content-Language, Content-Type만 허용

Simple Request 흐름

왜 Preflight가 필요할까?

• Simple Request 한방이면 끝나는건데 왜 굳이 2번(Preflight 요청 까지) 가야할까?
• CORS를 모르는 서버를 위해서라고 이해하는 것이 편함

CORS 모르는 서버

• CORS 아무런 설정 없는 서버
  • 예 : simple한 get요청
  • 서버에서는 CORS 설정을 아무것도 안함
  • 그대로 응답 반환하는데 ALLOW-ORIGIN이 없기에 브라우저에서 CORS 에러!라 응답
    

Preflight가 없다면?

• 만일 delete 메소드를 사용하여 통신하는데 Preflight 요청이 없다면
  • 실제 서버에서는 Data 삭제 및 성공 응답
  • SOP 위반이라 CORS 에러를 브라우저에서 내는데 이미 서버에서는 삭제처리가 된 상황
• 즉 CORS 에러를 실제 데이터가 삭제된 다음에 응답받기에 심각한 문제일수도 있음

Preflight 요청 흐름

• Preflight는 사전 요청으로 서버에서 어떤 동작을 하지 않음
• Preflight 요청이 실패한 경우 실제 요청을 보내지 않음
  • 서버는 안전하게 잘 지켜짐

인증정보 포함 요청(Credentialed Request)

• 인증 관련 헤더 포함할 때 사용하는 요청
  • JWT를 클라이언트에서 자동으로 담아서 보내고 싶을때 credentials를 include
• 클라이언트측 credentials : include
• 서버측 Access-Control-Allow-Credentials : true
  • Access-Control-Allow-Origin: *는 안됨, 특정 url 명시 필요
    • Credentials true인데 Origin *면 예외 터짐

---

CORS 해결

프론트 프록시 서버 설정(개발 환경)

• 브라우저에서 8181 -> 프론트 8081 받아서 서버 8080으로 토스
• 내부적으로 8080 포트로 바꿔서 요청 처리
• 응답할때 8081로 응답

직접 헤더에 설정

• 영상에서 넘어감
• 다소 번거로움

스프링 부트 이용 해결

실습

Preflight 없는 경우 예시(Simple Request Get)

• 8081 포트에서 8080 서버로 api 요청
  • 실제로 Server에서 OK로 응답
  • 하지만 브라우저에서 CORS 문제 발생
  • 위에서 언급한대로 preflight 없었더라면..!

Spring @CrossOrigin 어노테이션

• 컨트롤러에 설정하면 끝남
• 개별 메서드도 가능

// origins 설정 안하면 default 전체일듯
@CrossOrigin(origins = "http://localhost:8081")

// 오류!
@CrossOrigin(origins = "*", allowCredentials = "true)

• 위에서 언급한대로 아래 설정을 두개 같이 동시 사용하면 오류남 확인
  • origins = *
  • allowCredentials = "true"

WebMvcConfigurer 구현체

• @CrossOrigin 어노테이션의 경우 필요한곳에 모두 붙여야 한다.
• 전역적으로 설정하기 위해 CorsConfiguration 생성

@Configuration
public class CorsConfiguration implements WebMvcConfigurer  {

  @Override
  public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/api/**")
    .allowedOrigins("http://localhost:8081");
  }
}