현대 웹 서비스 보안의 중심에는 REST API가 있습니다.
로그인, 데이터 조회, 결제, 사용자 권한 처리까지 우리가 일상적으로 사용하는 대부분의 기능은 모두 API 통신을 기반으로 이루어지고 있습니다. 그렇기 때문에 이 과정에서 발생하는 보안 문제는 곧 서비스 전체의 보안 문제로 직결됩니다. 실제로 많은 기업들이 세션 관리 오류, JWT 토큰 저장 위치 실수, CSRF/CORS 설정 미흡 때문에 심각한 보안 사고를 겪어왔습니다.
이번 글에서는 바로 이러한 핵심 요소들을 깊이 있게 다루기 위해 REST API 보안을 주제로 잡았습니다. 단순 개념 나열이 아니라, “실무에서 바로 적용 가능한 보안 설정과 동작 원리”, 그리고 정보처리기사 실기에도 그대로 활용 가능한 핵심 이론까지 함께 정리해드립니다.
특히 다음과 같은 내용을 집중적으로 다룹니다:
- HTTPS 통신으로 데이터를 어떻게 안전하게 보호하는지
- 쿠키/세션과 토큰 기반 인증(JWT)의 정확한 차이
- 실무에서 가장 많이 터지는 CORS 문제와 안전한 설정법
- CSRF 공격이 실제로 어떻게 일어나며 어떻게 막는지
- 정보처리기사 실기 문제에서 REST API 보안이 어떤 형태로 출제되는지
이 글에서 말하는 REST API 보안 실무는 초급·중급 개발자, 공공기관/기업에서 보안 설정을 맡는 실무자, 그리고 정보처리기사 실기를 준비하는 분들에게 모두 도움이 되도록 작성했습니다. 특히 보안은 “개념을 아는 것”이 아니라 “왜 그렇게 해야 하는지 이해하는 것”이 핵심이기 때문에, 가능한 한 실제 예시, 코드 샘플, 사고 사례 중심으로 설명해드릴까 합니다.
이제 REST API 보안을 제대로 이해하고, 실무에서도 자신 있게 적용할 수 있는 시간입니다. 천천히, 하지만 깊이 있게 따라오시길 바랍니다!

