CORS 에러 개념과 해결법 (Spring MVC, Spring Security)

열심히 만든 프로젝트를 EC2에 띄워 서버를 활성화 시키고 프론트 엔드의 로컬에서 테스트를 해보려 했는데, 
띠용?! 페이지에 데이터는 보이지 않고, 개발자 도구를 켜면 빨간 에러들만 가득했습니다.

 

 

NBA에 첫 발길을 내딛는 신인 선수를 환영해주며 눈을 감고 자유투를 성공시키며 "Welcome to NBA"를 외치는 마이클 조던 마냥, CORS 에러는 웹개발을 하는 개발자들에게 웹개발 세계를 환영해주며 겪게되는 통과의례 같은 녀석입니다.

프로젝트때도 CORS에러로 엄청 고생을 하여 까먹지 않게 공부와 기록을 하려합니다.

 

 

🤔 CORS 란?

CORS 란  Cross-Origin Resource Sharing 이라는 뜻입니다. 이 문장을 직역하면 "교차 출처 리소스 공유 정책"이라고 해석할 수 있는데, 여기서 교차 출처라고 하는 것은 다른 출처를 의미하는 것으로 보면 됩니다.

 

하나식 뜯어서 해부해 보죠!

Origin(출처)?

먼저 출처(Origin)에 대해서 알아보겠습니다!

우리가 어떤 사이트를 접속할때 인터넷 주소창에 우리는 URL이라는 문자열을 통해 접근하게 됩니다.
이처럼 URL은 https://domain.com:3000/user?query=name&page=1과 같이 하나의 문자열 같지만, 사실은 다음과 같이 여러개의 구성 요소로 이루어져 있습니다.

 

이미지 출처 : https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

 

• Protocol : 프로토콜( http, https 등등)
• Host : 사이트 도메인
• Port : 포트 번호(생략가능)
• Path : 사이트 내부 경로
• Query string :  요청의 key 값과 value 값 ( = 으로 구분)
• Fragment : 해시 태그

 

이때 출처 즉, Origin 라는 것은 Protolcol 과 Host 그리고 Port 까지 모두 합친, 리소스가 존재하는 곳을 의미한다고 보면 됩니다.

 

Cross-Origin(교차 출처)란 

다른 출처를 의미합니다. 프로토콜, 호스트, 포트 번호가 같으면 동일 출처 (Same-Origin), 하나라도 다르다면 교차 출처 (Cross- Origin)이라고 생각하면 됩니다.

 

• 프로토콜 (scheme)
• 호스트 (domain)
• 포트 번호 (port)

 

URL	동일 출처 ?	이유
https://www.domain.com:3000/about	O	프로토콜, 호스트, 포트 번호 동일
https://www.domain.com:3000/about?username=inpa	O	프로토콜, 호스트, 포트 번호 동일
http://www.domain.com:3000	X	프로토콜 다름 (http ≠ https)
https://www.another.co.kr:3000	X	호스트 다름
https://www.domain.com:8888	X	포트 번호 다름
https://www.domain.com	X	포트 번호 다름 (443 ≠ 3000)

 

 

동일 출처 정책 vs 교차 출처 정책

출처(Origin)에 대한 각기 다른 정책인 Same Origin 정책과 Cross Origin 정책에 대해 알아보죠!
먼저 SOP(Same Origin Policy) 정책은 단어 그대로 동일한 출처에 대한 정책을 말합니다. 그리고 이 SOP 정책은 '동일한 출처에서만 리소스를 공유할 수 있다.'라는 법률을 가지고 있습니다. 
즉, 동일 출처(Same-Origin) 서버에 있는 리소스는 자유로이 가져올수 있지만, 다른 출처(Cross-Origin) 서버에 있는 리소스는 상호작용이 불가능하다는 말이죠.

SOP 정책이 있는 이유는 바로 보안을 위해서입니다.  출처가 다른 두 어플리케이션이 자유로이 소통할 수 있는 환경은 꽤 위험한 환경입니다. 만일 제약이 없다면, 해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있습니다.

이러한 악의적인 경우를 방지하기 위해, SOP 정책으로 동일하지 않는 다른 출처의 스크립트가 실행되지 않도록 브라우저에서 사전에 방지하는 것입니다.

 

