글 쓰는 시간

CORS란?

CORS(Cross-Origin Resource Sharing)는 웹 브라우저 보안 정책 중 하나로,

같은 출처(Origin)가 아닌 리소스에 대한 웹 페이지의 접근을 제한하는 정책을 완화하기 위한 메커니즘이다.

웹 애플리케이션에서 다른 도메인의 리소스를 요청할 때 발생하는 보안 이슈를 관리하기 위해 사용된다.

출처(Origin)

URL 은 아래의 그림과 같은 요소로 구성 되어있다.

위의 구성요소 중에서 Protocol + Host + Port 3가지가 같으면 동일 출처(Origin)라고 한다.

// 동일 출처 예시
http://example.com:80       
http://example.com                 // http의 기본 port인 80이 생략되어있으므로 동일 출처

http://example.com/path1
http://example.com/path2       // protocol, host, port(생략)이 같으며, path부터 다르므로 동일 출처
-------------------------------------------------------------------------------------------------
//다른 출처 예시
http://example.com/path1
https://example.com/path2      // protocol 이 다르므로 다른 출처

http://www.naver.com
http://twogaether.site               // host 가 다르므로 다른 출처

http://example.com
http://example.com:8080         // port 가 다르므로 다른 출처

CORS 가 나온 이유

인터넷 기술이 여전히 생소했던 과거에는 크로스 사이트 요청 위조(CSRF) 문제가 발생했다.

CSRF 공격이란 인증된 사용자가 악의적인 웹사이트에서 의도하지 않은 요청을 송신하는 공격이다

아래는 은행 접속을 예시로 들어 CSRF 공격이 어떻게 작동하는지 간단히 설명한다.

1. 사용자가 은행 계좌에 로그인한 상태에서 다른 탭에서 웹 사이트를 이용한다.
2. 그러다가 악의적인 웹사이트에 방문한다.
3. 이 웹사이트는 자동으로 특정 요청을 은행 웹사이트로 보내는 HTML 코드를 포함하고 있다.
   이 코드는 사용자가 은행 계좌에서 돈을 이체하는 등의 요청을 포함할 수 있다.
4. 악의적인 웹사이트가 사용자의 브라우저에서 은행 웹사이트에 대한 요청을 보내기 때문에 브라우저는 사용자의 세션 쿠키를 함께 전송한다.
5. 은행 웹사이트는 이 요청을 받았을 때, 브라우저의 세션 정보를 신뢰하고 사용자의 계좌에서 돈을 이체하는 요청으로 처리한다.

이 CSRF 문제를 방지하기 위해 이제 모든 브라우저에서 동일 출처 정책(Same-Origin-Policy)을 구현한다.

동일 출처 정책(Same-Origin Policy)

보통 스크립트로 로드되는 리소스에 대해 동일 출처 정책(Same-Origin Policy)를 적용한다.

동일 출처 정책은 보안상의 이유로 스크립트가 한 출처에서 로드한 문서나 스크립트에서 다른 출처의 리소스를 요청하는 것을 제한한다.

그러나 CORS는 이러한 제한을 우회하여 다른 출처의 리소스에 접근할 수 있도록 해준다.

Simple Request 와 Preflight

사실 나도 그랬고 다른 사람들도 그럴거라 생각하지만 이 개념에 대해 별 생각 없이 넘어가기 쉽다.

하지만 CORS 에 관해 제대로 이해하려면 백엔드, 프론트엔드 모두 이 과정을 이해해야 한다고 생각한다.

단순 요청 (Simple Request)

클라이언트 요청이 단순 요청의 조건에 해당하는 경우 예비 요청(Preflight) 없이 본 요청만으로 CORS 위반 여부를 검사한다.

단순 요청은 예비 요청없이 바로 서버에게 본 요청부터 보낸 후, 서버가 이에 대한 응답의 헤더에 

Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다. 

단순 요청은 아래 조건들을 모두 만족해야 한다.