1. REST API 보안이 중요한 이유
REST API는 “상태를 저장하지 않는(Stateless)” 특징을 가집니다.
즉, 서버는 요청이 올 때마다 새로운 요청으로 처리합니다.
→ 이 말은 곧, 인증·보안 정보는 매 요청마다 함께 전송되어야 한다는 뜻입니다.
따라서 HTTP 요청이 공격자에게 노출되면 그대로 악용될 위험이 큽니다.
2. HTTPS(SSL/TLS) 보안 작동 원리
✔ HTTPS란?
- HTTP에 SSL/TLS 암호화를 더한 프로토콜입니다.
- 통신하는 모든 데이터를 암호화하여 중간에서 탈취해도 읽을 수 없게 만듭니다.
✔ 왜 HTTPS가 필수인가?
- 로그인 정보, 토큰, 쿠키가 모두 암호화되어 전송
- 중간자 공격(MITM) 차단
- Google SEO 점수 상승 (HTTPS는 순위 요소)
✔ 작동 방식 (핸드쉐이크 4단계)
- 클라이언트가 서버에게 접속 요청
- 서버가 인증서(공개키 포함)를 전달
- 브라우저가 이를 검증
- 대칭 키 생성 후 세션 암호화 시작
✔ 서버 설정 예시(Nginx)
server {
listen 443 ssl;
ssl_certificate /etc/ssl/cert.pem;
ssl_certificate_key /etc/ssl/key.pem;
}
3. CORS(교차 출처 리소스 공유)
✔ CORS란?
REST API 보안에 있어 브라우저가 다른 출처에서 오는 요청을 차단하는 보안 정책입니다.
출처 = 프로토콜 + 도메인 + 포트
- https://abc.com
- http://abc.com:8080 → 다른 출처 // 예시입니다.
✔ CORS가 필요한 이유
최근 웹은
- React/Vue 프론트
- Spring/Node 백엔드
로 분리되므로 서로 다른 출처에서 요청을 주고받기 때문입니다.
✔ CORS 기본 응답 헤더
Access-Control-Allow-Origin: https://my-frontend.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
✔ Spring Boot CORS 설정 예
@Configuration
public class CorsConfig {
@Bean
public WebMvcConfigurer corsConfigurer() {
return new WebMvcConfigurer() {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/api/**")
.allowedOrigins("https://my-frontend.com")
.allowedMethods("GET", "POST", "PUT", "DELETE")
.allowCredentials(true);
}
};
}
}
4. CSRF(Cross Site Request Forgery)
✔ CSRF란?
사용자 모르게 악성 요청을 보내는 공격 방식입니다.
예시 상황: 로그인된 사용자가 악성 사이트 방문 → 자동으로 “내 계좌 이체 요청” 전송
✔ 방지 방법
- CSRF Token 사용 (가장 중요)
- SameSite=Lax 또는 Strict 쿠키 설정
- Referer / Origin 검증
✔ CSRF 토큰 예시
<input type="hidden" name="_csrf" value="${_csrf.token}">
Spring Security는 기본적으로 CSRF 방지가 활성화되어 있습니다.
5. JWT 보안 완전 정복
✔ JWT 기본 구조 (3단계)
header.payload.signature
- Header : 알고리즘 정보
- Payload : 유저 정보, 만료 시간
- Signature : 위변조 방지
✔ JWT 사용 시 반드시 지켜야 할 규칙 (중요)
- JWT은 로컬스토리지에 저장 금지
→ XSS 공격에 취약 - 가능한 한 HttpOnly Cookie로 관리
- Payload는 암호화되어 있지 않음
→ 민감한 정보 절대 넣지 않기 - 만료 시간을 반드시 짧게 설정
6. Access/Refresh Token 전략
| 구분 | Access Token | Refresh Token |
|---|---|---|
| 만료 시간 | 짧음 (5~30분) | 길음 (7~30일) |
| 용도 | API 호출 | Access Token 재발급 |
| 보관 위치 | HttpOnly Cookie | HttpOnly Cookie or Secure Storage |
| 보안 위험 | 탈취되면 즉시 사용 가능 | 탈취 시 장기 위험 |
※ Access Token 재발급 API 예시
app.post("/refresh", (req, res) => {
const { refreshToken } = req.cookies;
jwt.verify(refreshToken, REFRESH_SECRET, (err, user) => {
if (err) return res.sendStatus(403);
const newAccess = jwt.sign({ id: user.id }, ACCESS_SECRET, { expiresIn: "15m" });
res.cookie("access", newAccess, { httpOnly: true });
res.send("Token refreshed");
});
});
7. API Rate Limit(요청 제한) 적용
반복 로그인 공격(Brute force)과 봇 공격을 방지하는 기법입니다.
예: IP당 1시간 100회 제한
(Node.js Express 예시)
const rateLimit = require("express-rate-limit");
const limiter = rateLimit({
windowMs: 60 * 60 * 1000,
max: 100,
message: "Too many requests. Try again later."
});
app.use("/api/", limiter);
8. 서버 측 Validation(검증) 반드시 적용
프론트엔드 검증만 믿으면 절대 안 됩니다.
OWASP 권장 안전성 검증
- 이메일 포맷 체크
- 비밀번호 길이 및 조합
- SQL Injection 방지
- 파일 업로드 확장자·크기 제한
※ Spring Validation 예시
@NotBlank
@Email
private String email;
9. REST API 인증·인가 설계 Best Practice
- 모든 민감 요청은 HTTPS 필수
- JWT는 쿠키(HttpOnly) 기반으로 관리
- Access/Refresh Token 구조 적용
- CORS는 필요한 출처만 허용
- CSRF Token 활성화
- 중요 API는 Rate Limit 적용
- 서버 측 Validation 강제 적용
- 비밀번호는 Bcrypt로 단방향 암호화
10. REST API 보안의 실무 전체 예제 – 안전한 로그인 설계 완성본
// 1) 로그인 → 토큰 발급
app.post("/login", async (req, res) => {
const user = await findUser(req.body.email);
if(!user) return res.status(401).send("INVALID USER");
const access = jwt.sign({ id: user.id }, ACCESS_SECRET, { expiresIn: "15m" });
const refresh = jwt.sign({ id: user.id }, REFRESH_SECRET, { expiresIn: "14d" });
res.cookie("access", access, { httpOnly: true, secure: true });
res.cookie("refresh", refresh, { httpOnly: true, secure: true });
res.send("LOGIN OK");
});
// 2) 인증 미들웨어
function auth(req, res, next) {
const token = req.cookies.access;
if(!token) return res.sendStatus(401);
jwt.verify(token, ACCESS_SECRET, (err, user) => {
if(err) return res.sendStatus(403);
req.user = user;
next();
});
}
11. REST API 보안 관련 정보처리기사 실기 대비 핵심 요약
| 개념 | 실기 출제 포인트 |
|---|---|
| HTTPS | SSL/TLS 암호화 방식 |
| CORS | Preflight 요청 의미 |
| CSRF | 위조 요청 방지 토큰 |
| JWT | 구조, Signature 역할 |
| 인증/인가 | Authentication / Authorization 구분 |
| REST 보안 | Stateless 보안 위험 |
REST API 보안이 정보처리기사 실기(특히 업무 프로세스·보안·기술 요소 영역)에서 출제되는 파트에서 점수를 취득하기 위해서는 “웹 보안 개념 + 실제 동작 원리 + 공격/방어 방식”을 정확히 이해해야 합니다. 아래 내용을 숙지하면 REST·웹 보안 관련 문제의 거의 모든 유형을 대응할 수 있습니다.
실제 실기에서 자주 나오는 문제 유형:
- “CORS에서 Preflight가 필요한 상황은?”
- “JWT Signature의 역할은?”
- “CSRF 공격이란?”
- “HTTPS가 MITM 공격을 막는 원리는?”
(1) HTTPS의 목적
- 데이터 기밀성(암호화) 확보
- 데이터 무결성(변조 방지)
- 서버의 신뢰성(인증서 검증) 확보
※ 출제 유형 예시
“SSL/TLS에서 데이터 암호화를 위해 사용되는 방식은 무엇인가?”
정답: 대칭키 + 공개키 기반 혼합 암호화 방식
(2) SSL/TLS 핸드셰이크 개념
실기에서 자주 묻는 부분입니다.
※ 핵심 흐름
- 클라이언트 → 서버에게 접속 요청
- 서버 → 인증서(공개키) 전송
- 브라우저 → 인증서 검증 후 세션키 생성
- 세션키를 서버 공개키로 암호화해 전달
- 이후 모든 내용은 세션키(대칭키)로 암호화
※ 출제 유형 예시
✔ 공개키는 키 교환용
✔ 실제 데이터는 대칭키로 암호화
✔ 이유: “대칭키가 속도가 빠르기 때문”
3) CORS(교차 출처 리소스 공유)
※ 출제 포인트
- SOP(Same Origin Policy) 개념 이해
- 다른 출처에서 API 요청 시 브라우저가 차단
- Preflight(OPTIONS) 요청의 역할
※ 출제 유형 예시
“CORS에서 Preflight 요청(OPTIONS)이 발생하는 이유는?”
정답: 실제 요청 전 브라우저가 서버에게 허용된 Origin/Method/Header를 확인하기 위해
※ 자주 등장하는 헤더
Access-Control-Allow-OriginAccess-Control-Allow-MethodsAccess-Control-Allow-Headers
특히 “허용할 Origin만 명시적으로 지정해야 안전하다”는 점이 실기에서도 언급됩니다.
4) CSRF(Cross Site Request Forgery)
※ 출제 포인트
- “사용자 의도와 관계없이 공격자가 요청을 보냄”
- 쿠키 기반 인증 구조에서 잘 발생
- GET 방식도 공격 가능
※ 방지 방법
- CSRF Token 사용 (가장 중요한 정답)
- Referer / Origin 체크
- SameSite=Lax/Strict 설정
- 중요한 요청은 POST/PUT 사용
※ 출제 유형 예시
“CSRF 공격 방지 기법으로 옳지 않은 것은?”
정답:
✔ CAPTCHA
✔ CSRF Token
✔ Double Submit Cookie
❌ XSS 필터링(→ 다른 공격에 대한 방지책)
5) JWT(JSON Web Token)
※ 출제 포인트
- JWT 구조: Header.Payload.Signature
- 서명(Signature)은 위변조 방지
- Payload는 암호화 X → 누구나 디코딩 가능
- 만료 시간(
exp)의 중요성
※ 출제 유형 예시
“JWT Payload에 저장해서는 안 되는 정보는?”
정답:
주민등록번호, 비밀번호 등 민감 정보
※ Access / Refresh Token 차이
| 항목 | Access Token | Refresh Token |
|---|---|---|
| 목적 | API 인증 | Access 재발급 |
| 유효시간 | 짧음 | 김 |
| 보관 | HttpOnly Cookie | HttpOnly Cookie |
| 위험성 | 탈취 시 즉시 사용 | 장기 위험 |
※ 출제 포인트 : “Refresh Token은 탈취 위험이 크므로 안전한 저장 메커니즘이 필요하다”
6) 인증(Authentication) vs 인가(Authorization)
정보처리기사 실기 단골 문제입니다.
| 용어 | 의미 |
|---|---|
| 인증(Authentication) | “당신이 누구인지 확인” (로그인) |
| 인가(Authorization) | “당신이 무엇을 할 수 있는지 확인” (권한) |
※ 출제 유형 예시
“사용자 권한(Role)을 검사하는 과정은 인증인가 인가인가?”
정답: 인가(Authorization)
7) REST API의 보안적 특징
※ Stateless 특성 -> 요청마다 인증 필요
- 서버가 세션을 기억하지 않기 때문에 매 요청에 토큰/쿠키 포함
- 보안 설정이 빠지면 공격자가 악용하기 쉬움
※ 출제 포인트
“Stateless 구조에서 인증 정보는 어떤 방식으로 유지되는가?”
→ 토큰 기반(JWT), 세션-쿠키 기반
8) XSS(Cross Site Scripting)
JWT 저장 위치와 연계해 출제될 수 있는 부분입니다.
※ 핵심 개념
- 악성 스크립트를 주입해 사용자의 쿠키/세션을 탈취하는 공격
※ 보안 방법
- 입력값 검증
- HTML 엔티티 인코딩
- 쿠키
HttpOnly옵션 - CSP 정책 적용
※ 출제 유형 예시
“쿠키 탈취 방지 방법으로 가장 효과적인 것은?”
정답: HttpOnly 옵션
9) SQL Injection
REST API 보안에서 Validation과 함께 필수 출제 범위입니다.
※ 핵심 개념
- 외부 입력값을 통해 SQL 구문을 조작하는 공격
※ 출제 포인트
- Prepared Statement
- ORM 사용
- 입력값 검증
- 권한 최소화
※ 출제 유형 예시
“SQL Injection 방지 기법이 아닌 것은?”
정답: “문자열 연결 방식으로 쿼리 구성”
10) 인증 방식 비교 – 실기 대비
| 인증 방식 | 특징 | 실기 포인트 |
|---|---|---|
| 세션(Session) | 서버 저장, 쿠키로 연결 | 서버 메모리 사용 |
| JWT | 서버 저장 없음(Stateless) | 서명으로 위변조 방지 |
| OAuth2 | 소셜 로그인 | Authorization Code Flow |
| Basic Auth | ID/PW Base64 | HTTPS 필수 |
※ 출제 유형 예시 : “서버 메모리를 줄이기 위해 어떤 인증 방식이 적합한가?” → JWT
11) 보안 관련 필수 HTTP Header (기출 가능)
| 헤더 | 역할 |
|---|---|
| X-Frame-Options | 클릭재킹 방지 |
| X-XSS-Protection | XSS 기본 보호 |
| Content-Security-Policy | 스크립트 출처 제어 |
| Strict-Transport-Security | HTTPS 강제 |
| Set-Cookie(HttpOnly, Secure) | 쿠키 보안 강화 |
※ 출제 유형 예시
“다음 중 클릭재킹 방지 헤더는?”
정답: X-Frame-Options
✔ REST API 보안 실기 대비 핵심 정리(최종)
- HTTPS는 SSL/TLS 기반 암호화
- CORS는 브라우저의 동일 출처 정책 우회
- CORS Preflight는 OPTIONS 요청
- JWT는 Header.Payload.Signature 구조
- Signature는 위변조 방지
- JWT Payload는 암호화되지 않음
- CSRF는 사용자를 속여 요청을 보내는 공격
- CSRF Token으로 방지
- 세션 = 서버 저장, JWT = Stateless
- Authentication = 로그인
- Authorization = 권한 확인
- SQL Injection은 Prepared Statement로 방지
- XSS는 HttpOnly Cookie로 방지
- Strict-Transport-Security는 HTTPS 강제
- Refresh Token은 위험 → 보안 강화 필요
이 정도 파트만 정확히 이해하면 정보처리기사 실기에서 REST 보안 파트는 90% 이상 득점 가능합니다.
12. 마무리
REST API 보안은 단순 이론이 아니라 “실무 품질”을 결정하는 핵심 요소입니다.
이번 편에서 다룬 REST API 보안의 HTTPS, CORS, CSRF, JWT가 바로 웹 개발의 보안 4대 핵심 축이라고 할 수 있습니다.
13. 다음 편 예고
다음 편은 [정보처리기사] 제 15편 – API 성능 최적화 & 장애 대응 실무편 (로드밸런싱·캐싱·지수적 백오프) 으로 찾아오겠습니다. API의 성능을 최적화하고 그에 따른 장애에 대응하는 것은 SM 실무에 있어 가장 중요한 부분 중 하나입니다. 기존 REST API 보안보다 조금 더 나아가 실무에 적용되는 부분에 대한 내용이니 단단한 백엔드 개발자가 되고 싶다면 꼭 함께 읽어주세요!
14. 이전 편을 보지 못했다면?
[정보처리기사] 필기 실기 통합 이론 제 1편 – 정보와 보안의 모든 것
[정보처리기사] 필기 실기 통합이론 제2편 – 디자인패턴
[정보처리기사] 필기·실기 통합이론 제3편 – IT 신기술 및 전산 용어 총정리
[정보처리기사] 필기·실기 통합 이론 제 4편 – 실무에서 바로 쓰이는 기출전산용어
[정보처리기사] 필기·실기 통합 이론 제 5편 – 기출용어 중 실무에서 자주 쓰이는 고급 전산용어
[정보처리기사] 필기·실기 통합 이론 제 6편 – 기출용어 중 실무에서 자주 쓰이는 네트워크 보안과 데이터 암호화 핵심 정리 (SSL/TLS 포함)
[정보처리기사] 필기·실기 통합 이론 제 7편 – 실무에서 바로 쓰이는 네트워크 구조 완전 정복
[정보처리기사] 제 8편 – TCP/IP 완전 정복 (핵심 개념 + 포트번호 + 계층 역할)
[정보처리기사] 필기 실기 통합 이론 제 9편 – 웹 통신 완전 정복(HTTP, HTTPS, 쿠키, 세션, 토큰)
[정보처리기사] 필기 실기 통합 이론 제 10편 – 웹 보안 완전 정복(XSS · CSRF · SQL Injection 쉽게 이해하기)
[정보처리기사] 필기 실기 통합 이론 제 11편 – 웹 서버와 WAS 구조 완전 정복
[정보처리기사] 필기 실기 통합 이론 제 12편 – REST API 완전 정복(입문부터 실무까지)
[정보처리기사] 필기 실기 통합 이론 제 13편 – REST 인증 방식(OAuth·토큰·쿠키) 완전 정복