COP(Cross Origin Policy)

교차 출처 정책 을 지원하는 것 중엔 <img>, <video>, <script>, <link> 태그 등이 있습니다.

<link> 태그의 href 에서 다른 사이트의 .css 리소스에 접근하는 것이 가능
<img> 태그의 src 에서 다른 사이트의 .png, .jpg 등의 리소스에 접근하는 것이 가능
<script> 태그의 src 에서 다른 사이트의 .js 리소스에 접근하는 것이 가능 (type="module" 속성은 제외)

 

위 태그들은 혼합 콘텐츠(Mixed Content -  웹 페이지가 보안 연결(HTTPS)을 통해 전송될 때, 페이지 내의 일부 콘텐츠[예: 이미지, 비디오, 스크립트, 스타일시트 등]가 비보안 연결(HTTP)을 통해 로드되는 경우 )도 허용하기 때문에 Mixed Content 에러 또한 발생하지 않습니다.

 

SOP(Same Origin Policy)

XMLHttpRequest, Fetch API 스크립트

기본적으로 Same-Origin 정책을 따릅니다.

자바스크립트에서의 요청은 기본적으로 서로 다른 도메인에 대한 요청을 보안상 제한합니다. 브라우저는 기본으로 하나의 서버 연결만 허용되도록 설정되어 있기 때문입니다. (주로 자신의 서버)

혼합 컨텐츠 또한 허용하지 않기 때문에 HTTPS 요청 환경에선 API 요청 또한 HTTPS 프로토콜로 요청해야 합니다.

 

 

🔶 CORS 교차 출처 리소스 공유 (Cross-Origin Resource Sharing)

이처럼 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 단어 그대로 다른 출처의 리소스 공유에 대한 허용/비허용 정책입니다.
아무리 보안이 중요하지만, 개발을 하다 보면 기능상 어쩔 수 없이 다른 출처 간의 상호작용을 해야 하는 케이스도 있으며, 또한 실무적으로 다른 회사의 서버 API를 이용해야 하는 상황도 존재합니다. 따라서 이와 같은 예외 사항을 두기 위해 CORS 정책을 허용하는 리소스에 한해 다른 출처라도 받아들인다는 것 입니다.

 

CORS의 동작 방식

CORS는 HTTP 헤더를 사용하여 브라우저와 서버 간의 리소스 공유 권한을 설정합니다. CORS 요청은 크게 단순 요청(Simple Request) 과 예비 요청(Preflight Request)으로 나뉩니다.

 

단순요청(Simple Request)

단순 요청은 말그대로 예비 요청(Prefilght)을 생략하고 바로 브라우저는 서버에 특별한 사전 요청 없이 리소스를 요청합니다. 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin 헤더를 보내주면 브라우저가 CORS정책 위반 여부를 검사하는 방식입니다.

 

단순요청은 다음 조건을 모두 만족해야하는 요청입니다.

1. HTTP 메서드가 GET, POST, HEAD 중 하나일 것.

2. HTTP 헤더가 다음 중 하나만 포함될 것: Accept, Accept-Language, Content-Language, Content-Type (단, Content-Type이 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나일 경우)

 

매우 단순한 조건들만 가능하기 때문에 위 조건을 모두 만족되어 단순 요청이 일어나는 상황은 매우 드뭅니다. 왜냐하면 대부분 HTTP API 요청은 text/xml 이나 application/json 으로 통신하기 때문에 Content-Type 조건이 위반되기 때문입니다. 그래서 대부분의 API 요청은 그냥 예비요청으로 이루어집니다.

 

단순 요청

 

예비 요청(Preflight Request)

브라우저는 요청을 보낼때 한번에 바로 보내지않습니다. 먼저 예비 요청을 보내 서버와 잘 통신되는지 확인한 후 본 요청을 보냅니다. 이때 출처를 비교하게 됩니다.
즉, 예비 요청의 역할은 본 요청을 보내기 전에 브라우저 스스로 안전한 요청인지 미리 확인하는 것입니다.

이때 브라우저가 예비요청을 보내는 것을 Preflight라고 부르며, 이 예비요청의 HTTP 메소드를 GET이나 POST가 아닌 OPTIONS라는 요청이 사용된다는 것이 특징입니다.

 

