OWASP Top 10 완전해설: 웹 애플리케이션 보안의 핵심을 한눈에 보는 가이드
웹 보안에서 가장 중요한 리스트, OWASP Top 10이란?
웹 애플리케이션이 현대 비즈니스의 중앙 인프라로 자리잡은 오늘날, 사이버 공격의 빈도와 정교함은 날로 높아지고 있습니다. 이런 상황에서 "우리 서비스가 어떤 보안 위험에 노출되어 있는지" 체계적으로 점검하는 기준이 필요합니다.
그것이 바로 OWASP Top 10입니다.
OWASP(Open Web Application Security Project)는 웹 애플리케이션 보안을 전문으로 하는 국제 비영리 단체로, 전 세계 보안 전문가들의 실제 데이터와 현장 경험을 기반으로 "가장 위험한 웹 보안 취약점 10가지" 를 정기적으로 발표합니다. 이 목록은 현재 2021년 버전이 공식 최신이며, 2025년 갱신 작업이 진행 중입니다.
이 글에서는 OWASP Top 10의 각 항목을 취약점의 본질 → 실제 공격 시나리오 → 대응 방안 순으로 분석하겠습니다.
OWASP Top 10 2021 전체 목록 한눈에 보기
| 순위 | 카테고리 | 핵심 키워드 |
| A01 | Broken Access Control | 접근 권한 오남용 |
| A02 | Cryptographic Failures | 암호화 실패 |
| A03 | Injection | 주입 공격 (SQL, XSS 등) |
| A04 | Insecure Design | 불안전한 설계 |
| A05 | Security Misconfiguration | 잘못된 보안 설정 |
| A06 | Vulnerable & Outdated Components | 취약한 외부 컴포넌트 |
| A07 | Identification & Authentication Failures | 인증·인식 오류 |
| A08 | Software & Data Integrity Failures | 소프트웨어 및 데이터 무결성 실패 |
| A09 | Security Logging & Monitoring Failures | 로깅·모니터링 실패 |
| A10 | Server-Side Request Forgery (SSRF) | 서버측 요청 위조 |
A01: Broken Access Control — 권한은 있는가? 올바른 권한인가?
무엇이 문제인가
접근 제어(Access Control)는 "누구가 무엇에 접근할 수 있는지"를 정의하는 보안의 기본 장치입니다. 이것이 제대로 작동하지 않으면, 일반 사용자가 관리자 페이지를 열거나, 다른 사람의 개인 정보를 조회하거나, 권한 없이 데이터를 수정할 수 있게 됩니다.
이 항목은 2021년에 1위로 올라온 가장 심각한 위험입니다.
공격 시나리오
예를 들어, 한 이메일마케팅 플랫폼의 고객 상세 페이지 URL이 다음과 같은 구조입니다:
https://example.com/customers/profile?id=1234공격자가 단순히 id=1234를 id=1235로 바꾸면, 다른 고객의 개인정보 — 이름, 주소, 결제 정보까지 — 이 그대로 노출됩니다. 이는 IDOR(Insecure Direct Object Reference) 공격의 대표적인 사례입니다.
대응 방안
서버 측에서 모든 요청마다 권한을 재검증하는 것이 핵심입니다. 클라이언트 측(프론트엔드)에서만 접근을 막는 것은 의미가 없습니다. 최소 권한 원칙(Principle of Least Privilege)을 철저히 적용하고, 접근 제어 정책을 단일 중앙 모듈로 관리하는 것이 좋습니다.
A02: Cryptographic Failures — 암호화했다고 안심하면 안 된다
무엇이 문제인가
암호화 자체가 있더라도, 잘못된 암호화 알고리즘, 키 관리 실패, 전송 구간의 암호화 미적용 등으로 인해 민감 데이터가 유출될 수 있습니다. 이전에는 "민감한 데이터 노출"이라는 이름으로 불렀지만, 2021년에는 근본 원인인 암호화 실패 자체로 명명이 바뀌었습니다.
공격 시나리오
금융 서비스 앱이 사용자의 신용카드 번호를 저장할 때, MD5나 SHA-1 같은 오래된 해시 알고리즘으로 암호화한 경우입니다. 이 알고리즘들은 현재 역해독(Reverse Engineering)이 가능하여, 공격자가 원본 카드 번호를 복원할 수 있습니다.
또는 HTTPS가 아닌 HTTP로 로그인 정보를 전송하는 경우, 중간 경로에서 패킷을 스니핑하여 ID와 비밀번호를 그대로 탈취할 수 있습니다.
대응 방안
AES-256, TLS 1.2 이상의 강력한 암호화 프로토콜을 사용하고, 비밀번호는 bcrypt, Argon2 등의 전용 해싱 알고리즘으로 처리해야 합니다. 암호화 키는 별도의 키 관리 시스템(KMS)을 통해 안전하게 관리하는 것이 원칙입니다.
A03: Injection — 공격자의 "코드"가 우리 앱을 실행한다
무엇이 문제인가
Injection은 공격자가 의도하지 않은 코드나 명령을 우리 애플리케이션에 주입하여 실행시키는 공격입니다. SQL Injection, Command Injection, XSS(Cross-Site Scripting) 등이 이 카테고리에 속합니다. 2017년에는 1위였고, 2021년에는 3위로 내려왔지만 여전히 가장 빈번한 공격 유형 중 하나입니다.
공격 시나리오
로그인 폼의 사용자명 필드에 다음과 같은 값을 입력합니다:
' OR '1'='1' --백엔드에서 이 값을 적절히 검증하지 않고 SQL 쿼리에 그대로 삽입하면, 쿼리의 논리가 왜곡되어 모든 사용자의 계정을 우회할 수 있습니다. 심한 경우 테이블 삭제(DROP TABLE)까지 가능합니다.
대응 방안
매개변수화된 쿼리(Parameterized Query) 또는 ORM(Object-Relational Mapping) 을 사용하여 사용자 입력과 SQL 구문을 분리하는 것이 가장 효과적입니다. 모든 입력값에 대해 유효성 검사와 이스케이프 처리를 수행해야 합니다.
A04: Insecure Design — 보안은 "추가 옵션"이 아니라 "설계의 일부"
무엇이 문제인가
이 항목은 2021년에 새로 추가된 카테고리입니다. 단순한 구현 오류가 아니라, 보안을 처음부터 고려하지 않은 아키텍처와 설계 자체의 문제를 다루고 있습니다. 아무리 코드를 잘 작성해도, 설계 단계에서 보안적 사고가 빠진 시스템은 근본적으로 취약합니다.
공격 시나리오
이메일 회사의 비밀번호 재설정 기능에서, 재설정 코드를 생성했지만 사용 횟수 제한이 없고 만료 시간도 없었습니다. 공격자는 이 코드를 무제한 시도하여 대상 계정의 비밀번호를 강제 변경할 수 있었습니다. 이것은 구현 버그가 아니라, 비즈니스 로직 자체의 설계 실수입니다.
대응 방안
Secure by Design 원칙을 따라, 보안 요구사항을 프로젝트 기획 단계부터 반영해야 합니다. 위험 모델링(Threat Modeling)을 수행하고, OWASP의 Security Champions 프로그램 등을 활용하여 개발팀 전반에 보안 인식을 높이는 것이 중요합니다.
A05: Security Misconfiguration — "설정했다"는 것과 "올바르게 설정했다"는 것은 다르다
무엇이 문제인가
클라우드, 웹 서버, 앱서버, 데이터베이스 등 모든 인프라에 기본 설정값이 있습니다. 이 기본값을 그대로 사용하거나, 불필요한 기능을 끄지 않고 두면 공격자에게 열린 문이 됩니다.
공격 시나리오
AWS S3 버킷을 생성했을 때, 공개 접근(Public Access) 옵션을 비활성화하지 않아 전 세계 누구든 버킷 안의 파일을 다운로드할 수 있게 되었습니다. 이런 유형의 설정 오류로 인한 대형 데이터 유출 사건은 실제로 여러 건 기록되어 있습니다.
대응 방안
모든 환경에 대해 **기본 설정 검사(Hardening)**를 체계적으로 수행하고, 불필요한 기능과 포트를 비활성화합니다. CI/CD 파이프라인에 보안 설정 자동 검사 단계를 추가하고, 정기 감사를 통해 설정 드리프트를 방지해야 합니다.
A06: Vulnerable & Outdated Components — 사용하는 라이브러리가 안전한가?
무엇이 문제인가
현대 개발은 수백 개의 오픈소스 라이브러리와 외부 컴포넌트를 활용합니다. 이 중 하나라도 알려진 취약점을 가지고 있거나 유지보수가 중단된 경우, 공격자는 그 약점을 통해 우리 시스템에 침입할 수 있습니다.
공격 시나리오
2021년의 Log4Shell(CVE-2021-44228) 사건은 Java 로깅 라이브러리 Log4j의 취약점으로 인해 전 세계 수백 개 기업의 서버가 원격 코드 실행(RCE) 공격에 노출된 실제 사례입니다. 이 라이브러리를 사용했던 조직 중 많은 곳에서는 자신들이 사용하고 있었던 것조차 파악하지 못했습니다.
대응 방안
SCA(Software Composition Analysis) 도구를 활용하여 사용 중인 모든 컴포넌트의 버전과 취약점을 지속적으로 모니터링합니다. npm, pip, Maven 등의 패키지 매니저에서 제공하는 보안 알림(Security Advisory) 기능을 활용하고, 정기적으로 패키지를 업데이트하는 습관을 만들어야 합니다.
A07: Identification & Authentication Failures — "당신은 진짜인가?"
무엇이 문제인가
인증(Authentication)과 세션 관리에 취약점이 있으면, 공격자는 다른 사람의 계정을 가로질러 접근할 수 있습니다. 약한 비밀번호, 세션 토큰의 부적절한 관리, 다중 인증(MFA)의 부재가 주요 원인입니다.
공격 시나리오
사용자가 로그아웃했지만 세션 토큰이 서버 측에서 무효화되지 않아, 공격자가 이전 토큰을 재사용하여 계정에 접근하는 세션 고정(Session Fixation) 공격이 가능합니다. 또는 비밀번호가 "123456"처럼 너무 단순하여 Brute Force 공격으로 간단히 해독되는 경우도 해당됩니다.
대응 방안
MFA(다중 인증) 를 기본 옵션으로 제공하고, 비밀번호 복잡도 정책을 강화합니다. 세션 토큰은 로그아웃 시 즉시 무효화하고, 일정 시간 후 자동 만료되도록 설정해야 합니다. OAuth 2.0, OpenID Connect 등의 표준 인증 프로토콜을 적용하는 것도 좋은 접근입니다.
A08: Software & Data Integrity Failures — "배포된 코드가 원본과 같은가?"
무엇이 문제인가
소프트웨어 배포 파이프라인(Supply Chain)이 안전하지 않으면, 공격자가 배포 과정에 악성 코드를 삽입할 수 있습니다. 또한 데이터가 전송 중 변경되었는지 확인하는 무결성 검증 이 부재한 경우도 문제입니다.
공격 시나리오
2020년의 SolarWinds 공격은 소프트웨어 업데이트 파일 자체에 백도어가 삽입된 소프트웨어 공급망 공격(Supply Chain Attack)의 대표적인 사례로, 미국 정부와 대형 기업 수십 곳이 피해를 받았습니다.
대응 방안
CI/CD 파이프라인의 각 단계에서 코드 서명(Code Signing) 과 해시 검증을 수행합니다. SBOM(Software Bill of Materials) 을 작성하여 사용 중인 모든 컴포넌트를 추적하고, 배포 환경에 대한 접근을 최소화하는 것이 핵심입니다.
A09: Security Logging & Monitoring Failures — "공격이 있었는지 우리는 알고 있는가?"
무엇이 문제인가
공격이 발생했을 때, 이를 즉시 감지하고 대응할 수 있는 로깅과 모니터링 체계 가 없으면 피해가 장기간 지속될 수 있습니다. OWASP에서는 이 항목을 업계 전문가들의 강력한 요구로 목록에 유지하고 있습니다.
공격 시나리오
한 회사의 웹 서버에 해킹 공격이 가해졌지만, 로그가 제대로 기록되지 않았거나 모니터링 알림이 설정되지 않아 6개월 동안 공격자가 시스템 내부를 자유롭게 접근하고 있었습니다. 피해는 이미 발생한 후에야 발견됩니다.
대응 방안
모든 인증, 접근, 오류 이벤트를 체계적으로 로깅하고, SIEM(Security Information and Event Management) 시스템을 활용하여 실시간 모니터링과 이상 탐지를 수행합니다. 정기적인 로그 검토와 인사이드 위협 탐지 프로세스도 구축해야 합니다.
A10: Server-Side Request Forgery (SSRF) — 서버가 공격자의 요청을 대신 실행한다
무엇이 문제인가
SSRF는 공격자가 서버 측 애플리케이션을 이용하여, 내부 네트워크의 리소스에 대한 요청을 임의로 생성하는 공격입니다. 외부에서 직접 접근할 수 없는 내부 시스템까지 공격 대상이 될 수 있습니다. 이 항목도 업계 전문가들의 강하한 요구로 2021년에 새로 추가되었습니다.
공격 시나리오
외부 URL을 받아 미리보기를 생성하는 기능이 있는 앱에서, 공격자가 다음과 같은 URL을 입력합니다:
http://169.254.169.254/latest/meta-data/이 주소는 AWS 클라우드의 인스턴스 메타데이터 URL로, 서버 내부에서만 접근 가능합니다. 앱이 이 요청을 처리하면, AWS 계정의 IAM 정보가 공격자에게 반환됩니다.
대응 방안
모든 외부 요청에 대해 URL 유효성 검사와 허용 목록(Allowlist) 을 적용합니다. 내부 네트워크로의 요청을 방지하기 위해 프록시 설정과 네트워크 세그먼테이션 을 강화하고, 클라우드 환경에서는 메타데이터 접근을 제한하는 설정을 적용해야 합니다.
마음에 새기을 5가지 핵심 원칙
OWASP Top 10 전체를 관통하는 보안의 기본 철학을 정리하면 다음과 같습니다.
① Secure by Design — 보안은 개발 시작 단계부터 고려해야 합니다.
② 최소 권한 원칙 — 사용자와 시스템 모두 반드시 필요한 권한만 부여합니다.
③ 입력 불신 — 모든 외부 입력값은 검증·정제 후에만 사용합니다.
④ 암호화 우선 — 저장과 전송 모든 단계에서 강력한 암호화를 적용합니다.
⑤ 지속적 모니터링 — 공격을 예방하는 것만큼 중요하게, 공격을 감지하는 역량도 구축합니다.
마지막으로
OWASP Top 10은 단순한 리스트가 아닙니다. 이는 전 세계 보안 커뮤니티의 실전 경험과 데이터를 거짜면 도출된 경고입니다. 현재 2025년 버전이 갱신 작업 중이므로, 새로운 트렌드와 위험 유형이 추가될 가능성도 높습니다.
우리가 할 수 있는 최선은, 이 10가지 항목을 개발 프로세스의 체크리스트로 내면화하고, 팀 전체가 보안을 문화로 받아들이는 것입니다. 그것이 진정한 보안의 출발점입니다.
댓글