1. 요청의 메소드는 GET, HEAD, POST 중 하나여야 한다.
2. Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
3. 만약 Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.

이 중 2, 3번 조건이 까다롭기 때문에 현실적으로 조건을 만족시키기 어렵다.

사용자 인증에 사용되는 Authorization 헤더도 사용하면 안되고, 무엇보다도 최근 웹 개발에서 주로 사용하며

대부분의 HTTP API에서 사용되는 application/json 컨텐츠 타입도 가지면 안된다. 

즉, POST 요청으로 바디에 데이터를 담아서 요청하려해도  application/json 헤더를 쓸 수 없다.

예비 요청(Preflight)

단순 요청의 조건을 만족하기 매우 까다롭기 때문에 일반적으로 웹 개발 시 가장 자주 마주치게 되는 시나리오이다. 

이 시나리오에서 브라우저는 요청을 예비 요청과 본 요청으로 나누어 서버에 전송한다. 

이때 브라우저가 본 요청을 보내기 전에 보내는 예비 요청을 Preflight라고 부른다. 

본 요청을 보내기 전에 브라우저 스스로 이 요청을 보내는 것이 안전한지 확인하는 과정으로, 

HTTP 메소드 중 OPTIONS 메소드가 사용된다. 

이 시나리오의 과정은 아래와 같다.

1. 프론트엔드에서 자바스크립트의 fetch API를 이용해 브라우저에게 리소스를 받아오라는 명령을 내리면
2. 브라우저는 서버에게 예비 요청을 먼저 보내고, 서버는 이 요청에 대한 응답으로
   현재 자신이 어떤 것들을 허용하고 금지하는지에 대한 정보를 응답 헤더에 담아 브라우저에게 다시 보내준다.
3. 이후 브라우저는 자신이 보낸 예비 요청과 서버가 응답에 담아준 허용 정책을 비교한 후
   요청을 보내도 안전하다고 판단되면 같은 엔드포인트로 다시 본 요청을 보낸다.
4. 이후 서버가 본 요청에 대한 응답을 하면 브라우저는 최종적으로 응답 데이터를 자바스크립트에게 넘겨준다.

CORS 동작 방식

1. 요청 (Request) 전송
   - 브라우저에서 한 출처의 웹 페이지가 다른 출처의 리소스에 HTTP 요청을 보낸다.
2. 프리플라이트 옵션 요청 (Preflight Request) 확인
   - 만약 요청이 특정 조건을 충족하는 경우 (Simple Request 가 아닌 경우),
   브라우저는 사전에 서버에게 요청 전에 '프리플라이트'라고 불리는 OPTIONS 메서드로 요청을 보낸다. 
   - 이때 서버는 허용된 메서드(예: GET, POST) 및 헤더 등에 대한 정보를 응답한다.
3. 실제 요청 (Actual Request)
   - 프리플라이트 요청이 성공하면, 실제로 리소스에 대한 실제 HTTP 요청(GET, POST 등)이 이루어진다.
4. 응답 (Response)
   - 서버는 요청을 받아들이고, 브라우저에게 응답을 보낸다.
   - 응답에는 어떤 출처에서 리소스에 접근할 수 있는지를 나타내는 'Access-Control-Allow-Origin' 헤더 등이 포함된다.

만약 서버에서 특정 출처의 요청을 허용한다고 헤더에 명시되어 있지 않다면, 브라우저는 해당 요청을 차단한다.

또한 응답을 200으로 받아도 바디에 아무 값도 안담겨 오는 경우에도 CORS 문제를 생각해 볼 수 있다.

JWT(Json Web Token) 란

JWT는 Json(key & value) 형식을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. 

JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 암호화하여 토큰에 담아 전달한다. 

Claim 기반

Claim 이란 사용자에 대한 정보나 속성을 말하며 name & value 형식으로 구성된다. 

JWT는 독립적이다

JWT는 독립적(Self-contained)이라고 표현하기도 한다.