예비 요청은 다음 조건 중 하나라도 만족하는 경우에 발생합니다

1. HTTP 메서드가 PUT, DELETE 등 단순 요청에 해당하지 않는 경우

2. 커스텀 헤더가 포함된 경우

3. Content-Type이 application/json 등 단순 요청에 해당하지 않는 경우

즉, 단순 요청 조건이 위반되는 경우 모두 예비요청으로 보낸다고 생각하면 됩니다.

예비 요청

 

특히 수행하는 API 호출 수가 많으면 많을 수록 예비 요청으로 인해 서버 요청을 배로 보내게 되니 비용적인 측면에서 낭비가 될 수 있습니다. 따라서 브라우저 캐시(Cache)를 이용해 Access-Control-Max-Age 헤더에 캐시될 시간을 명시해 주면, 이 Preflight 요청을 캐싱 시켜 최적화를 시켜줄 수 있습니다.

 

+) 인증된 요청 (Credentialed Request)

인증된 요청은 클라이언트에서 서버에게 자격 인증 정보(Credential)를 실어 요청할때 사용되는 요청입니다.

여기서 말하는 자격 인증 정보란 세션 ID가 저장되어있는 쿠키(Cookie) 혹은 Authorization 헤더에 설정하는 토큰 값 등을 일컫습니다.

즉, 클라이언트에서 일반적인 JSON 데이터 외에도 쿠키 같은 인증 정보를 포함해서 다른 출처의 서버로 전달할때 CORS의  인증된 요청으로 동작된다는 말이며, 이는 기존의 예비 요청과는 살짝 비슷하지만, 차이점이 존재합니다.

 

클라이언트 측

기본적으로 브라우저가 제공하는 요청 API 들은 별도의 옵션 없이 브라우저의 쿠키와 같은 인증과 관련된 데이터를 함부로 요청 데이터에 담지 않도록 되어있습니다.

이때 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 바로 credentials 옵션입니다.

프론트엔드의 자바스크립트에서 credentials: "include" , withCredentials: true 설정을 하면 클라이언트와 서버가 통신할때 쿠키와 같은 인증 정보 값을 공유하겠다는 설정이 됩니다.

JWT를 이용하여 쿠키로 자격 인증을 하는 경우 액세스 토큰을 요청 헤더의 Authorization 필드에 설정합니다.

Authorization 헤더를 포함하기 때문에, 단순 요청(simple request)이 아니며 프리플라이트 요청이 발생합니다.

 

서버측

서버측도 마찬가지로 이러한 인증된 요청에 대해 일반적인 CORS 요청과는 다르게 대응해줘야 합니다.
브라우저는 Access-Control-Allow-Credentials: true 가 없는 응답을 거부합니다.
Access-Control-Allow-Origin 응답 헤더의 와일드 카드 (*)를 허용하지 않습니다.

따라서 서버에서 꼭 설정을 해주어야 합니다.

이제부턴 제가 서버 설정을 통해 CORS 문제를 해결한 방법을 알려드리겠습니다.

 

🪄 해결 방법

CORS를 대할 때 특히나 주의 할 점은 출처를 비교하는 로직은 서버에서 구현된 로직이 아닌 브라우저에서 구현된 로직이라는 점입니다. 즉 서버에서 올바른 응답값을 주지만 브라우저가 출처를 비교해서 교차 출처면 block을 시켜  CORS 에러를 발생시키는 것입니다.

이걸 해결하기 위해선 서버단에선 교차 출처를 허용하는 헤더를 추가해주어야 합니다.

 

✨ 방법 1

