[Indp] CORS 에러 해결하기

🚀 개요

Indp 프로젝트에서 서버와 클라이언트를 연동하면서 CORS 에러가 발생하였다. 클라이언트는 AWS CloudFront, 서버는 AWS EC2 로 배포해 놓은 상태였다. CORS 에러란 왜 발생하고 어떻게 해결하는지 학습해보고 적용해보자.

📖 CORS

Cross-Origin Resource Sharing 를 의미하며 요청 브라우저에서 다른 출처를 갖는 서버로 요청이 갈 때 브라우저에서 발생하는 보안 정책이다. 여기서 포인트는 다른 출처, 브라우저에서 발생, 보안 정책이다. 각각이 의미하는 것이 무엇인지 알아보자.

다른 출처

URL 에서 출처란 프로토콜, 호스트, 포트 번호를 의미하고 이 중 동일하지 않은 것이 있다면 출처가 다른 것이다. 다른 출처의 예시는 다음과 같다.

• 프로토콜 http ≠ https
• 호스트 www.aaa.com ≠ www.api.aaa.com
• 포트 번호 www.aaa.com:8080 ≠ www.aaa.com:3000

브라우저에서 발생

CORS 에러는 브라우저에 의해 발생하는 에러이다. 따라서 서버 to 서버 통신에서는 CORS 에러가 발생하지 않는다.

보안 정책

웹 생태계는 SOP(Same-Origin Policy) 라는 정책이 존재한다. 이름에서도 알 수 있듯이 SOP 는 같은 출처의 리소스만 공유하도록 제한하는 정책이다. 그렇다면 다른 출처의 리소스를 제한하는 이유는 무엇일까?

브라우저에는 토큰과 같은 인증 정보들이 저장될 수 있다. 이 인증 정보들은 해당 사이트로 요청을 보낼 때마다 함께 보내진다. 여기서 문제는 신분증과 같은 중요한 인증 정보가 브라우저에 저장된다는 것이다. 만약 사용자가 로그인을 하여 토큰이 브라우저에 저장된 상태에서 피싱 메일이나 악성 사이트를 통해 사용자의 브라우저에서 악의적인 코드가 실행되게 한다고 가정해보자. SOP 정책이 없다면 서로 다른 출처 끼리 데이터를 주고받을 수 있게 되고 브라우저에 저장된 토큰으로 해당 사이트에서 사용자의 정보를 조회 할 수 있게 될 것이다. 이와 같은 위험을 방지하는 것이 SOP 정책이다.

📖 CORS 요청의 종류

Simple Request

• GET, POST, HEAD 메소드 중 하나를 사용하는 요청
• Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width 헤더일 경우
• Content-Type 헤더가 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나일 경우

1. 클라이언트가 다른 출처로 요청을 보낼 때 브라우저가 요청 메시지에 Origin 헤더 (현재 사이트의 프로토콜 + 호스트 + 포트)를 추가
2. 서버는 Access-Control-Allow-Origin 헤더에 허용하는 Origin 을 명시
3. 응답을 받은 브라우저는
   1. Access-Control-Allow-Origin 값이 요청을 보낸 Origin 과 다르면 응답을 사용하지 않고 버리고 CORS 에러 발생
   2. Access-Control-Allow-Origin 값이 요청을 보낸 Origin 과 같다면 응답 데이터를 클라이언트로 전달

Preflight Request

• Simple Request 조건을 만족하지 않는 요청

1. 브라우저는 내부적으로 진짜 요청을 보내기 전에 OPTIONS 라는 메소드로 preflight 요청을 보내서 CORS 와 관련하여 서버에게 해당 요청을 보내도 되는지 물어봄

OPTIONS /resource
Access-Control-Request-Method: 요청에서 사용될 메서드
Origin: 요청을 보낸 출처

2. 서버는 허용되는 Origin, Method 등을 응답

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: 허용되는 출처
Access-Control-Allow-Methods: 허용되는 메서드
Access-Control-Max-Age: preflight 요청을 캐싱할 시간(초)

3. 응답을 받은 브라우저는 응답 헤더 값이 요청을 보낸 Origin 과 다르면 진짜 요청을 보내지 않고 CORS 오류 발생

Credential Request

