안녕하세요. 평상시보다 1시간정도 늦게자니 하루종일 피곤하네요.그래도 할일은 다 해야겠죠? 그래야지 주말에 신나게 놀 수 있으니까요!
저번 시간에는 CORS에 대해서 학습해봤었죠? 이번 시간에는 OWASP 보안 취약점에 대해서 알아보도록 하겠습니다.
OWASP
OWASP(Open Worldwide Application Security Project)는 웹 애플리케이션 보안과 관련된 지식, 도구, 문서, 가이드를 제공하는 비영리 커뮤니티입니다.
개발자와 보안 담당자가 애플리케이션에서 자주 발생하는 보안 위험을 이해하고, 이를 예방할 수 있도록 자료를 제공합니다.
그 중 OWASP Top 10은 웹 애플리케이션에서 자주 발생하고 영향도가 큰 보안 위험을 정리한 대표적인 문서입니다.
OWASP Top 10
OWASP Top 10은 웹 애플리케이션에서 주의해야 할 주요 보안 위험 10가지를 정리한 문서입니다.
여기서 중요한 점은 OWASP Top 10이 단순한 취약점 이름 목록이 아닌 웹 애플리케이션에서 반복적으로 발생하는 보안 위험을 개발자가 인식하고 우선순위를 정할 수 있도록 도와주는 자료라는 점입니다.
즉, OWASP Top 10은 "이 10가지만 막으면 보안이 완벽해!"라는 의미가 아닌 개발자가 웹 보안에서 먼저 점검해야 할 대표적인 위험 목록에 가깝습니다.
OWASP Top 10 2025 목록
| 구분 | 항목 | 의미 |
| A01 | Broken Access Control | 접근 권한 검증 실패 |
| A02 | Security Misconfiguration | 보안 설정 오류 |
| A03 | Software Supply Chain Failures | 의존성, 빌드, 배포 공급망 위험 |
| A04 | Cryptographic Failures | 암호화 처리 실패 |
| A05 | Injection | SQL Injection, XSS 등 삽입 공격 |
| A06 | Insecure Design | 보안이 고려되지 않은 설계 |
| A07 | Authentication Failures | 인증 처리 실패 |
| A08 | Software or Data Integrity Failures | 소프트웨어나 데이터 무결성 검증 실패 |
| A09 | Security Logging & Alerting Failures | 보안 로그와 경고 처리 부족 |
| A10 | Mishandling of Exceptional Conditions | 예외 상황 처리 실패 |
Broken Access Control
Broken Access Control은 사용자가 허용된 범위를 넘어 다른 사용자나 관리자 기능에 접근할 수 없는 문제입니다.
발생 예시
- 일반 사용자가 관리자 API를 호출할 수 있는 경우
- 다른 사용자의 주문 내역이나 게시글 수정 API에 접근할 수 있는 경우
- URL의 userId만 바꿔서 다른 사용자의 정보를 조회할 수 있는 경우
이를 예방하기 위해 서버에서 항상 인증된 사용자와 요청 대상 데이터의 소유자를 검증해야 합니다.
관리자 기능은 역할 기반 권한 검사를 적용해야 합니다. 클라이언트에서 버튼을 숨기는 것만으로 권한 제어를 끝내면 안됩니다.
Security Misconfiguration
Security Misconfiguration 서버, 프레임워크, 데이터베이스, 클라우드, 보안 헤더 등의 설정이 잘못되어 발생하는 취약점입니다.
발생 예시
- 운영 환경에서 디버그 모드가 켜져 있는 경우
- 불필요한 에러 스택 트레이스가 사용자에게 노출되는 경우
- CORS를 모든 Origin에 과도하게 허용하는 경우
- 기본 계정이나 기본 비밀번호를 그대로 사용하는 경우
이를 예방하기 위해 운영 환경과 개발 환경 설정을 분리해야 합니다. 불필요한 에러 메시지와 디버그 정보를 숨겨야 하며, CORS, 보안 헤더, 서버 포트, 관리자 접근 경로 등을 명확하게 제한해야 합니다.
Software Supply Chain Failures
Software Supply Chain Failures는 애플리케이션이 사용하는 외부 라이브러리, 의존성, 빌드 도구, 배포 과정에서 발생할 수 있는 보안 위험입니다.
발생 예시
- 취약점이 있는 오래된 라이브러리를 계속 사용하는 경우
- 출처가 불분명한 패키지를 설치하는 경우
- CI/CD 환경의 토큰이나 시크릿 키가 노출되는 경우
- 빌드 과정에서 악성 코드가 포함되는 경우
이를 예방하기 위해 의존성 버전을 주기적으로 점검해야 합니다. 또한 Gradle, npm 등의 패키지 취약점 경고를 확인해야 합니다.
환경 변수, API Key, 토큰을 GitHub에 올리지 않으며 신뢰할 수 있는 저장소와 패키지를 사용해야 합니다.
Cryptographic Failures
Cryptographic Failures는 민감한 데이터를 적절하게 암호화하거나 보호하지 못해 발생하는 문제입니다.
발생 예시
- 비밀번호를 평문으로 저장하는 경우
- HTTPS를 적용하지 않아 로그인 정보가 평문으로 전송되는 경우
- 취약한 해시 알고리즘을 사용하는 경우
- 개인정보나 토큰을 안전하지 않게 저장하는 경우
이를 예방하기 위해 비밀번호는 bcrypt, scrypt, Argon2 같은 비밀번호 저장용 알고리즘을 사용해야 합니다. 민감한 통신에는 HTTPS를 적용해야 합니다. 또한 API Key와 JWT secret은 코드에 직접 작성하지 않고 환경 변수를 관리해야 합니다.
앞에서 살펴본 해시 알고리즘과 HTTPS는 Cryptographic Failures를 줄이기 위한 대표적인 보안 요소라고 볼 수 있습니다.
Injection
Injection은 사용자의 입력값이 명령어나 쿼리의 일부로 해석되어 의도하지 않은 동작을 일으키는 취약점입니다.
발생 예시
- SQL Injection
- Command Injection
- XSS
- NoSQL Injection
이를 예방하기 위해 사용자 입력값을 SQL 문자열에 직접 붙이지 않으며 Prepared Statement, JPA, Query Parameter Binding을 사용해야 합니다. 또한 입력값 검증과 출력값 이스케이프 처리를 적용해야 합니다.
Insecure Design
Insecure Design은 구현 실수보다는 설계 단계에서 보안 요구사항을 충분히 고려하지 않아 발생하는 문제입니다.
발생 예시
- 비밀번호 재설정 기능에서 본인 확인 절차가 부족한 경우
- 결제나 예약 기능에서 중복 요청 방지 설계가 없는 경우
- 권한 모델을 설계하지 않고 API를 먼저 구현하는 경우
이를 예방하기 위해서는 기능 구현 전에 어떤 사용자가 어떤 데이터에 접근할 수 있는지 정의, 중요 기능에는 악용 가능성을 먼저 생각해야 합니다. 또한 요구사항 단계에서 보안 조건을 함께 작성해야 합니다.
Authentication Failures
Authentication Failures는 사용자가 누구인지 확인하는 인증 과정이 부실할 때 발생하는 문제입니다.
발생 예시
- 약한 비밀번호 정책
- 로그인 실패 횟수 제한 없음
- JWT 만료 시간 관리 부실
- 토큰 검증 누락
- 비밀번호 재설정 일크를 안전하지 않게 처리하는 경우
이를 예방하기 위해 비밀번호는 안전하게 해시하여 저장, JWT의 만료 시간과 서명을 검증, 로그인 실패 시 과도한 시도를 제한하며 민감한 기능에는 추가 인증 절차를 고려할 수 있습니다.
Software or Data Integrity Failures
Software or Data Integrity Failures는 소프트웨어나 데이터가 신뢰할 수 있는 상태인지 검증하지 않아 발생하는 문제입니다.
발생 예시
- 검증되지 않은 업데이트 파일을 적용하는 경우
- 외부에서 받은 데이터를 신뢰하고 그대로 처리하는 경우
- 무결성 검증 없이 중요한 데이터를 반영하는 경우
이를 예방하기 위해 외부 데이터는 항상 검증, 파일 업로드나 외부 API 응답은 신뢰 경계를 기준으로 검증해야 하며 배포 파일이나 의존성의 무결성을 확인할 수 있는 절차를 고려해야 합니다.
Security Logging & Alerting Failures
Security Logging & Alerting Failures는 보안상 중요한 이벤트를 기록하지 않거나, 이상 징후를 감지하지 못하는 문제입니다.
발생 예시
- 로그인 실패가 반복되어 기록되어도 기록하지 않는 경우
- 관리자 기능 호출 기록이 없는 경우
- 권한 없는 접근 시도를 모니터링하지 않는 경우
이를 예방하기 위해 로그인 실패, 권한 거부, 관리자 API 호출, 토큰 검증 실패 같은 이벤트는 로그로 남겨야 합니다. 또한 민감한 정보느 로그에 남기지 않아야 하며, 반복적인 실패나 비정상 요청은 경고 대상으로 관리해야 합니다.
Mishandling of Exceptional Conditions
Mishandling of Exceptional Conditions는 예외 상황을 잘못 처리해 보안 정보가 노출되거나 시스템이 예측하지 못한 상태로 동작하는 문제입니다.
발생 예시
- 예외 발생 시 내부 스택 트레이스가 사용자에게 그대로 노출되는 경우
- 인증 실패와 사용자 없음을 너무 상세하게 구분해 공격자에게 힌트를 주는 경우
- 예외 처리 누락으로 서버 오류가 반복 발생하는 경우
이를 예방하기 위해서는 사용자에게는 일반화된 에러 메시지를 제공, 내부 예외 정보는 서버 로그에만 남겨야 하며 전역 예외 처리기를 사용해 일관된 에러 응답을 내려야 합니다.
백엔드 개발자가 점검해야 할 보인 체크리스트
- API마다 인증과 인가가 필요한지 확인했는가?
- 관리자 API는 일반 사용자가 호출할 수 없도록 제한했는가?
- 비밀번호는 평문이 아니라 안전한 해시로 저장했는가?
- JWT Secret, DB password, API key를 코드에 직접 작성하지 않았는가?
- 사용자 입력값을 검증하고 있는가?
- SQL 문자열을 직접 조립하지 않는가?
- 운영 환경에서 디버그 정보가 노출되지 않는가?
- CORS를 과도하게 열어두지 않았는가?
- 보안상 중요한 이벤트를 로그로 남기고 있는가?
- 예외 응답에 내부 서버 정보가 노출되지 않는가?
오늘은 OWASP Top 10을 기준으로 주요 웹 보안 취약점에 대해 알아보았습니다. OWASP Top 10은 웹 애플리케이션에서 자주 발생하는 보안 위험을 정리한 기준으로 개발자가 우선적으로 점검행야 할 항목들을 이해하는데 도움이 됩니다.
다음 시간에는 콘텐츠 보안 정책(CSP)에 대해 알아보겠습니다. 수고하셨습니다.
'백엔드 공부' 카테고리의 다른 글
| 테스트(1) - 단위 테스트, 통합 테스트, 기능 테스트 (1) | 2026.05.14 |
|---|---|
| 웹 보안 지식(6) - 콘텐츠 보안 정책 (0) | 2026.05.13 |
| 웹 보안 지식(4) - CORS (0) | 2026.05.11 |
| 웹 보안 지식(3) - HTTPS와 SSL/TLS의 동작 원리 (0) | 2026.05.08 |
| 웹 보안 지식(2) - 해시 알고리즘 (0) | 2026.05.07 |