서버에서 웹 컨피그를 설정해서 CORS 설정을 해줄 수 있습니다. 스프링 서버 전역적으로 CORS 설정 해줄 수 있습니다. WebMvcConfigurer 를 확장하여 addCorsMappings 메소드를 재정의해서 사용하게 됩니다. CorsRegistry 를 통해 설정해줄 수 있습니다.

 

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    private static final String[] ALLOW_ORIGINS = {
        "http://localhost:5173",
        "https://yanabada-******.vercel.app",
        "https://www.*******.com"
    };

    private static final String[] ALLOW_METHODS = {
        "GET", "POST", "PATCH", "DELETE", "HEAD", "OPTIONS", "PUT"
    };

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
            .allowedOrigins(ALLOW_ORIGINS) // 허용할 출처
            .allowedMethods(ALLOW_METHODS) // 허용할 HTTP method
            .allowCredentials(true) // 쿠키 인증 요청 허용을 위해선 true로 설정해줘야합니다.
            .maxAge(3000); // 원하는 시간만큼 pre-flight 리퀘스트를 캐싱할 수 있습니다.
    }
}

 

✨ 방법2

특정 컨트롤러, 특정 메소에만 CORS 적용하고 싶을 땐 @CrossOrigin 어노테이션을 사용할 수 있습니다.

@Controller
@CrossOrigin(origins = "http://localhost:5173", methods = RequestMethod.GET) // 특정 컨트롤러에만 CORS 적용하고 싶을때.
public class customController {

	// 특정 메소드에만 CORS 적용 가능
    @GetMapping("/url")  
    @CrossOrigin(origins = "http://localhost:5173", methods = RequestMethod.GET) 
    @ResponseBody
    public List<Object> findAll(){
        return service.getAll();
    }
}

 

 

✨방법 3이자, 트러블 슈팅한 점

 

웹 컨피그를 설정하고 나선 프론트엔드와 API 통신이 잘 이루어 졌지만, 스프링 시큐리티를 설정했을 땐 다시 CORS 에러가 생겼습니다. 수많은 트러블 슈팅을 하고 나서 얻은 결과 스프링 시큐리터의 필터체인에서 CORS 설정을 안했기 때문입니다. 

그럼, 왜 웹 컨피그 설정을 했는데도 CORS 문제가 생겼는지 되물을 수 있습니다.

 

스프링 시큐리터의 CORS 설정은 필터 체인 내에서 CORS 필터를 통해 이루어집니다. Spring Web MVC CORS 설정은 CorsRegistry 사용하여 설정하며, 이는 인터셉터와 유사한 방식으로 작동합니다. 주로 컨트롤러에 대한 요청에 대해 CORS 헤더를 추가합니다.

필터는 서블릿 기반으로 스프링 컨테이너에 요청이 닿기 전에 서블릿 에서 요청의 전처리와 후처리를 해줄 수 있고, CorsRegistry 은 인터셉터와 비슷하게 동작하므로 컨트롤러 앞단에서 전처리 후처리를 합니다.

자세한 건 제, 필터와 인터셉터 차이 블로그 글을 봐주세요!

https://programmer-may.tistory.com/198

필터와 인터셉터의 차이

 

CORS 설정은 앞서 말했다싶이 서버에서 특정 헤더들을 추가하는 것입니다. Spring Web MVC와 Spring Security에서의 CORS 설정은 주로 응답 헤더를 설정하는 것으로, 이는 요청의 후처리 과정에 해당합니다.

Spring Web MVC에서 CORS 설정을 했더라도 Spring Security 설정에서 CORS를 명시적으로 설정하지 않으면, Spring Security의 필터 체인에서 CORS 요청이 걸러질 수 있습니다. 이는 Spring Security가 모든 HTTP 요청을 가로채고 처리하기 때문입니다.

 