Payload 안에 사용자에 대한 정보가 들어있으므로 데이터베이스 조회 작업이 줄어든다.

하지만 이러한 특성 때문에 Payload에 암호화되지 않은 데이터가 노출되는 JWS 방식의 경우

민감한 정보는 넣지 않는 것이 바람직하다.

JWT, JWS, JWE 구분

JWT

JWT는 인터페이스 역할을 해주는 추상적인 개념이고 실제 구현은 JWS와 JWE로 나누어진다.

JWS

디지털 서명을 하는 방식은 JWS(JSON Web Signature)

JWE

암호화 하는 방식은 JWE(JSON Web Encryption)

JWT 구조

JWT는 Header, Payload, Signature의 3 부분으로 이루어지며 Json 형태인 각 부분은 Base64Url로 인코딩 되어 표현된다. 

각각의 부분은 ". "구분자를 사용하여 구분한다.

추가로 Base64Url은 암호화된 문자열이 아니므로 같은 문자열에 대해 항상 같은 인코딩 문자열을 반환한다.

1. Header

• alg: Secret Key 를 암호화 할 알고리즘 방식을 지정하며 Signature 및 토큰 검증에 사용 
  ex) HS256(SHA256) 또는 RSA
• typ: 토큰의 타입을 지정 
  ex) JWT

{
        "alg": "HS256",
        "typ": JWT
}

2. Payload

토큰의 Payload에는 토큰에서 사용할 정보의 조각들인 Claim이 담겨 있다. 

Claim은 총 registered, public, private 의 3가지로 나누어지며, Json(Key & Value) 형태로 다수의 정보를 넣을 수 있다.

ㄴ 1. Registerd

Registerd Claim은 토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터들이다.

모두 선택적으로 작성이 가능하며 사용할 것을 권장한다. JWT를 간결하게 하기 위해 key는 모두 길이 3의 String이다.

여기서 subject로는 unique한 값을 사용하며, 주로 사용자 이메일을 사용한다.

• iss: 토큰 발급자(issuer)
• sub: 토큰 제목(subject)
• aud: 토큰 대상자(audience)
• exp: 토큰 만료 시간(expiration), NumericDate 형식으로 되어 있어야 함
  ex) 1480849147370
• nbf: 토큰 활성 날짜(not before), 이 날이 지나기 전의 토큰은 활성화되지 않음
• iat: 토큰 발급 시간(issued at), 토큰 발급 이후의 경과 시간을 알 수 있음
• jti: JWT 토큰 식별자(JWT ID), 중복 방지를 위해 사용하며, 일회용 토큰(Access Token) 등에 사용

ㄴ 2. Public

Public Claim은 사용자 정의 클레임으로 공개용 정보를 위해 사용된다.

충돌 방지를 위해 URI 포맷을 이용하며 예시는 아래와 같다.

{
        "https://mangkyu.tistory.com": true
}

ㄴ 3. Private

Private Claim은 사용자 정의 클레임으로 서버와 클라이언트 사이에 임의로 지정한 정보를 저장한다.

예시는 아래와 같다.

{
        "token_type": access
}

3. Signature

Signature는 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다. 

Signature를 생성하는 과정은 아래와 같다.

1. 위에서 만든 Header와 Payload의 값을 각각 BASE64Url로 인코딩한다.
2. 인코딩한 값을 Secret Key를 이용해 Header에서 정의한 알고리즘으로 해싱한다.
3. 이 값을 다시 BASE64Url로 인코딩하여 생성한다.

JWT 토큰 예시

완성된 JWT 의 형식은 아래와 같다.

Header(base64Url 인코딩).Payload(base64Url 인코딩).secretKey(Header의 알고리즘으로 암호화 후 base64Url인코딩)

생성된 토큰은 HTTP 통신을 할 때 Authorization이라는 key의 value로 사용된다. 

