1. CORS

Cross-Origin Resource Sharing
교차 출처 리소스 공유 (뭔말이야)
교차 출처의 개념 > 다른 출처
-> 다른 출처와 리소스를 공유하는 것

출처란?

Protocol + Host + Port번호

출처 내의 Port 번호는 생략이 가능하다. 80, 443과 같이 http는 기본 port가 정의되어 있기 때문이다.
만약 Port 번호까지 명시되어 있는 경우는, 실제 Port 번호와 동일해야 같은 출처로 인정된다.

SOP란?

Same-Origin Policy
같은 출처에서만 리소스를 공유할 수 있다라는 규칙을 가진 정책
그러나 CORS 정책을 지킨 리소스 요청인 경우는 예외로 허용한다.

다른 출처로 리소스를 요청하는 경우
-> SOP 정책을 위반한 것
SOP의 예외 조항인 CORS 정책까지 지키지 않는 경우
-> 아예 다른 출처의 리소스를 사용할 수 없게 된다.

이런 제약을 왜 만들었지?

다른 출처의 어플리케이션이 서로 통신하는 것에 대해 아무런 제약도 존재하지 않는다면
웹에서 돌아가는 클라이언트 어플리케이션은 사용자의 공격에 너무나도 취약하기 때문에,
해당 어플리케이션의 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting)와 같은 방법을 사용하여 어플리케이션에서 코드가 실행된 것처럼 꾸며서 공격자가 사용자의 정보를 탈취할 수 있다.

출처를 구분하는 로직은 브라우저에 구현되어 있다.

만약 CORS 정책을 위반하는 리소스 요청을 하더라도 해당 서버는 같은 출처에서 보낸 요청만 받겠다는 로직을 가지고 있는 경우가 아니라면 정상적으로 응답을 하고, 이후 브라우저가 이 응답을 분석해서 CORS 정책 위반이라고 판단되면 그 응답을 사용하지 않고 버린다.

CORS 정책 위반 해결 방법

Access-Control-Allow-Origin 세팅

서버에서 Access-Control-Allow-Origin 헤더에 알맞은 값을 세팅해주는 방법.
모든 요청을 다 받겠다는 의미의 *을 세팅하면 편할 수 는 있지만 보안적인 이슈가 생길 수도 있으므로 아래와 같이 명확한 출처를 표기해주는 것이 좋다.
Access-Control-Allow-Origin: https://velog.io/@doobyeol

참고

2. CSRF

cross-site Request forgey

요청을 위조하여 사용자의 권한을 이용해 서버에 대한 악성공격을 하는 것

사용자는 로그인 후 어플리케이션에서 인증 토큰을 받는다.
만약 사용자가 공격자의 사이트를 방문하면, 공격자는 사용자의 토큰을 이용하여 서버에 요청을 보낼 수 있고, 사용자가 원치 않은 작업들을 수행하게 되버린다. 악성 게시글 작성등..

Spring Security에서는 이러한 CSRF에 의한 공격을 방지하기 위해서 Form형식의 전송들에대해서는 _csrf 라는 hidden 타입으로 값을 설정하고 이값과 서버에서 받는 값이 일치해야 요청 전송을 허가한다.
하지만 Server가 REST API 용도로만 사용된다면 다음과 같은 설정으로 사용하지 않을 수도 있다.

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends
   WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http
      .csrf().disable();
  }
}

참고