OWASP Top 10이란?
개발자가 금요일 오후에 코드를 푸시합니다. 월요일이 되자 공격자가 API 파라미터를 조작해 고객 기록에 접근하고, 단순한 권한 확인만으로 막을 수 있었던 접근 제어 취약점을 통해 데이터를 유출합니다. OWASP Top 10은 이러한 취약점을 방지하기 위해 존재합니다.
OWASP 재단은 OWASP Top 10을 "개발자와 웹 애플리케이션 보안을 위한 표준 인식 문서"로 정의합니다. 이는 웹 애플리케이션에서 가장 중요한 보안 위험에 대한 폭넓은 합의를 나타냅니다. 이 목록은 여러 차례 개정되었으며, 2025년판에서는 애플리케이션 보안 환경의 변화를 반영한 구조적 변화가 도입되었습니다.
NIST와 MITRE CWE 콘텐츠 팀은 자체 프레임워크에서 OWASP Top 10 카테고리를 공식적으로 참조합니다. 보안 프로그램을 운영하거나 애플리케이션을 개발하거나 취약점 대응을 관리하는 경우, OWASP Top 10은 이해관계자가 기대하는 최소 기준입니다. 다음은 최신 판에서 다루는 내용과 각 카테고리가 환경에 어떻게 적용되는지에 대한 설명입니다.
2025 OWASP Top 10 카테고리
2025년판에서는 실제 데이터를 기반으로 우선순위가 재조정되었습니다. 아래는 현재 순위와 보안 프로그램에 중요한 변화 사항을 포함한 10개 카테고리입니다.
A01: Broken Access Control
여전히 최상위 카테고리로, 테스트된 애플리케이션의 3.73%에서 관련 결함이 최소 1개 이상 발견되었습니다. Broken access control은 사용자가 의도된 권한을 벗어나 행동할 수 있도록 허용합니다. 예를 들어, URL 파라미터를 수정해 다른 사용자의 기록을 조회하거나, JWT 토큰 조작을 통한 권한 상승, 기능 수준 제한 우회 등이 있습니다. 이 카테고리는 insecure direct object references (IDOR), 누락된 접근 제어, CORS 오구성 등을 포함합니다. 이전에 별도 카테고리였던 SSRF도 여기에 통합되었습니다.
A02: Security Misconfiguration
2021년 #5에서 상승했으며, 현대 애플리케이션 동작이 코드보다 구성에 더 많이 의존함을 반영합니다. 이 카테고리는 변경되지 않은 기본 자격 증명, 불필요하게 노출된 서비스, 스택 트레이스를 노출하는 상세 오류 메시지, 누락된 보안 헤더 등을 포함합니다. 클라우드 환경과 컨테이너화된 배포는 각 서비스, API 게이트웨이, Kubernetes 클러스터마다 별도의 구성 표면을 추가해 위험을 증폭시킵니다.
A03: Software Supply Chain Failures
2025년판에서 가장 주목할 만한 구조적 변화입니다. 이전에는 "취약하거나 오래된 구성요소"에 국한되었으나, 이제는 소프트웨어 종속성, 빌드 시스템, 배포 인프라 전체를 포괄합니다. 공격자는 애플리케이션 코드 자체보다 CI/CD 파이프라인, 개발 도구, 컨테이너 레지스트리, 널리 사용되는 오픈소스 패키지를 점점 더 많이 노립니다. 데이터상 발생 빈도는 적지만, 이 카테고리는 2025년 데이터셋에서 평균 exploit 및 영향 점수가 가장 높습니다.
A04: Cryptographic Failures
"Sensitive Data Exposure"에서 이름이 변경되어 증상보다 근본 원인에 초점을 맞춥니다. 이 카테고리는 평문 전송 데이터, 사용 중단된 해시 함수(MD5, SHA1), 암호화 키로 사용되는 비밀번호, 불충분한 난수성 등을 포함합니다. 암호화 보호가 실패하면 공격자는 전송 중 자격 증명을 가로채거나 저장된 데이터를 복호화하거나 인증 토큰을 위조할 수 있습니다. 이름 변경은 데이터 노출 사건을 사후에 분류하는 대신, 노출 원인 해결에 중점을 둔 OWASP의 방향성을 반영합니다.
A05: Injection
Injection은 애플리케이션이 신뢰할 수 없는 입력을 적절한 검증이나 이스케이프 없이 인터프리터에 전달할 때 발생하며, 공격자가 의도하지 않은 명령을 실행할 수 있습니다. SQL injection, cross-site scripting (XSS), OS 명령어 인젝션, LDAP injection 등이 여기에 해당합니다. 2025년 순위에서 #3에서 #5로 하락했지만, 여전히 관련 CVE 수가 가장 많으며 입력 처리가 소홀할 경우 데이터 유출의 주요 원인입니다.
A06: Insecure Design
이 카테고리는 구현 버그가 아닌 아키텍처 및 설계 수준의 결함을 다룹니다. 약한 비밀번호 재설정 흐름, 비즈니스 워크플로우에서 누락된 권한 확인, 민감한 엔드포인트에 대한 속도 제한 부재 등은 모두 설계상의 결정이며, 근본적으로 안전하지 않은 설계는 아무리 안전하게 코딩해도 해결할 수 없습니다. OWASP는 위협 모델링, 안전한 설계 패턴, 코드 작성 전 보안 활동의 중요성을 강조하기 위해 이 카테고리를 도입했습니다. 2025년 #4에서 #6으로 하락한 것은 업계가 점차 개선되고 있음을 시사합니다.
A07: Identification and Authentication Failures
이 카테고리는 공격자가 사용자 신원을 탈취할 수 있는 취약점을 다룹니다. 예를 들어, 자격 증명 채우기, 약한 비밀번호에 대한 무차별 대입 공격, 누락된 multi-factor authentication (MFA), 예측 가능한 세션 토큰이나 부적절한 세션 무효화 등 세션 관리 결함이 있습니다. OWASP 분석에 따르면 표준화된 인증 프레임워크 사용이 발생률에 긍정적 영향을 미치고 있지만, 도난된 자격 증명은 여전히 침해의 가장 일반적인 초기 접근 벡터 중 하나입니다.
A08: Software or Data Integrity Failures
이 카테고리는 소프트웨어 업데이트, CI/CD 파이프라인, 데이터 직렬화에서 신뢰를 전제로 한 가정을 겨냥합니다. 애플리케이션이 서명 검증 없이 자동 업데이트를 하거나, 검증되지 않은 소스에서 종속성을 가져오거나, 검증 없이 신뢰할 수 없는 데이터를 역직렬화할 경우, 공격자는 전체 애플리케이션 권한으로 실행되는 malicious code를 주입할 수 있습니다. 또한, CI/CD 파이프라인 무결성도 포함되어, 빌드 단계가 손상되면 악성 아티팩트가 탐지되지 않은 채 운영 환경에 배포될 수 있습니다.
A09: Security Logging and Alerting Failures
"Security Logging and Monitoring Failures"에서 이름이 변경되었습니다. OWASP의 2025년 소개에 따르면, "모니터링" 대신 "Alerting"으로 변경된 이유는 "경고 없는 훌륭한 로깅은 보안 사고 식별에 거의 가치가 없다"는 점을 반영합니다. 로그 소스에 연동된 실질적인 경고가 없으면, 침해가 발생해도 증거는 저장소에 남아 있을 뿐 탐지되지 않습니다. 이 카테고리는 또한 로그 세부 정보 부족, 민감한 작업에 대한 audit trails 누락, 인증 또는 접근 제어 이벤트를 포착하지 못하는 로그도 포함합니다.
A10: Mishandling of Exceptional Conditions
2025년판에서 새롭게 추가된 카테고리로, 애플리케이션이 예기치 않은 입력, 자원 부족, 타임아웃, 내부 오류를 만났을 때 발생하는 상황을 다룹니다. 예외 처리가 미흡하면 상세 스택 트레이스를 통해 민감한 데이터가 노출되거나, fail-open 로직으로 보안 통제가 우회되거나, 서비스 거부 조건이 발생할 수 있습니다. OWASP는 이전에 "코드 품질" 이슈로 분산되어 있던 24개의 CWE를 이 카테고리로 통합하여, 안전하지 않게 실패하는 취약한 시스템이 별도의 위험군임을 강조합니다.
아래 표는 각 카테고리와 2025년판에서 변경된 사항을 요약합니다.
| # | Category | What changed in 2025 |
| A01 | Broken Access Control | 이전에는 별도 카테고리였던 SSRF가 포함됨 |
| A02 | Security Misconfiguration | 2021년 #5에서 상승 |
| A03 | Software Supply Chain Failures | "Vulnerable and Outdated Components"에서 전체 종속성 생태계로 확장 |
| A04 | Cryptographic Failures | #2에서 하락; 근본 원인 암호화 이슈에 계속 초점 |
| A05 | Injection | #3에서 #5로 하락; 여전히 가장 많이 테스트되는 카테고리 중 하나 |
| A06 | Insecure Design | #4에서 #6으로 하락; 업계의 위협 모델링 도입이 개선 중 |
| A07 | Authentication Failures | 위치 변동 없음; "Identification and Authentication Failures"에서 이름 소폭 변경 |
| A08 | Software or Data Integrity Failures | 위치 변동 없음 |
| A09 | Security Logging and Alerting Failures | 이름 변경; 운영상 필요를 반영해 "Alerting"이 "Monitoring"을 대체 |
| A10 | Mishandling of Exceptional Conditions | 신규 카테고리; 이전 SSRF 항목을 대체 |
이 카테고리들은 기준선을 정의합니다. 각 항목을 어떻게 해결할지 살펴보기 전에, 이러한 위험이 조직에 왜 중요한지 이해하는 것이 도움이 됩니다.
OWASP Top 10의 중요성
취약점 발견과 악용 사이의 간극이 계속 좁아지고 있으며, 웹 애플리케이션은 여전히 주요 진입점입니다. 조직에 있어 OWASP Top 10이 중요한 이유는 세 가지입니다.
- 위험 우선순위 지정. 모든 것을 동시에 해결할 수는 없습니다. Top 10은 이론적 심각성만이 아니라 악용 가능성과 영향에 따라 데이터 기반의 출발점을 제공합니다.
- 규제 준수 정렬. NIST CSF는 OWASP Top 10 변형과의 매핑을 유지합니다. 감사자나 규제 기관이 애플리케이션 보안 프로그램에 대해 질문할 때, OWASP Top 10은 공통 언어입니다.
- 재정적 현실. 접근 제어, 구성 오류, 인젝션에서의 보안 실패는 비용이 많이 드는 사고로 이어질 수 있습니다. OWASP Top 10은 운영 및 비즈니스에 영향을 줄 가능성이 가장 높은 취약점 유형에 팀의 집중을 유도합니다.
이러한 위험이 중요한 이유를 이해하는 것이 첫걸음입니다. 다음은 각 항목을 코드 및 구성 수준에서 어떻게 해결할지 아는 것입니다.
OWASP Top 10 취약점 예방 방법
각 OWASP Top 10 카테고리에는 팀이 직접 구현할 수 있는 구체적인 예방 조치가 있습니다.
- A01: Broken access control. 모든 엔드포인트에 대해 기본 거부(deny-by-default)를 적용합니다. 모든 요청마다 서버 측에서 권한을 검증하고, 코드베이스 전체에 일관되게 적용되는 단일 접근 제어 루틴으로 통합합니다. 디렉터리 목록을 비활성화하고 CORS 정책이 신뢰할 수 있는 도메인으로만 제한되도록 합니다.
- A02: Security misconfiguration. 기본 자격 증명을 제거하고, 사용하지 않는 서비스와 기능을 비활성화하며, 환경 전반에 걸쳐 구성 감사를 자동화합니다. 보안 헤더를 최신 상태로 유지하고, 오류 메시지는 스택 트레이스 대신 일반적인 응답만 반환하도록 합니다.
- A03: Software supply chain failures. 종속성을 특정 버전으로 고정하고, 암호화 서명이나 체크섬으로 무결성을 검증합니다. software bill of materials (SBOM)을 유지하고, CI/CD 플러그인 및 개발 도구를 감사하며, 종속성 트리 내 공개된 취약점에 대해 취약점 데이터베이스를 모니터링합니다.
- A04: Cryptographic failures. 최신 암호화 표준(TLS 1.2+, AES-256)을 사용하고, MD5 및 SHA1과 같은 사용 중단 알고리즘은 폐기합니다. 비밀번호는 bcrypt나 Argon2와 같은 적응형 hashing 함수로 저장합니다. 데이터 민감도에 따라 적절한 보호 수준을 적용할 수 있도록 분류합니다.
- A05: Injection. 모든 데이터베이스 작업에 대해 파라미터화된 쿼리를 사용합니다. 모든 사용자 입력을 검증 및 정제하고, 출력은 렌더링 컨텍스트(HTML, JavaScript, SQL)에 맞게 이스케이프합니다. XSS 영향을 줄이기 위해 콘텐츠 보안 정책을 적용합니다.
- A06: Insecure design. 코드 작성 전 위협 모델링을 수행하고, 기능 테스트와 함께 악용 사례 테스트를 마련하며, OWASP Proactive Controls의 안전한 설계 패턴을 적용합니다. 설계 결함은 운영 환경보다 아키텍처 단계에서 수정하는 것이 비용이 적게 듭니다.
- A07: Authentication failures. MFA를 적용하고, 로그인 시도 횟수 제한과 로그인 지연을 구현하며, 표준화된 인증 프레임워크를 사용합니다. 로그아웃 및 비밀번호 변경 시 세션을 적절히 무효화합니다.
- A08: Software or data integrity failures. 모든 빌드 아티팩트, 컨테이너 이미지, 소프트웨어 업데이트에 암호화 서명을 적용합니다. 역직렬화 입력을 검증하고, CI/CD 파이프라인의 쓰기 권한은 인가된 역할로만 제한합니다.
- A09: Security logging and alerting failures. 인증 실패, 접근 제어 위반, 권한 상승 시도에 대해 실질적인 경고 임계값을 구성합니다. 로그가 수집되는 것뿐만 아니라 실제 조건에서 경고가 발생하는지 테스트합니다.
- A10: Mishandling of exceptional conditions. 오류 발생 시 접근을 거부하는 안전한 실패 모드를 정의합니다. 사용자에게는 일반적인 오류 메시지만 반환하고, 내부적으로는 상세 진단 정보를 로깅합니다. null 값, 자원 고갈, 예기치 않은 입력 유형을 명시적으로 처리합니다.
카테고리별 예방은 기술적 해결책을 제공합니다. 이를 조직 전체에 확장하는 과정에서 구현상의 과제가 발생합니다.
OWASP Top 10 구현 시 도전과 일반적인 실수
수백 개의 애플리케이션, 수십 개의 개발팀, 지속적 배포 주기를 가진 운영 환경에서 OWASP Top 10을 실제로 적용하는 과정에서 구현이 무너집니다. 다음은 가장 큰 피해를 유발하는 패턴입니다.
- Top 10을 합격/불합격 체크리스트로 취급. OWASP는 Top 10을 인식 가이드로 명시하며, 보안 프로그램이 아니라고 설명합니다. 검증 수준의 테스트에는 OWASP ASVS를 권장합니다. 공급망만 다루는 경우 Top 10은 "가끔"만 충분하다고 평가됩니다.
- 분산된 접근 제어 구현. Proactive Controls 프로젝트는 코드베이스 곳곳에 여러 접근 제어 구현이 분산되는 것을 경고합니다. 하나의 결함 있는 구현만으로도 전체가 취약해질 수 있습니다.
- 기본 허용(permissive-by-default) 구성. REST API와 웹훅에 대해 기본 거부를 적용하지 않으면, 미처 다루지 않은 엔드포인트가 암묵적으로 접근 가능해집니다. 이는 클라우드 서비스, Kubernetes RBAC, API 게이트웨이 모두에 해당합니다.
- 대규모 권한 부여. 인증은 개선되고 있지만, 접근 제어는 그렇지 않습니다. 업계는 "누구인가?"는 해결하고 있지만, "무엇을 할 수 있어야 하는가?"는 API와 마이크로서비스 전반에서 여전히 어려움을 겪고 있습니다.
- 경고 없는 로깅. SIEM에 테라바이트 단위의 로그 데이터를 수집하더라도, 실질적인 경고 임계값이 구성되지 않으면, 증거는 저장소에 남아 있는 동안 사고는 탐지되지 않습니다.
- 열거 기반 스캐닝에만 의존. 열거 기반 도구는 이미 알고 있는 것만 찾을 수 있습니다. 논리적 결함, 새로운 오구성, 아키텍처적 약점은 시그니처 매칭만으로는 탐지할 수 없으며, 행위 분석이 필요합니다.
이러한 패턴은 보안 프로그램이 OWASP Top 10을 일회성 감사로 취급할 때 지속적으로 나타납니다.
OWASP Top 10 모범 사례
카테고리별 해결책을 넘어, 다음과 같은 프로그램 수준의 실천이 조직 전체에 OWASP Top 10을 적용하는 데 도움이 됩니다.
- 중앙 집중식 보안 통제 라이브러리 구축. 프로그램 가이드에 따라 인증, 권한 부여, 입력 검증, 암호화에 대한 공유 및 재사용 가능한 라이브러리를 정의합니다. 각 팀이 자체 구현을 만들면 불일치로 인해 취약점이 발생합니다.
- Proactive Controls를 개발 워크플로우에 매핑. Proactive Controls는 위험 중심의 Top 10을 보완하는 개발자 지향 가이드입니다. C1(Access Control)은 A01, C3(Input Validation)은 A05, C5(Secure Defaults)는 A02에 매핑됩니다. 개발자에게 회피해야 할 위험이 아니라, 구현해야 할 구체적 통제를 제공합니다.
- OWASP ASVS를 검증 기준선으로 사용. 임의의 침투 테스트 대신, 각 Top 10 카테고리에 매핑된 구조화된 ASVS 요구사항을 적용합니다. ASVS는 프로그램 통합을 위한 CSV 및 JSON 형식의 테스트 기준을 제공합니다.
- 규제 정렬을 위해 NIST SSDF와 통합. NIST SP 800-218은 OWASP ASVS, OWASP SAMM, OWASP SCVS를 상호 보완 프레임워크로 명시적으로 참조하며, 행정명령 14028 요구사항과 정렬됩니다.
이러한 실천은 프로그램의 기반을 만듭니다. 테스트는 예방 통제가 예상대로 작동하는지 검증합니다.
OWASP Top 10 테스트 방법
모든 카테고리를 포괄하는 단일 도구는 없습니다. 효과적인 OWASP Top 10 테스트는 정적 분석, 동적 테스트, 구성요소 분석을 결합해 코드, 런타임, 종속성 위험을 모두 다룹니다.
- 정적 애플리케이션 보안 테스트(SAST)는 배포 전 소스 코드를 스캔하여 인젝션 패턴, 암호화 취약점, 인증 결함을 탐지합니다. SAST는 개발 초기 단계에서 문제를 발견해 수정 비용을 최소화합니다.
- 동적 애플리케이션 보안 테스트(DAST)는 실행 중인 애플리케이션을 대상으로 접근 제어 결함, 오구성, 오류 처리 실패를 실제 공격 트래픽으로 테스트합니다. OWASP ZAP은 OWASP 커뮤니티가 유지하는 널리 사용되는 오픈소스 DAST 도구입니다.
- 소프트웨어 구성요소 분석(SCA)는 서드파티 라이브러리, 프레임워크, 컨테이너 이미지 내 알려진 취약점을 종속성 트리와 공개 취약점 데이터베이스를 대조해 식별합니다.
- 침투 테스트는 자동화 도구가 놓치는 논리적 결함과 아키텍처적 약점을 실제 환경에서 검증합니다. 침투 테스트 결과를 ASVS 요구사항에 매핑해 구조화된 검증을 수행합니다.
아래 표는 각 테스트 방법이 가장 직접적으로 다루는 OWASP Top 10 카테고리를 매핑한 것입니다.
Method | Categories covered | Best used |
SAST | A04, A05, A07 | 개발 중, 코드 병합 전 |
| DAST | A01, A02, A10 | 스테이징 또는 운영 환경에서 실행 중인 애플리케이션 대상 |
| SCA | A03, A08 | 빌드 시 및 모든 종속성 업데이트 시 |
| Penetration testing | 모든 10개 카테고리 | 주기적 검증, 주요 릴리즈 이후 |
이 방법들을 결합하면 OWASP Top 10의 모든 카테고리를 포괄할 수 있습니다. 자율화된 도구는 탐지와 대응 속도 간의 실행 격차를 해소합니다.
핵심 요약
OWASP Top 10은 웹 애플리케이션 보안 위험에 대한 업계 표준 인식 프레임워크로, 2025년에는 공급망 범위가 확장되고 로깅과 함께 경고에 대한 강조가 추가되었습니다. Broken Access Control이 여전히 최상위 카테고리입니다. 각 카테고리에는 deny-by-default 접근 제어부터 암호화 아티팩트 검증까지 구체적이고 실행 가능한 예방 조치가 있습니다.
효과적인 구현을 위해서는 중앙 집중식 보안 통제, SAST, DAST, SCA를 통한 계층적 테스트, 그리고 악용 속도와 대응 속도 간의 격차를 해소하는 자율적 조사가 필요합니다.
자주 묻는 질문
OWASP Top 10은 OWASP Foundation에서 발행하는 표준 인식 문서로, 웹 애플리케이션에 대한 가장 중요한 보안 위험을 식별합니다.
실제 취약점 데이터와 커뮤니티 설문조사를 기반으로, 이 목록은 개발자, 보안팀, 감사자가 애플리케이션 보안 프로그램의 기준선으로 사용하는 합의 기반 순위를 제공합니다. 최신 버전은 2025년에 공개되었습니다.
OWASP Top 10은 고정된 릴리스 일정이 없습니다. 충분한 새로운 취약점 데이터와 커뮤니티 의견이 모여야 개정된 순위가 발표됩니다.
이전 버전은 2013년, 2017년, 2021년, 2025년에 공개되었습니다. 각 업데이트는 실제 악용 패턴의 변화, 애플리케이션 아키텍처의 변화, 새로운 데이터 수집 방법론을 반영하며, 이론적 위험 예측에만 근거하지 않습니다.
Top 10은 웹 애플리케이션의 가장 중요한 위험 카테고리를 강조하기 위한 인식 문서입니다. ASVS(Application Security Verification Standard)는 세 가지 보증 수준에서 구조화되고 테스트 가능한 검증 요구사항을 제공하여 보안 테스트 및 코드 리뷰에 적합합니다.
OWASP는 설계 검토 및 보안 평가에 ASVS 사용을 권장하며, Top 10은 입문용, ASVS는 검증 프레임워크로 위치시킵니다.
웹 애플리케이션 Top 10은 API와 관련된 카테고리, 특히 Broken Access Control(A01)과 Injection(A05)을 포함합니다. 그러나 OWASP는 API 권한 부여, 속도 제한, 객체 수준 접근 제어와 같은 API에 특화된 카테고리로 구성된 별도의 API Security Top 10을 유지하고 있습니다.
여러 주요 API 위험은 A01과 유사한 권한 부여 실패와 직접적으로 관련되어 있습니다. API 노출이 많은 조직은 두 목록 모두를 참고하여 적절한 보안을 확보해야 합니다.
2025년 방법론은 분석된 데이터셋을 확장하고, 미래 지향적 위험을 위한 OWASP 커뮤니티 설문조사 요소와 함께 더 넓은 데이터 기여 주기를 도입했습니다.
가중치 공식은 여전히 악용 가능성과 기술적 영향을 균형 있게 반영하면서 더 넓은 취약점 집합을 반영했습니다. 이러한 방법론적 확장은 단순한 위협 패턴 변화가 아니라 여러 순위 변동의 원인이 되었으며, 여기에는 보안 구성 오류의 상승과 예외 조건 처리 미흡이 새로운 범주로 추가된 것이 포함됩니다.
아니요. OWASP는 Top 10이 인식 및 입문 수준의 교육 도구임을 명확히 밝히고 있습니다. 공급망 보안만을 기준으로 할 때도 Top 10은 "가끔만" 충분하다고 평가됩니다.
완전한 프로그램에는 검증을 위한 OWASP ASVS, 성숙도 평가를 위한 OWASP SAMM, SDLC 통합을 위한 NIST SSDF, 그리고 Top 10이 다루지 않는 위험을 보완하기 위한 지속적인 런타임 보호가 포함되어야 합니다.
