[CS] 애플리케이션 레이어 2

🚀HTTP 상태유지 기술(쿠키, 세션, JWT)

HTTP는 무상태(stateless) 프로토콜로 클라이언트와 서버가 요청/ 응답 후 상태를 유지 하지 않는다.

따라서 사용자 인증, 장바구니 유지 등을 위해 상태 유지 기술이 필요하다.

쿠키와 세션은 웹 애플리케이션에서 클라이언트와 서버 간의 상태를 유지하기 위한 핵심 기법이다.

쿠키란?

클라이언트에 저장되는 작은 데이터 조각으로 Set-Cookie 헤더로 설정한다.

1.[클라이언트] 서버로 요청

POST /login HTTP/1.1 Host: example.com

2. [서버] 응답하면서 쿠키 설정

HTTP/1.1 200 OK Set-Cookie: id=abc123; Path=/; HttpOnly

3. [클라이언트] 이 쿠키 정보를 브라우저의 쿠키 저장소에 저장

4. 이후 요청에서 브라우저가 쿠키를 자동으로 보냄

GET /mypage HTTP/1.1 Host: example.com Cookie: id=abc123

세션이란?

서버가 클라이언트 상태를 서버 메모리 또는 저장소에 저장해두는 것

1. [클라이언트] 로그인 요청

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=alice&password=1234

2. [서버] 로그인 인증 후 세션 생성

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=xyz123abc456; Path=/; HttpOnly

3. [클라이언트] 쿠키 저장

브라우저는 JSESSIONID=xyzabc 쿠키를 브라우저의 쿠키 저장소에 저장함

4. [클라이언트] 다음 요청 시 자동으로 쿠키 전송

GET /mypage HTTP/1.1
Host: example.com
Cookie: JSESSIONID=xyzabc

5. [서버] 세션 정보 사용

서버는 쿠키에서 JSESSIONID를 읽고,
해당 ID에 저장된 세션 정보를 메모리에서 꺼냄

session.getAttribute("user")

쿠키 vs 세션

항목	쿠키	세션
저장 위치	클라이언트(브라우저)	서버 (보통 메모리)
클라이언트 저장 내용	정보 자체	세션 ID (JSESSIONID)
보안	상대적으로 낮음 (노출 위험)	상대적으로 안전함 (정보는 서버에 있음)
용량 제한	약 4KB	서버 메모리 크기에 따라 다름
유지 조건	쿠키 유효기간(혹은 브라우저 꺼질 때까지)	세션 만료 시간 설정 (기본 30분 등)

JWT (JSON Web Token) 란?

서버가 상태를 저장하지 않고도 인증 가능한 토큰 기반 인증 방식으로 토큰 자체에 사용자 정보를 포함한다.

특징

서버가 사용자 상태를 별도 저장할 필요 없음
확장성과 분산환경에 적합
페이로드에 사용자 정보 포함 가능
토큰 탈취 시 위험
토큰 길이 길고, 만료 전까지 폐기 불가

1. [클라이언트] 로그인 요청

POST /login HTTP/1.1
Content-Type: application/json

{
  "username": "alice",
  "password": "1234"
}

2. [서버] 로그인 성공 시 JWT 생성

3. [서버 응답] 토큰을 클라이언트에게 전달

HTTP/1.1 200 OK
Content-Type: application/json

{
  "token": "<JWT 토큰 문자열>"
}

4. [클라이언트] JWT 저장

localStorage.setItem("accessToken", "<JWT 토큰>");

5. [클라이언트] API 요청 시 JWT 포함

GET /mypage HTTP/1.1
Authorization: Bearer <JWT 토큰>

이때 Authorization 헤더에 Bearer 타입으로 넣는 게 일반적이다.

6. [서버] JWT 검증 및 사용자 정보 추출

Authorization 헤더에서 JWT 토큰 추출
서버에 저장된 비밀 키로 서명 유효성 검사
토큰이 유효하면 내부에 담긴 사용자 정보(userId, role 등)를 읽어 활용

Claims claims = jwtParser.parse(token);
Long userId = claims.get("userId");

7. [서버] 응답

HTTP/1.1 200 OK
Content-Type: application/json

{
  "message": "Welcome, alice!",
  "userId": 1
}

🚀 SOP, CORS 개념과 RESTful API

SOP(Same-Origin Policy)란?

서로 다른 출처(origin)의 자원 간 접근 제한

출처 기준: 프로토콜 + 도메인 + 포트

예시

http://example.com:80 → http://example.com:81 ❌ (포트 다름)
https://example.com → http://example.com ❌ (프로토콜 다름)

CORS (Cross-Origin Resource Sharing)란?

출처가 다른 자원 요청을 허용할지 말지를 결정하는 브라우저 보안 정책