일반적으로 value에는 Bearer이 앞에 붙여지며 예시는 아래와 같다.

{
        "Authorization": "Bearer {생성된 토큰 값}"
}

JWT 단점 및 고려사항 

1. Self-contained: 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다. 
2. 토큰 길이: 토큰의 Payload에 3종류의 Clain을 저장하므로 정보가 많아질수록 토큰의 길이가 늘어나
   네트워크에 부하를 줄 수 있다. 
3. Payload 인코딩: Payload 자체는 암호화 된 것이 아니라 BASE64Url로 인코딩 된 것이다.
   중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로 JWE로 암호화하거나
   Payload에 중요 데이터를 넣지 않아야 한다. 
4. Stateless: JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 
   즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다. 
5. Store Token: 토큰은 클라이언트 측에서 관리해야 하기 때문에 토큰을 저장해야 한다.

관련글

스프링에서 JWT 발급해보기

발급된 JWT 를 이용한 인증

참고자료)

x-www-form-urlencoded와 json

x-www-form-urlencoded 와 json 는 content-type 의 한 종류이다.

여기서 content-type 이란 HTTP 요청 데이터를 전송할 때 헤더에 담기는 형식이다. 

테스트코드나 postman 등을 사용하여 보낸 요청을 확인할 때 content-type 을 설정한다.

주로 사용하는 2가지인 x-www-form-urlencoded와 json의 차이를 간단하게 살펴보자.

1. application/x-www-form-urlencoded

key1=value1&key2=value2&key3=value3&....

위 처럼 key = value 형식을 '&' 으로 구분지어 데이터를 전달해주는 형식이다.

전에는 이걸 주로 사용했지만 전송하는 데이터가 복잡해지면서 도메인 데이터를 명확하게 표현하는데 한계가 있다.

따라서 요즘엔 JSON 을 많이 사용한다.

2. application/json

{
     "key1" : "value1",
     "key2" : "value2",
     "data" : {
                   "key3" : "value3"
                  }
}

위 처럼 데이터를 전달하는 형식이다.

x-www-form-urlencoded 형식에서는 data 같은 새로운 객체의 데이터를 따로 구분지어 표시해주기 힘들지만

JSON 형식에서는 온전히 표현해줄 수 있기 때문에 최근에는 JSON 형식을 주로 사용한다.

HTTP 요청 데이터는 주로 다음과 같은 3가지 방법을 사용한다

1. GET - 쿼리 파라미터

다음과 같이 URL에서 쿼리 스트링 형식으로 전달한다.

http://localhost:8080/request-param?username=hello&age=20

• 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달
• 예) 검색, 필터, 페이징등에서 많이 사용하는 방식

2. POST - HTML Form

HTML Form 형식으로 요청 헤더를 보면 아래와 같은 형식을 확인할 수 있다.

content-type: application/x-www-form-urlencoded

• 메시지 바디에 쿼리 파라미터 형식으로 전달 
• message body:
  username=hello&age=20
• 예) 회원 가입, 상품 주문, HTML Form 사용
• 이 방식으로 데이터 전달 시 HTTP 메시지 바디에 해당 데이터를 포함해서 보내기 때문에
  바디에 포함된 데이터가 어떤 형식인지 content-type을 꼭 지정해야 한다.

3. HTTP message body

JSON 방식으로 보내면 아래와 같은 형식을 확인할 수 있다.

content-type: application/json

• 말 그대로 메시지 바디에 데이터를 담아 보낸다.
• message body:
  {
      "username": "hello",
      "age": 20
  }
• HTTP API에서 주로 사용하는 방식으로 JSON, XML, TEXT이 있다.
• POST, PUT, PATCH

이러한 JSON 데이터를 파싱, 처리해주는 라이브러리 (스프링의 경우 Jackson) 을 사용해서

역직렬화 하여 자바 객체로 변환할 수도 있다.

요약

