이 글에서 얻는 것
- OWASP Top 10을 “암기 리스트”가 아니라, 백엔드 보안 점검의 프레임으로 사용할 수 있습니다.
- 서비스에서 가장 자주 터지는 취약점이 “코드 한 줄”이 아니라 설계/운영/의존성에서 온다는 감각을 얻습니다.
- 스프링/백엔드 관점에서 각 항목을 어떻게 점검하고, 무엇부터 고정하면 좋은지 기준이 생깁니다.
0) OWASP Top 10은 “우선순위 힌트”다
OWASP Top 10은 전 세계적으로 자주 관측되는 취약점 범주를 정리한 것입니다. 내 서비스의 위협 모델과 완전히 같을 수는 없지만, “점검 순서”를 잡는 데 매우 유용합니다.
좋은 사용법:
- Top 10을 기준으로 “우리 서비스에서 해당 위험이 어디에 있는지”를 찾는다
- 위험이 큰 영역부터(인증/인가/데이터) 보안 베이스라인을 고정한다
- 자동화(스캔/정책)로 실수를 줄인다
1) A01 Broken Access Control(인가 실패)
가장 흔하고, 가장 치명적입니다.
실무에서 자주 터지는 형태:
- 다른 사용자의 리소스를 조회/수정(IDOR, 수평 권한)
- 관리자 기능이 일반 사용자에게 노출(수직 권한)
기본 대책:
- “리소스 소유자/테넌트” 검증을 서버에서 강제(클라이언트 주장 믿지 않기)
- 최소 권한 원칙(Role/Scope)
- 중요 엔드포인트는 보안 테스트 케이스로 고정
2) A02 Cryptographic Failures(암호화 실패)
암호화는 “알고리즘 선택”보다 “키/운영”에서 자주 무너집니다.
기본 대책:
- 전송: HTTPS/TLS 강제(HSTS 포함)
- 저장: 민감 데이터 암호화(필요한 경우), 비밀번호는 강한 해시(BCrypt/Argon2)
- 키 관리: 소스/이미지에 키를 넣지 않고 Secret Manager/Vault로 주입 + 회전
3) A03 Injection(인젝션)
SQL만이 아니라, LDAP/OS command/JSONPath 등 “입력이 명령/쿼리로 해석되는 곳”이 모두 대상입니다.
기본 대책:
- 파라미터 바인딩(Prepared Statement), ORM/쿼리 빌더 사용
- 입력 검증(allow-list)과 인코딩(출력 컨텍스트별)
- 동적 쿼리 조립/문자열 템플릿은 최소화
4) A04 Insecure Design(설계 취약)
“구현은 맞는데 설계가 위험한” 케이스입니다.
예:
- 레이트리밋/브루트포스 방어가 없다
- 중요한 동작(결제/권한 변경)에 재인증/추가 검증이 없다
대책:
- 위협 모델링(간단한 것부터)
- “보안 요구사항”을 기능 요구사항만큼 명시
- abuse case(악용 시나리오)를 테스트/운영 정책으로 반영
5) A05 Security Misconfiguration(설정 실수)
운영에서 가장 자주 발생하는 사고 중 하나입니다.
예:
- 디버그/액추에이터/문서 UI가 외부에 노출
- 기본 계정/기본 설정 방치
- CORS/헤더 정책이 과하게 열림
대책:
- 환경별 설정 분리(dev/prod)
- “외부 노출”은 네트워크/인증으로 강제
- 안전한 기본값(secure defaults)으로 시작
6) A06 Vulnerable and Outdated Components(취약한 의존성)
코드를 잘 짜도, 의존성이 취약하면 사고가 납니다.
대책:
- 의존성 스캔(SCA) + 자동 업데이트(Dependabot 등)
- SBOM 생성/관리(조직 규모가 커지면 필수로 가는 경향)
- 런타임 이미지(베이스 이미지) 취약점 스캔
7) A07 Identification & Authentication Failures(인증 실패)
인증은 “로그인”만이 아니라 세션/토큰 운영까지 포함합니다.
대책:
- 비밀번호 정책/계정 잠금/레이트리밋
- 세션/토큰 만료/회수(Refresh token rotation 등)
- 401/403 분리, MFA 옵션(서비스 성격에 따라)
8) A08 Software and Data Integrity Failures(무결성 실패)
CI/CD/배포/업데이트에서 무결성이 깨지는 문제입니다.
대책:
- 아티팩트/이미지 서명 검증, 공급망 보호
- CI에서 검증된 아티팩트만 배포
- 외부에서 받아 실행하는 스크립트/플러그인 신뢰성 점검
9) A09 Security Logging and Monitoring Failures(로깅/모니터링 실패)
침해는 “막는 것”만큼 “빨리 알아차리는 것”이 중요합니다.
대책:
- 인증 실패/권한 실패/민감 동작에 대한 보안 이벤트 로그
- 알람/온콜/런북(대응 절차)
- 로그에 PII/시크릿이 남지 않게(마스킹/정책)
10) A10 SSRF(Server-Side Request Forgery)
서버가 외부 URL을 호출해주는 기능(프록시/미리보기/웹훅)이 있으면 위험이 생깁니다.
대책:
- URL allow-list(도메인/스킴/포트), 내부망 메타데이터 IP 차단
- 타임아웃/리다이렉트 제한
- egress 네트워크 정책으로 “갈 수 있는 곳” 자체를 제한
11) 실무 적용 루틴(추천)
- 인증/인가 경계부터 점검(A01/A07)
- 설정/노출을 닫기(A05)
- 의존성/배포 무결성 자동화(A06/A08)
- 로깅/알람으로 탐지 능력 확보(A09)
- 마지막으로 설계 취약/SSRF 같은 특수 케이스를 기능 단위로 점검(A04/A10)
연습(추천)
- 내 서비스의 “민감 기능 5개”를 뽑고(A01/A07), 권한/인증 실패 테스트 케이스를 작성해보기
- 운영에서 노출되면 안 되는 엔드포인트(Actuator/Swagger 등)를 목록화하고, 네트워크/인증으로 막아보기
- 의존성 스캔(Dependabot/SCA)을 켜고, 한 번 취약점 업데이트를 처리해보며 운영 루프를 만들어보기
💬 댓글