cookie와 session이 필요한 이유

cookie와 session이 필요한 이유를 이해하기 위해서는 HTTP 프로토콜의 connectionless, stateless한 특성에 대한 이해가 필요하다.
connectionless는 클라이언트에서 요청을 한 뒤에 서버로부터 응답을 받으면 해당 연결을 끊어버리는 HTTP 프로토콜의 특징이다. HTTP가 TCP를 기반으로 구현되었기 때문에 네트워크 관점에서 keep-alive는 옵션으로, 연결비용을 줄이는 것을 장점으로 비연결지향이라고 한다.

stateless는 클라이언트와 서버의 통신이 끝나면 상태를 유지하지 않는 HTTP 프로토콜의 특징이다. 연결이 끊기는 순간 클라이언트와 서버간의 통신이 끝나고, 상태 정보는 유지하지 않는 것이 특징이다.

cookie와 session은 앞서 설명한 HTTP 프로토콜의 두 가지 특징(connectionless, stateless)이 가지는 단점을 해결하기 위해 사용된다.
우리가 특정 웹 페이지를 이용할때 한 번의 로그인을 한 뒤에 로그인한 사용자에 대한 인증을 유지하는 것이 바로 쿠키와 세션을 사용했기 때문이다. 쿠키와 세션을 사용하지 않는다면, 새로운 페이지로 이동할때마다 다시 로그인을 해야한다.

cookie, session, JWT(JSON Web Token)

cookie와 session의 차이점에 있어, 정보가 저장되는 위치와 보안에 대한 부분도 있지만 이보다 더 중요한 것은 lifecycle에 대해 이해하는 것이 중요하다. cookie와 session 모두 만료시간이 있지만, cookie의 경우에는 클라이언트의 로컬에 파일로 저장되기 때문에 브라우저가 종료되어도 계속 정보가 남아있지만, 세션의 경우에는 만료시간과 상관없이 브라우저가 종료되면 삭제된다는 특징을 가지고 있다.

CORS(Cross-Origin Resource Sharing) ?

브라우저상에서 정보를 받는 곳과 보내는 곳이 신뢰할 수 있는 곳인지 확인하는 절차가 필요하다.
발신자와 수신자를 신뢰할 때 정보의 신뢰성과 보안이 보장될 수 있기 때문이다.

CORS issue는 브라우저와 서버 간의 요청에서만 발생되며, 서버와 서버간에는 발생하지 않는다.
요청을 보내는 쪽과 받는 쪽의 도메인이 서로 다른 경우, browser가 해당 요청을 차단한다.

동일 출처 정책(same origin policy)

하나의 근원지로부터 문서 또는 스크립트를 로드함으로써 다른 근원지로부터 오는 잠재적인 악성 문서를 격리하는 정책이다.

CORS 해결방법

직접적으로 사용자들의 browser를 변조해서 CORS 문제를 해결할 수 없기 때문에 아래의 두 가지 방법으로 CORS 문제를 해결할 수 있다.

• 해결방법1: Proxy 방식

  예를들어 브라우저에서 다른 도메인인 백엔드 서버로 요청을 보내는 것은 문제가 되기 때문에 브라우저와 같은 도메인인 프론트엔드 서버를 거쳐서 백엔드 서버로의 요청과 응답을 처리하는 방법이다.

• 해결방법2: Access-Control-Allow-Origin header 허용

  header의 Access-Control-Allow-Origin의 통해 요청이 오는 특정 도메인을 허용할 수 있다.

  예를들어 Express server에서 router의 callback 함수에서 response를 통해 header의 Access-Control-Allow-Origin 속성을 통해 특정 도메인을 허용해주거나, cors middleware를 사용해서 해결할 수 있다.

  1 2 3 4 5 6 7 8 9 10

  res.setHeader('Access-Control-Allow-Origin', '*'); // cors middleware app.use( cors({ // 요청을 보낸 도메인이 자동으로 허용된다. origin: true, credentials: false }) );