들어가며
현대 웹 애플리케이션과 API 시스템은 모두 네트워크 위에서 동작합니다.
그리고 이 통신 과정은 늘 위조, 도청, 스니핑, 위협 요소에 노출될 수 있습니다.
이러한 위험으로부터 시스템을 보호하기 위한 첫걸음이 바로 **네트워크 보안(Network Security)**입니다.
이 글에서는 실무에서 가장 자주 마주치는 세 가지 개념, SSL(HTTPS), CORS, CSRF를 중심으로, 네트워크 보안의 기초를 소개하며 📂 Network / Network Security 카테고리의 시작을 열겠습니다.
왜 네트워크 보안이 필요한가?
| 위험 요소 | 설명 |
| 도청 (Sniffing) | 통신 중간에 데이터를 가로채 읽는 행위 |
| 위조 (Spoofing) | 신뢰할 수 있는 것처럼 가장한 접근 시도 |
| 세션 탈취 | 로그인 세션 쿠키를 훔쳐 사용자로 위장 |
| 크로스 도메인 접근 | 의도치 않은 출처에서 API 호출 |
보안은 사용자 신뢰와 시스템 신뢰성의 기본입니다.
1. SSL/TLS – HTTPS는 어떻게 통신을 보호하는가?
- HTTPS는 HTTP에 SSL/TLS 암호화 계층을 추가한 것입니다.
- 클라이언트와 서버 간 통신을 대칭 + 비대칭키로 안전하게 암호화합니다.
- 인증서 기반으로 서버의 신원을 검증하고, 암호화된 세션을 형성합니다.
실무 포인트
- SSL 인증서가 없으면 https:// 접속이 불가능하거나 브라우저 경고 발생
- 프론트엔드 fetch/axios 요청 시 https 환경이 기본 요구됨
- API 게이트웨이에서도 TLS 인증서 설정이 필요함
2. CORS – 왜 내 API는 막히는가?
CORS(Cross-Origin Resource Sharing)는
**브라우저 보안 정책(동일 출처 정책, Same-Origin Policy)**을 우회하는 표준입니다.
| 개념 | 설명 |
| 동일 출처 | 프로토콜, 도메인, 포트 모두 같아야 함 |
| CORS 오류 | 프론트엔드와 백엔드 출처가 다를 때 발생 |
| 해결 방식 | 서버에서 Access-Control-Allow-* 헤더로 허용 |
실무 포인트
- 개발환경(localhost:3000 → localhost:8080)에서 자주 발생
- Nginx나 Express, Spring에서 CORS 허용 설정 필요
- 프리플라이트 요청(OPTIONS)을 이해해야 함
3. CSRF – 사용자의 신뢰를 이용한 공격
CSRF(Cross-Site Request Forgery)는
인증된 사용자의 브라우저를 속여 공격자가 의도한 요청을 보내게 하는 공격 기법입니다.
작동 방식
- 사용자가 로그인 상태로 공격자의 사이트 접속
- 백그라운드에서 인증 쿠키를 담은 악의적 요청 전송
- 서버는 이를 정당한 요청으로 처리해버림
방어 전략
- 서버에서 CSRF 토큰 발급 → 요청 시 토큰 검증
- SameSite 쿠키 옵션 설정 (Lax, Strict, None)
- 중요 요청은 가능한 GET 대신 POST + CSRF 토큰 사용
앞으로 다룰 주제들
📂 Network / Network Security 카테고리에서는 다음과 같은 실전 중심 내용을 다룰 예정입니다:
- SSL 인증서 발급과 Nginx에 적용하기
- Let's Encrypt + certbot 자동 갱신
- Spring / Express에서 CORS 설정 예시
- 프리플라이트 요청(OPTIONS)의 구조와 응답 처리
- CSRF 방어를 위한 Spring Security 설정법
- 쿠키의 SameSite 옵션 완전 정리
보안은 선택이 아닌 기본입니다.
웹과 API가 연결되는 모든 순간, 우리는 네트워크 보안의 원리와 구현 방식을 이해하고 있어야 합니다.
📌 다음 글 미리보기
👉 SSL 인증서 발급과 Nginx에 적용하기
📚 Network Security 시리즈 전체 보기
👉 https://jobreview.tistory.com/category/network/network_security
댓글