CORS

 

Q . CORS란? 사용하는 이유. 동작 방식에 대하여

Q . 개발을 하면서 CORS 관련하여 경험하였던 이슈 -> 해결 방법은?

 

 

CORS(Cross Origin Resource Sharing)

합의 된 출처들 간의(Cross Origin) 요청을 허용해주기 위해(Resource Sharing) 만들어진 규칙

 

SOP(Same-Origin Policy)

 : 같은 출처끼리만 리소스를 공유할 수 있다.

- 웹 브라우저에 내장된 기본 정책

 

CORS 설정을 하지 않은 경우 SOP 정책에 의한 에러

- http://localhost:3000 에서 http://localhost:8080/api/v2/products 로의 접근이 CORS 정책에 의하여 차단되었다.

 

 

보통 프론트 단에서 API로 정보를 받아오기 위해 HTTP 요청을 보냈을 때 접하게 되는 에러

브라우저에서 출처(Origin)가 다른 곳과 요청을 주고 받는 것을 허용하지 않아 생기게 됨.

 

=> CORS라는 예외 규칙을 만들어 출처는 다르지만 합의 된 출처들 간의 요청을 허용

 

 

출처(Origin)

 

URL의 구조(https://www.grabbing.me/URL-018cdd1bb4b541fab6246569244fcf93)

Origin : Protocol + Host + Port

 

 

 

 

Ex)

http://localhost:8080/api/v1/products

 

http://localhost:3000	x	포트 번호가 다름
https://localhost:8080	x	프로토콜이 다름
http://localhost:8080/new-order	o	경로는 다르지만 출처는 동일

 

 

 

 

CORS를 사용하는 이유

소스 코드와 같은 정보가 노출되기 쉬운 웹 클라이언트 환경에서, 

(개발자 도구를 키거나, 페이지 소스 보기 등으로 소스 코드가 노출되는 것과 같은)

 

다른 출처와의 통신 시

XSS, CSRF와 같은 공격으로 악성 소스가 삽입되거나, 정보가 탈취될 수 있는 위험 가능성이 존재함.

 

=> 요청 및 응답에 대해 CORS 정책을 준수하는지를 검사하여 안전한 요쳥인지를 판단하기 위함

 

 

 

CORS의 동작 방식

- 요청 시 헤더 Origin 필드에 요청을 보내는 출처를 함께 담아 전송(OPTIONS)

- 이후 서버에서는 응답 헤더의 Access-Control-Allow-Origin 필드를 통해 리소스에 대한 접근이 허용된 출처를 담아 응답 전송

- 응답을 받은 브라우저는 자신이 보냈던 Origin과 Access-Control-Allow-Origin을 비교하여 유효성 여부를 판단

 

 

Preflight

예비 요청을 통하여 CORS 정책 위반 여부를 판단하고,

후에 본 요청을 보냄

 

Preflight

 

 

예비 요청

예비 요청에 대한 응답

Access-Control-Allow-~ 필드를 통하여 CORS 정책을 확인한 후, 본 요청을 전송

 

 

 

본 요청에 대한 응답

-> GET 메소드를 이용하여 본 요청을 보냈음을 알 수 있음.

 

 

 

 

 

Simple Request

예비 요청을 보내지 않고 바로 서버에게 본 요청을 보냄.

본 요청에 대한 응답 헤더를 통하여 CORS 위반 여부를 확인함.

 

 

Simple Request

 

다음과 같은 조건을 만족할 때에만 사용 가능하다.

 

• GET, HEAD, POST method Request 이어야 한다.
• Accept, Accept-Language, Content-Language, Contene-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더는 사용 불가능하다.
• Content-Type을 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.

->  사실상 위의 조건들을 모두 만족시키는 것은 쉽지 않다.

 

 

 

Credentialed Request

인증된 요청을 사용하는 방식.

서로의 통신에 있어서 보안을 더 강화하고자 할 때 사용

credentials 옵션을 통하여 요청에 인증 정보를 담음

 

 

credentials

• same-origin : 같은 출처 내에서 인증 정보를 사용
• include : 모든 요청에 인증 정보를 사용함

 

 

이 옵션을 사용하면 CORS 위반 여부 판단 시 Origin 값만 확인하는 것이 아닌 다음과 같은 규칙이 추가된다.

• Access-Control-Allow-Origin 에는 * 값을 사용할 수 없고, 명시적인 URL 이어야 한다.
• 응답 헤더에는 Access-Control-Allow-Credentials : true 가 반드시 존재해야한다.

 

credentials 옵션 규칙 예시

 

- 서버의 Access-Control-Allow-Origin 값이 * 로 설정되어 있기 때문에 CORS 정책을 위반하였다는 에러가 출력된다.

 

 

 

 

CORS 에러가 발생하였을 때의 해결 방식

 

1. Spring에서의 해결 방식

 

1) WebMvcConfigurer에서 정책 설정

 

@Configuration
public class ApiConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/v1/**").allowedOrigins("*");
    }
    ...

allowedOrigins, allowedMethods 등의 메소드를 통하여 설정 가능

 

 

 

 

2) @CrossOrigin annotation을 통하여 설정

 

@CrossOrigin(originPatterns = "*")
@RestController
@RequestMapping("/api/v1")
public class RestProductController {
						...

originPatterns 값을 이용하여 origin에 대한 설정이 가능하다.

 

 

 

2. (개발 과정에서) 브라우저에서 Proxy를 사용하여 요청을 대리하게 함으로써 CORS 위반을 우회하는 방식

 - CORS 정책을 사용하는 것이 브라우저이므로 가능

 

 

 

---

https://www.grabbing.me/URL-018cdd1bb4b541fab6246569244fcf93

URL 구조 이해하기

https://steady-coding.tistory.com/616

 

[Spring] Spring에서 CORS 이슈를 해결하는 방법