SecurityConfig 설정 (스프링부트 3버전, 스프링 시큐리티 6버전을 사용하였습니다.)

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtAuthFilter jwtAuthFilter;
    private final JwtExceptionFilter jwtExceptionFilter;
    private final Oauth2UserService oauth2UserService;
    private final Oauth2LoginSuccessHandler oauth2LoginSuccessHandler;
    private final Oauth2LoginFailureHandler oauth2LoginFailureHandler;
    private final JwtAuthenticationEntryPoint jwtAuthenticationEntryPoint;

    private static final String[] PERMIT_PATHS = {
        "/auth", "/auth/**", "/login/**",
        "/oauth2/**", "/signin/**", "/error/**",
        "/ws-stomp", "/ws-stomp/**"
    };

    private static final String[] PERMIT_PATHS_POST_METHOD = {
        "/v1/accommodations/**", "/v1/orders",
        "/v1/accommodations"
    };

    private static final String[] PERMIT_PATHS_GET_METHOD = {
        "/v1/products", "/v1/products/**",
        "/ws-stomp", "/ws-stomp/**",
        "/v1/payments/admin"
    };
    
    private static final String[] ALLOW_ORIGINS = {
        "http://localhost:5173",
        "https://yanabada-********.vercel.app",
        "https://www.*******.com"
    };

    private static final String[] ALLOW_METHODS = {
        "GET", "POST", "PATCH", "DELETE", "HEAD", "OPTIONS", "PUT"
    };
    
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        http.httpBasic(AbstractHttpConfigurer::disable);
        http.cors(cors -> cors.configurationSource(corsConfigurationSource())); // CORS 필터 설정
        http.csrf(AbstractHttpConfigurer::disable);

        http.authorizeHttpRequests(authorize -> authorize
            .requestMatchers(PERMIT_PATHS).permitAll()
            .requestMatchers(POST, PERMIT_PATHS_POST_METHOD).permitAll()
            .requestMatchers(GET, PERMIT_PATHS_GET_METHOD).permitAll()
            .requestMatchers("/v1/products/own").denyAll()
            .anyRequest().authenticated()
        );

        http.exceptionHandling(exceptionHandling -> {
            exceptionHandling.authenticationEntryPoint(jwtAuthenticationEntryPoint);
        });

        http.oauth2Login(oauth2 -> oauth2
            .userInfoEndpoint(
                userInfoEndpoint -> userInfoEndpoint.userService(oauth2UserService))
            .successHandler(oauth2LoginSuccessHandler)
            .failureHandler(oauth2LoginFailureHandler)
        );

        http.addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class)
            .addFilterBefore(jwtExceptionFilter, JwtAuthFilter.class);

        return http.build();
    }

    @Bean
    CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration configuration = new CorsConfiguration();
        configuration.setAllowedOrigins(List.of(ALLOW_ORIGINS));
        configuration.setAllowedMethods(List.of(ALLOW_METHODS));
        configuration.setAllowedHeaders(List.of("*"));
        configuration.addExposedHeader("Authorization");
        configuration.setAllowCredentials(true); //쿠키를 이용한 인증 요청을 허용
        configuration.setMaxAge(3600L);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration);
        return source;
    }
}

 

 

🧑‍💻 마무리 하며

CORS 를 만나면서 나도 드디어 웹 개발자구나 느껴볼 수 있었습니다. 브라우저에서 CORS에 대한 동작 방식이 어떻게 행해지는지, 이걸 해결하기 위해서 어떤 헤더를 설정해줘야하는지 배웠습니다. 대부분의 API 요청시 CORS 동작 방식은 예비요청(Preflight) 걸 학습할 수 있었고, 어떻게 예비요청이 오는지 배울 수 있었습니다. 또한 프로젝트에서 JWT도 사용하여, 인증 요청 방식도 배울 수 있었습니다.

결국 CORS 에러는 서버에서 헤더 설정을 해주지 않아 일어나는 것이었습니다. 

서버에서 헤더 설정을 하는 케이스는 여러가지가 있었습니다. 전역적으로 처리하는 WebMvcConfigurer 를 구현한 웹 컨피그 방법, 특정 메소드, 컨트롤러에만 설정할 수 있는 @CrossOrigin  어노테이션 마지막으로, 스프링 시큐리티를 도입했을 시 CORS 필터에서 CORS 설정하는 방법 등을 학습할 수 있었습니다.

그중 웹 컨피그 설정을 해두었는데, 왜 시큐리티를 활성화 시키면 다시 CORS 에러가 발생하는 이유에 대해 트러블 슈팅하며 배운 것이 기억에 남습니다. 웹 컨피그 설정도 해줬는데 CORS가 터졌을 땐 프론트엔트 측에서 잘못한 것인줄 알고 있었지만, 그렇지 않다는 걸 깨닫고는 매우 당황했던 기억이 납니다.

CORS는 제가 설명한 것보다 더 깊고, 또 여러 애로사항을 만든다고 봤습니다. 나중을 위해서라도 조금 더 깊게 공부해보고 싶습니다.