[정보보안] OWASP Top 10 2025

OWASP TOP 10 2025
전반적으로 OWASP TOP 10 2025은 두 축의 변화가 뚜렷해요. 하나는 공급망·설정처럼 애플리케이션 외부·주변 환경의 위험이 부상한 것이고, 다른 하나는 증상보다 근본 원인으로 카테고리를 재편한 것입니다. OWASP TOP 10 2025에 대해서 간단히 알아보겠습니다.

  1. A01 접근 통제 실패 (Broken Access Control):
    “누가 무엇에 접근할 수 있는가”를 제대로 강제하지 못하는 문제입니다. IDOR(Insecure Direct Object Reference)과 권한 상승이 핵심 사례이고, 이번 판에서 SSRF가 이 카테고리로 통합됐어요. 40개의 CWE를 포함해 가장 많은 약점을 아우르며, 평균 3.73%의 애플리케이션에서 하나 이상 발견됐습니다. 2025판에서는 API 환경에서 자주 악용되는 BOLA(객체 수준 인가 실패)·BFLA(기능 수준 인가 실패)를 명시적으로 포함한 게 특징이에요. 방어의 근본은 서버 측에서 매 요청마다 권한을 검증하고 “기본 거부(deny by default)” 정책을 쓰는 것입니다.
  2. A02 보안 설정 오류 (Security Misconfiguration):
    기본 계정 방치, 불필요한 서비스 활성화, 잘못된 권한, 누락된 보안 헤더 등 “코드는 멀쩡한데 설정이 틀린” 문제입니다. 애플리케이션 동작이 점점 설정 기반으로 늘어나면서 이 사이클에서 더 흔해졌고, 5위에서 2위로 뛰었어요. XXE(XML External Entity, CWE-611)가 이 카테고리에 속합니다. XML 파서를 안전하게 설정하지 않은 게 근본 원인이라는 관점이죠.
  3. A03 소프트웨어 공급망 실패 (Software Supply Chain Failures) — 신규:
    2021년의 “A06 취약하고 오래된 컴포넌트(Vulnerable and Outdated Components)”를 확장해, 의존성·빌드 시스템·배포 인프라 전반의 침해를 포괄합니다. 단순히 오래된 라이브러리를 쓰는 것을 넘어, npm/PyPI 같은 패키지 저장소 오염, CI/CD 파이프라인 탈취, 빌드 도구 변조 등을 포함해요. 데이터상 발생 건수는 가장 적지만 CVE 기준 익스플로잇·영향 점수는 가장 높고, 커뮤니티 설문에서 압도적으로 우선순위로 뽑혔습니다. SolarWinds나 xz 백도어 사건이 이 계열의 대표 사례예요.
  4. A04 암호화 실패 (Cryptographic Failures):
    암호화를 안 하거나, 약한 알고리즘을 쓰거나, 키를 잘못 관리해서 민감 데이터가 노출되는 문제입니다. 평문 저장, 오래된 해시(MD5/SHA1), 하드코딩된 키 등이 전형적이죠. 2위에서 4위로 내려왔지만, 여전히 민감 데이터 노출이나 시스템 침해로 직결되는 경우가 많습니다. “데이터가 노출됐다”는 증상보다 “암호화를 제대로 안 했다”는 근본 원인에 초점을 둔 명칭이에요.
  5. A05 주입 (Injection):
    신뢰할 수 없는 입력이 명령어나 쿼리로 해석되는 고전적 취약점입니다. SQL 인젝션(저빈도·고영향)부터 XSS(고빈도·저영향)까지 아우르며, 가장 많이 테스트되고 가장 많은 CVE가 연결된 카테고리예요. SAST(Static Application Security Testing, 정적 분석)/DAST(Dynamic Application Security Testing, 동적 분석)가 상대적으로 잘 잡는 계열입니다. 3위에서 5위로 내려왔지만, 방어가 정착됐다기보다 다른 항목이 부상한 상대적 이동으로 보는 게 맞아요. 방어는 파라미터화된 쿼리와 입력 검증·이스케이핑 등이 있습니다.
  6. A06 안전하지 않은 설계 (Insecure Design):
    구현 버그가 아니라 설계 단계의 결함입니다. 코드를 아무리 잘 짜도 애초에 위협 모델링이 안 된 아키텍처는 안전할 수 없다는 개념으로, 2021년에 신설됐어요. 4위에서 6위로 내려왔는데, 이는 위협 모델링과 보안 설계에 대한 업계의 실질적 개선이 반영된 결과라고 OWASP는 봅니다. 코딩으로 사후에 못 고치고 설계 단계에서 막아야 한다는 점에서 다른 항목과 성격이 다릅니다.
  7. A07 인증 실패 (Authentication Failures):
    2021년 “A07 식별 및 인증 실패(Identification and Authentication Failures)”에서 이름이 간소화됐어요. 취약한 비밀번호 정책, 세션 관리 미흡, 무차별 대입 방어 부재, 다단계 인증 미적용 등이 해당합니다. 7위를 유지했는데, 표준화된 인증 프레임워크 사용이 늘면서 발생률에 긍정적 효과가 나타나고 있다고 평가됩니다. 직접 구현하지 말고 검증된 라이브러리·프로토콜(OAuth, OIDC 등)을 쓰라는 게 핵심 교훈이에요.
  8. A08 소프트웨어·데이터 무결성 실패 (Software or Data Integrity Failures):
    서명 검증 없이 업데이트를 적용하거나, 신뢰할 수 없는 소스에서 역직렬화(deserialization)하는 등 무결성을 검증하지 않는 문제입니다. 8위를 유지했고, A03(공급망)보다 더 낮은 수준에서 소프트웨어·코드·데이터 아티팩트의 무결성과 신뢰 경계를 다룹니다. 공급망 실패와 겹쳐 보이지만, A03이 생태계 전반의 문제라면 A08은 애플리케이션이 데이터/코드를 받아들이는 지점의 검증 실패에 가까워요.
  9. A09 보안 로깅·알림 실패 (Security Logging & Alerting Failures):
    2021년 “A09 보안 로깅 및 모니터링 실패(Security Logging and Monitoring Failures)”에서 “로깅 및 알림”으로 이름이 바뀌었습니다. 공격을 탐지·대응할 기록이 없거나, 있어도 알림으로 이어지지 않는 문제예요. 로깅만 잘 되고 알림이 없으면 보안 사고 식별에 거의 가치가 없다는 점을 강조하려는 개명입니다. 이 항목은 데이터로는 늘 과소 대표되기 때문에 커뮤니티 설문을 통해 순위에 올랐어요. 자동화 도구로 잡기 어려운 대표적 항목이죠. Zabbix 같은 모니터링·알림 체계가 바로 이 영역의 방어와 맞닿아 있습니다
  10. A10 예외 조건의 잘못된 처리 (Mishandling of Exceptional Conditions) — 신규:
    4개 CWE로 구성된 신규 카테고리로, 부적절한 오류 처리, 논리 오류, “실패 시 열림(failing open)” 등 시스템이 비정상 조건을 만났을 때 발생하는 시나리오에 초점을 둡니다. 예를 들어 인증 로직에서 예외가 발생했을 때 안전하게 차단(fail closed)하지 않고 통과시켜 버리는 경우, 오류 메시지에 민감 정보(스택 트레이스, 내부 경로)를 노출하는 경우 등이 해당해요. 앞서 XXE를 이 카테고리로 분류한 자료가 있었는데, OWASP 공식 분류상 XXE는 A02(설정 오류)에 가깝고, A10은 오류·예외 처리 자체의 결함을 다루는 별개 범주라는 점을 다시 확인할 수 있습니다.

You may also like...

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다