1. 쿼리 파라미터 : 메시지 바디x, URL 에 쿼리 파라미터 형식
2. HTML Form : 메시지 바디에 쿼리 파라미터 형식
   key1=value1&key2=value2&... 형식
3. HTTP message body : 메시지 바디에 데이터를 담음, 주로 JSON

웹 서버 (Web Server)

• HTTP 기반으로 동작
• 정적 리소스 제공, 기타 부가기능
• 정적 HTML, CSS, JS, 이미지, 영상
• 에) NGINX, APACHE

웹 애플리케이션 서버 (WAS)

• HTTP 기반으로 동작
• 웹 서버 기능 포함
• 프로그램 코드를 실행해서 애플리케이션 로직 수행
  • 동적 HTML, HTTP API (JSON)
  • 서블릿, JSP, 스프링 MVC
    
    
• 예) 톰캣, Jetty, Undertow

웹 서버와 WAS 의 차이

웹 서버는 정적 리소스를, WAS는 애플리케이션 로직을 포함한 동적 리소스 처리한다.

사실 둘의 용어도 경계도 모호하다.

• 웹 서버도 애플리케이션 로직을 실행하는 기능을 포함하기도 함
• WAS도 웹 서버의 기능을 수행 가능

자바에서는 서블릿 컨테이너 기능을 제공하면 WAS 라고 하며 WAS는 애플리케이션 코드를 실행하는데 더 특화돼있다.

웹 서버와 WAS를 분리하는 이유는?

WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능하므로 WAS, DB 만으로도 시스템 구성이 가능하다.

그러나 주로 서버 구성 시에 웹 서버와 WAS를 분리하여 구성한다. 그 이유에 대해 알아보자.

1. WAS가 너무 많은 역할을 담당하면 서버 과부하 우려가 있다.

WAS 단독으로 사용시 정적 리소스 때문에 가장 중요한 애플리케이션 로직의 수행이 어려울 수 있다.

또한 WAS 장애 시 오류 화면 출력이 불가능하다.

2. 물리적으로 분리하여 보안을 강화한다.

WAS에는 실제 Web Application이 올라가 있기 때문에 외부와 직접 연결이 되어 있다면

중요한 설정 파일이나 리소스들이 외부로 노출될 수 있다.
이를 막기 위해서 웹 서버를 WAS앞단에 배치해서 리소스를 안전하게 보호할 수 있다.

3. 유연한 로드밸런싱이 가능하다.

정적 리소스는 웹 서버가 처리하고, WAS가 애플리케이션 로직같은 동적인 처리를 전담한다.

이에 따라 효율적인 리소스 관리가 가능해진다.

• 정적 리소스가 많이 사용되면 웹 서버 증설
• 애플리케이션 리소스가 많이 사용되면 WAS 증설

결론

웹 서버는 정적인 리소스를 제공하는 서버이고, WAS는 동적인 리소스를 제공하는 서버이다.

WAS 단독으로도 시스템 구성이 가능하지만 웹 서버와 WAS를 분리하여 구성하는 가장 큰 이유는 로드밸런싱.

REST 란

REST(Representational State Transfer)란 네트워크 아키텍처 스타일이다.

여기서 '네트워크 아키텍처 스타일'란 네트워크 자원을 정의하고 처리하는 방법 전반을 일컫는다.

즉, REST는 HTTP를 잘 활용하기 위한 원칙이라고 할 수 있고
REST API는 이 원칙을 준수해 만든 API이다.

그렇다면 HTTP를 잘 활용하기 위한 원칙은 무엇인가?

Representational State Transfer
자원의 표현으로 상태를 전달하는 것

URI로 자원을 표현하는 데에 집중하고, HTTP METHOD로 자원의 상태(행위)를 정의하는 것이

REST한 API를 설계하는 중심 규칙이다.

RESTful한 설계의 중심 규칙

• URI로 자원(리소스)을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현된다.

예시를 통해 살펴보도록 하자.

 GET /members/delete/1