• 클라이언트에서 서버에게 자격 인증 정보를 실어 요청할 경우
• 자격 인증 정보 쿠키, Authorization 헤더 등
• 클라이언트에서 withCredentials 옵션을 true 로 설정해야 인증 관련 헤더를 요청에 실어 보낼 수 있음
• 서버에서 Access-Control-Allow-Credentials 헤더를 true 로 설정해야 응답 데이터를 클라이언트로 전달할 수 있음

📖 CORS 해결 방법

CORS 해결책은 서버의 응답 헤더인 Access-Control-Allow-Origin 에 달렸다. 서버에서 클라이언트의 요청을 허용할지 말지 결정하는 것이다.

1. 클라이언트에서 서버로 요청을 보내는 대신 클라이언트에서 프록시 서버로 요청을 보내고 프록시 서버에서 서버로 요청을 보내는 방법
2. 서버에서 CORS 관련 응답 헤더를 설정

🌞 적용 해보기

CORS 에러란 무엇이고 왜 발생하며 어떻게 해결하는 지를 알아봤다. 이제 프로젝트에서 발생한 CORS 에러를 해결해보자.

🚨 CORS 에러 발생

클라이언트 Origin 인 https://verby.co.kr 과 서버의 Origin인 https://api.verby.co.kr 이 달라 다음과 같이 CORS 에러가 발생하였다.  브라우저는 응답 헤더인 Access-Control-Allow-Credentials 를 보고 현재의 Origin 이 허용된 Origin 인지 확인해야하는데 해당 헤더가 존재하지 않아 CORS 에러가 발생하였다.

✅ Nginx 를 통한 응답 헤더 설정

서버의 응답 헤더인 Access-Control-Allow-Origin 을 'https://verby.co.kr' 로 설정하여 브라우저에게 https://verby.co.kr 가 혀용된 Origin 임을 알려주자.

location / {
if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://verby.co.kr';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, DELETE, PUT, PATCH, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Content-Type';
        add_header 'Access-Control-Max-Age' 86400;

        return 204;
    }

    add_header 'Access-Control-Allow-Origin' 'https://verby.co.kr' always;

    proxy_pass http://localhost:8080/;
}

1. Preflight Request 의 응답 헤더 설정 (Method: OPTIONS)
2. Simple Request 의 응답 헤더 설정 (always 설정을 하여 실패한 요청의 경우에도 cors 설정)

Nginx 를 재시작하여 다시 요청을 보내면 더이상 CORS 에러가 발생하지 않는다.

1. 브라우저가 요청 헤더에 현재 요청을 보내는 Origin 인 'https://verby.co.kr' 을 추가
2. 클라이언트가 서버에 요청
3. 서버는 응답 헤더인 Access-Control-Allow-Origin 을 'https://verby.co.kr' 로 설정하여 허용되는 Origin 명시
4. 응답을 받은 브라우저는 Access-Control-Allow-Origin 값을 통해 현재 Origin 과 동일한지 확인
5. 허용된 Origin 임을 확인하고 응답 데이터를 클라이언트로 전달
6. 통신 성공!

2개 이상의 Origin 설정하기

서버가 허용하는 Origin 은 https://verby.co.kr과 https://www.verby.co.kr이다. 맨 처음에는 단순하게 여러개의 헤더를 설정해주었다.

add_header 'Access-Control-Allow-Origin' 'https://verby.co.kr';
add_header 'Access-Control-Allow-Origin' 'https://www.verby.co.kr';

하지만, 요청을 보낼 경우 CORS 에러가 발생한다. 

Access-Control-Allow-Origin 헤더는 두 개(multiple) 이상이면 안된다. 이것도 CORS 관련 정책인가보다. 물론 다음과 같이 설정해도 되지 않는다.

add_header 'Access-Control-Allow-Origin' 'https://verby.co.kr, https://www.verby.co.kr';

찾아보니 Nginx 에는 변수에 동적으로 값을 대입할 수 있는 map 모듈이라는게 있었다. 이를 사용하여 동적으로 허용 Origin 을 설정할 수 있었다.

# nginx.conf
http {
	...
	map $http_origin $allowed_origin {
        default "https://verby.co.kr";
        https://www.verby.co.kr $http_origin;
    }
}

# sites-available/verby.co.kr
location / {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' $allowed_origin;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, DELETE, PUT, PATCH, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
        add_header 'Access-Control-Max-Age' 86400;

        return 204;
    }

    add_header 'Access-Control-Allow-Origin' $allowed_origin always;

    proxy_pass http://localhost:8080/;
}