브라우저 출처(origin)가 다른 서버로 요청을 보낼 때,

그 서버가 허용해줘야 요청이 성공할 수 있게 해주는 메커니즘

출처란?

출처 = 프로토콜 + 도메인 + 포트

URL	출처
http://localhost:3000	http, localhost, 3000
http://api.example.com	http, api.example.com, 80

예시)

React 프론트엔드: http://localhost:3000
Spring 백엔드 API: http://localhost:8080

이 두 개는 포트가 다르기 때문에 출처가 다르다.

그래서 브라우저는 이 요청을 크로스 오리진 요청이라고 판단하고 보안상의 이유로 이 요청을 막는다.

구분	설명
목적	다른 출처(Origin) 간의 HTTP 요청을 제어
기본 동작	브라우저가 다른 출처 요청을 막음
해결 방법	서버가 응답 헤더에 Access-Control-Allow-Origin을 설정해서 허용
적용 대상	브라우저에서의 요청만 해당됨 (Postman, 서버 간 통신은 영향 없음)

RESTful API란?

자원을 URL로 표현하고, HTTP 메서드로 행동을 나타내는 API 설계 방식

REST: 자원을 URL로 표현하고, HTTP 메서드로 행동 표현

RESTful: REST 원칙에 잘 맞게 API를 설계한 상태

특징

자원은 명사, 동작은 HTTP 메서드로 표현

URL 예시:

GET /users/123 → 사용자 정보 조회
POST /users → 사용자 생성
PUT /users/123 → 사용자 전체 수정
DELETE /users/123 → 사용자 삭제

RESTful API를 쓰는 이유

일관성	모든 API가 비슷한 패턴이라 이해가 쉬움
직관성	URL만 봐도 무슨 데이터에 대한 건지 바로 알 수 있음
확장성	프론트엔드/백엔드가 분리된 구조에서 매우 유용함
표준화	다른 개발자와 협업할 때도 원활함 (API 문서화 쉬움)

🚀 XSS, CSRF, SQL Injection 방어 기법

XSS란?

악성 스크립트를 삽입하여 사용자의 브라우저에서 실행하는 것

방어법

출력 시 인코딩 (HTML, JavaScript)
- 예: <script> → <script>
Content Security Policy(CSP) 설정
HttpOnly 쿠키로 JS 접근 차단

CSRF란?

사용자가 로그인된 상태에서 악성 사이트가 의도치 않은 요청 유도

방어법

CSRF 토큰 사용: 요청마다 난수 값을 포함
SameSite 쿠키 설정
Referer 헤더 확인: 요청 출처 검증

SQL Injection이란?

사용자 입력에 SQL 구문 삽입 후 데이터베이스 조작

방어법

Prepared Statement (매개변수화 쿼리) 사용
ORM 사용 (ex. JPA)
입력값 검증 (숫자, 길이, 특수문자 제한)

🚀 웹 캐시와 프록시 서버(포워드, 리버스 프록시)

웹캐시란?

웹 페이지나 리소스를 임시로 저장해두고, 다음 요청 시 빠르게 응답하는 기술

브라우저 캐시	브라우저가 가지고 있음 (가장 가까움)
프록시 캐시	중간 서버(프록시 서버)가 가지고 있음
CDN 캐시	전 세계에 퍼져있는 서버들이 가지고 있음 (Cloudflare, Akamai 등)

프록시 서버란?

클라이언트와 서버 사이에서 중간 요청을 대신 처리해주는 서버

포워드 프록시

클라이언트를 대신해서 서버에 요청을 보내는 프록시

이미지 출처: https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/

리버스 프록시

서버 앞단에서 요청을 받아 백엔드 서버에 전달하는 프록시

'CS > 네트워크' 카테고리의 다른 글

[CS] 트랜스포트 레이어(UDP, TCP) (0)	2025.04.27
[CS] 애플리케이션 레이어 1 (HTTP) (0)	2025.04.11
[CS] 컴퓨터 네트워크의 기본 개념 (0)	2025.04.06

🚀HTTP 상태유지 기술(쿠키, 세션, JWT)

쿠키란?

세션이란?

JWT (JSON Web Token) 란?

🚀 SOP, CORS 개념과 RESTful API

SOP(Same-Origin Policy)란?

CORS (Cross-Origin Resource Sharing)란?

RESTful API란?

🚀 XSS, CSRF, SQL Injection 방어 기법

XSS란?

CSRF란?

SQL Injection이란?

🚀 웹 캐시와 프록시 서버(포워드, 리버스 프록시)

웹캐시란?

프록시 서버란?

'CS > 네트워크' 카테고리의 다른 글

티스토리툴바