위와 같은 방식은 REST를 제대로 적용하지 않은 URI이다. URI는 자원을 표현하는데 중점을 두어야 한다.

delete와 같은 행위에 대한 표현은 HTTP Method를 통해 표현한다.

위의 잘못된 URI를 HTTP Method를 통해 수정해 보면 아래와 같이 수정할 수 있다.

DELETE /members/1

회원정보 조회는 GET, 회원 추가를 표현하고자 할 때는 POST METHOD를 통해 표현한다.

회원정보를 조회하는 URI

GET /members/show/1     (x)
GET /members/1          (o)

회원을 추가할 때

GET /members/insert/2   (x) 
POST /members/2         (o)

추가 지식)

사실 요즘 사용하는 REST API 라는 용어는 HTTP API와 거의 같은 의미라고 한다.

본래 REST API는 HTTP 프로토콜을 따르면서 아래의 4가지 가이드 원칙을 지켜야 한다.

1. 자원의 식별
2. 메세지를 통한 리소스 조작
3. 자기서술적 메세지
4. 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어(HATEOAS)

이러한 제약 조건들을 완벽하게 지키면서 개발하는 것을 RESTful API라고 하는데

실무에서 이런 방법으로 개발하는 것은 현실적으로 어렵고 개발비용 대비 효과가 있는 것도 아니다.

(4번째 원칙이 특히나 구현하기 어렵다.)

그런데 이미 많은 사람들이 이 조건들을 지키지 않아도 REST API라고 하기 때문에 HTTP API와 같은 의미로 사용하고 있다.

하지만 엄밀하게는 위 제약 조건들을 모두 지켜야 REST API라고 말할 수 있다.

좀 더 알고싶다면 해당 유튜브 영상을 한 번 보는것도 괜찮을것 같다.

참고 자료)

https://bentist.tistory.com/37

API 란

영어로 풀어쓰면 Application Programing Interface 라고 한다.

여러가지 예시를 보면서 고민해봤지만 한마디로

 "다른 사람이 쓸 수 있도록 준비해 놓은것" 

이라고 정의 할 수 있다.

우리가 핸드폰을 사용하듯 내부에서 어떤 원리로 동작하는지는 사용자 입장에선 그다지 중요하지 않다.

그저 사용 설명서를 읽고 알맞은 입력값을 넣어 사용할 수 있으면 그만이다.

그래서 사용 설명서인 API 명세서를 잘 작성해야하며, 

플로우차트, 유스 케이스, 액티비티 다이어그램도 같이 있다면 사용법을 힉히기 훨씬 쉬울것이다.

+ 조금 더 깊게

Application Programing Interface (API) 의 의미

처음 봤을때 API의 영어 뜻이 이해가 안됐지만 공부할수록 잘 지은 이름이란걸 느끼고 있다.

해석해보면 애플리케이션에서 쓰는 프로그래밍 인터페이스라고 할 수 있는데, 전엔 잘 몰랐지만 이게 생각보다 명확한 의미였다.

스프링에서 쓰는 대표적인 API 의 예시는 JDBC, JPA 이다.

• JDBC

• JPA

인터페이스란 프로그램의 틀을 정해놓은 상호간의 약속 이다.

위의 예시들은 애플리케이션 로직이 구현체를 의존하는게 아닌 추상화된 인터페이스를 의존함으로써 

JDBC의 구현체로 MySQL DB을 쓰든 Oracle DB를 쓰든 약속 된 JDBC 표준 인터페이스의 틀만 맞춘다면 DB 연결이 가능하다.

또한 JPA의 구현체를 하이버네이트를 쓰든 이클립스링크를 쓰든 틀만 맞춘다면 JPA를 사용한 ORM 기술을 사용할 수 있다.

결론

API 란 상호간의 약속(입력값, 출력값, 데이터 형식 등)대로 동작하는 프로그램이다.

참고 자료)

김영한 님의 스프링 DB 1편