OWASP Top 10이란? 2017·2021·2025 세 판으로 본 웹 보안 위협의 흐름

한눈에 보기

• OWASP Top 10은 웹 애플리케이션에서 가장 중요한 보안 위험 10가지를 정리한 목록입니다. 비영리 단체 OWASP(Open Worldwide Application Security Project)가 몇 년에 한 번씩 새로 냅니다. 2025년 판이 여덟 번째입니다.
• 최근 세 판은 2017년, 2021년, 2025년 판입니다. 2025년 판은 2025년 11월 후보판으로 공개된 뒤 연말에 최종판이 됐습니다.
• 가장 큰 변화는 접근 통제 실패입니다. 2017년 5위에서 2021년 1위로 올라 2025년에도 1위입니다.
• 2017년 1위였던 인젝션은 3위(2021)를 거쳐 5위(2025)로 내려갔습니다.
• 2025년에는 소프트웨어 공급망 실패가 3위로 새로 들어오고, 보안 설정 오류가 5위에서 2위로 올랐습니다.
• 목록은 공격 기법의 이름보다 근본 원인을 기준으로 바뀌어 왔습니다.

OWASP Top 10은 어떻게 만들어지나

OWASP는 여러 보안 회사와 기관이 보낸 실제 점검 데이터와 현장 실무자 설문을 함께 씁니다. 데이터는 이미 찾아낸 취약점을 보여 주고, 설문은 데이터에 아직 잡히지 않는 새 위험을 보완합니다. 2025년 판은 이 이유를 "제공받은 데이터를 보는 것은 사실상 과거를 보는 것"이라고 적었습니다. 2021년 판은 10개 분류 중 8개를 데이터로, 2개를 설문으로 골랐습니다.

데이터의 규모는 판마다 크게 늘었습니다.

CWE(Common Weakness Enumeration)는 소프트웨어 약점의 종류에 붙인 번호입니다. 예를 들어 "SQL 인젝션"은 CWE-89입니다. OWASP는 수백 개의 CWE를 10개 분류로 묶어 순위를 매깁니다.

세 판 나란히 보기

2025년 판 10가지 항목 자세히

항목마다 무엇인지, OWASP가 든 예시 장면, 막는 법을 정리했습니다.

A01. 접근 통제 실패(Broken Access Control)

무엇인가. 사용자가 허락된 권한 밖의 일을 할 수 있는 문제입니다. 남의 데이터를 보거나 바꾸고, 권한 없는 기능을 쓰게 됩니다.

예시. 계좌 정보를 보여 주는 주소가 https://example.com/app/accountInfo?acct=내계좌 라고 합시다. 서버가 요청한 사람이 그 계좌 주인인지 확인하지 않으면, 주소의 acct 값만 남의 계좌 번호로 바꿔도 남의 정보가 보입니다. 관리자 화면 버튼을 화면에서만 숨기고 서버에서는 막지 않으면, 공격자는 그 주소를 직접 불러 관리자 기능을 씁니다.

막는 법. 권한 확인은 공격자가 바꿀 수 없는 서버 쪽 코드에서 합니다. 공개 자원이 아니면 기본값을 "거부"로 두고, 데이터마다 "이 사람이 주인인가"를 확인합니다.

A02. 보안 설정 오류(Security Misconfiguration)

무엇인가. 서버·애플리케이션·클라우드를 보안상 잘못 설정해 생기는 약점입니다. 필요 없는 기능이 켜져 있거나, 기본 계정과 비밀번호가 그대로이거나, 오류 메시지가 내부 정보를 너무 많이 보여 주는 경우입니다.

예시. 운영 서버에 설치할 때 딸려 온 예제 애플리케이션을 지우지 않았고, 그중 하나가 관리 콘솔인데 기본 비밀번호도 그대로입니다. 공격자는 기본 비밀번호로 로그인해 서버를 장악합니다. 클라우드 저장소의 공유 권한이 기본값으로 인터넷 전체에 열려 있어 민감한 데이터가 새는 경우도 여기에 들어갑니다.

막는 법. 설정을 손으로 하지 않고 자동화된 절차로 똑같이 잠급니다. 개발·검증·운영 환경은 같은 설정에 서로 다른 자격 증명을 씁니다. 쓰지 않는 기능·계정·예제는 지웁니다.

A03. 소프트웨어 공급망 실패(Software Supply Chain Failures)

무엇인가. 소프트웨어를 만들고 배포하고 업데이트하는 과정이 뚫리는 문제입니다. 직접 쓰는 라이브러리뿐 아니라 그 라이브러리가 쓰는 라이브러리, 빌드 도구, 배포 서버까지 포함합니다.

예시. OWASP는 실제 사건 세 가지를 듭니다. 2019년 SolarWinds 사건에서는 믿고 쓰던 업체의 업데이트에 악성 코드가 들어가 약 1만 8천 곳의 조직이 침해됐습니다. 2025년 Bybit 사건에서는 지갑 소프트웨어에 심긴 코드가 특정 지갑을 쓸 때만 작동해 15억 달러가 도난당했습니다. 2025년 Shai-Hulud 공격은 인기 npm 패키지에 악성 버전을 심어 스스로 퍼지는 첫 npm 웜이었습니다.

막는 법. 쓰는 모든 구성 요소와 그 의존성을 목록(SBOM)으로 관리하고, 버전을 계속 추적합니다. 쓰지 않는 의존성은 지웁니다. 빌드와 배포 과정에서 누가 무엇을 바꿀 수 있는지 좁힙니다.

A04. 암호화 실패(Cryptographic Failures)

무엇인가. 암호화를 하지 않았거나 약하게 해서 민감한 데이터가 드러나는 문제입니다.

예시. 일부 페이지에서 HTTPS를 강제하지 않는 사이트를 공용 와이파이에서 쓰면, 공격자가 연결을 HTTP로 낮춰 세션 쿠키를 훔치고 그 사용자로 로그인한 것처럼 행세합니다. 비밀번호를 솔트 없이 단순한 해시로 저장한 데이터베이스가 유출되면, 미리 계산해 둔 해시표로 비밀번호가 한꺼번에 풀립니다.

막는 법. 모든 전송을 TLS로 암호화합니다. 데이터를 분류해 민감한 것을 표시하고, 필요 없는 민감 데이터는 저장하지 않습니다. 비밀번호는 느리게 계산하는 전용 해시 함수로 저장하고, 검증된 암호 라이브러리를 씁니다.

A05. 인젝션(Injection)

무엇인가. 사용자가 넣은 값이 데이터베이스·브라우저·명령줄 같은 해석기에 명령의 일부로 실행되는 문제입니다. SQL 인젝션과 XSS가 대표적입니다.

예시. 다음처럼 입력값을 SQL 문장에 그대로 이어 붙인다고 합시다.

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

공격자가 id 값으로 ' OR '1'='1 을 보내면 조건이 늘 참이 되어 모든 계정 정보가 나옵니다. 더 위험한 경우 데이터를 바꾸거나 지울 수도 있습니다. OWASP는 프레임워크를 쓴다고 안심해서도 안 된다며, 같은 방식으로 이어 붙인 Hibernate 쿼리(HQL)도 뚫리는 예를 함께 듭니다.

막는 법. 데이터와 명령을 섞지 않습니다. 매개변수화 쿼리처럼 값이 명령으로 해석되지 않는 안전한 API를 쓰고, 출력은 쓰일 곳에 맞게 인코딩합니다.

A06. 안전하지 않은 설계(Insecure Design)

무엇인가. 코드를 잘못 짠 것이 아니라, 처음부터 필요한 보안 장치를 설계하지 않은 문제입니다. OWASP는 "안전하지 않은 설계는 완벽한 구현으로도 고칠 수 없다"고 말합니다.

예시. 한 영화관 체인은 단체 예매 할인을 주면서 15명이 넘으면 보증금을 받도록 했습니다. 그런데 몇 번의 요청으로 모든 상영관의 좌석 600석을 한꺼번에 잡아 둘 수 있다면 큰 손해가 납니다. 코드는 설계대로 정확히 동작했지만, 설계에 악용 시나리오가 없었습니다. "비밀번호 찾기 질문과 답"도 여러 사람이 답을 알 수 있어 본인 확인 수단으로 믿을 수 없는 설계입니다.

막는 법. 인증·권한·결제 같은 중요한 흐름은 만들기 전에 위협 모델링으로 악용 시나리오를 먼저 적어 봅니다. 검증된 보안 설계 패턴을 모아 두고 다시 씁니다.

A07. 인증 실패(Authentication Failures)

무엇인가. 공격자가 다른 사람인 척 로그인할 수 있는 문제입니다.

예시. 다른 사이트에서 유출된 아이디·비밀번호 목록을 그대로 넣어 보는 크리덴셜 스터핑이 흔합니다. 요즘은 사람들의 습관을 노려 Winter2025 를 Winter2026 으로, ILoveMyDog6 을 ILoveMyDog7 로 바꿔 넣어 보기도 합니다. 자동화된 시도를 막지 않는 사이트는 "이 비밀번호가 맞는지" 알려 주는 창구가 됩니다.

막는 법. 다중 인증(MFA)을 쓰고, 비밀번호 관리자 사용을 돕습니다. 기본 관리자 계정을 남기지 않고, 새 비밀번호를 가장 흔한 비밀번호 목록과 대조합니다. 로그인 실패가 반복되면 늦추거나 막습니다.

A08. 소프트웨어 또는 데이터 무결성 실패(Software or Data Integrity Failures)

무엇인가. 검증되지 않은 코드나 데이터를 믿을 만한 것으로 받아들이는 문제입니다. 출처를 확인하지 않은 플러그인, 서명 없이 받는 업데이트, 검증 없이 산출물을 가져오는 빌드 파이프라인이 여기에 들어갑니다.

예시. 가정용 공유기나 셋톱박스 가운데는 서명된 펌웨어인지 확인하지 않고 업데이트하는 기기가 많습니다. 공격자가 바꿔치기한 펌웨어도 그대로 설치됩니다. 한 회사가 편의를 위해 외부 고객 지원 서비스를 support.회사.com 으로 연결해 두자, 회사 도메인의 로그인 쿠키가 그 외부 서비스로 함께 전송돼 세션을 도둑맞을 수 있게 된 예도 있습니다.

막는 법. 디지털 서명으로 소프트웨어와 데이터가 기대한 출처에서 왔고 바뀌지 않았는지 확인합니다. 믿을 수 있는 저장소에서만 패키지를 받고, 코드와 설정 변경에는 검토를 둡니다.

A09. 보안 로깅·경보 실패(Security Logging and Alerting Failures)

무엇인가. 공격이 일어나도 기록이 없거나, 기록은 있어도 아무도 알아채지 못하는 문제입니다.

예시. 한 어린이 건강보험 사이트는 기록과 감시가 없어 공격을 알아채지 못했습니다. 외부에서 알려 준 뒤에야 350만 명이 넘는 어린이의 건강 기록 수천 건이 조회되고 바뀐 것을 알았고, 침해는 7년 넘게 이어졌을 수 있었습니다. 로그인 성공만 기록하고 실패는 남기지 않는 경우도 흔한 예입니다.

막는 법. 로그인·권한 확인·입력 검증 실패를 누가 했는지 알 수 있게 기록하고, 사후 조사에 충분한 기간 보관합니다. 로그 관리 도구가 읽을 수 있는 형식으로 남기고, 이상한 일이 생기면 경보가 울리게 합니다.

A10. 예외 상황 처리 미흡(Mishandling of Exceptional Conditions)

무엇인가. 예상하지 못한 상황을 막지 못하고, 알아채지 못하고, 제대로 대응하지 못하는 문제입니다. 2025년 판에 새로 들어왔습니다.

예시. 이체가 "보내는 계좌에서 빼기 → 받는 계좌에 넣기 → 기록하기" 순서로 진행되는데, 공격자가 중간에 네트워크를 끊습니다. 시스템이 오류가 난 거래 전체를 되돌리지(fail closed) 않으면 돈이 빠져나가기만 하거나 계좌가 어긋납니다. 데이터베이스 오류 메시지를 사용자에게 그대로 보여 주면, 공격자는 일부러 오류를 내면서 얻은 정보로 더 정교한 SQL 인젝션을 준비합니다.

막는 법. 오류가 날 수 있는 곳에서 바로 잡아 처리하고, 실패하면 막는 쪽으로 멈춥니다. 여러 단계로 된 작업은 중간에 실패하면 전체를 되돌립니다. 사용자에게는 이해할 수 있는 짧은 메시지만 보여 주고, 자세한 내용은 기록과 경보로 남깁니다.

세 판을 거치며 달라진 것

항목 하나하나보다 세 판을 나란히 놓았을 때 보이는 흐름을 여섯 가지로 정리합니다.

흐름 1. 공격 기법에서 근본 원인으로

2017년 목록에는 XXE, XSS처럼 공격 기법의 이름이 많았습니다. 2021년 판부터 OWASP는 증상보다 원인에 맞춰 분류를 다시 묶었습니다. 2021년 소개문은 "필요할 때는 증상보다 근본 원인에 초점을 맞추도록 이름을 바꿨다"고 적습니다.

• 민감한 데이터 노출 → 암호화 실패. 데이터가 새는 것은 결과일 뿐이고, 원인은 암호화를 하지 않았거나 잘못한 데 있다는 뜻입니다. OWASP는 이전 이름이 "근본 원인이 아니라 넓은 증상"이었다고 설명합니다.
• XSS는 인젝션으로, XXE는 보안 설정 오류로 들어갔습니다. 사용자 입력이 코드로 해석되는 문제(인젝션)와 파서를 위험하게 설정한 문제(설정 오류)로 원인을 따라 옮긴 것입니다.

2025년 판도 이 방향을 이어 갑니다. 다만 "겹치는 부분 없이 10개 분류를 만드는 것은 사실상 불가능하다"고 한계도 함께 적었습니다.

흐름 2. 접근 통제 실패가 1위가 되다

접근 통제 실패는 로그인한 사용자가 허락되지 않은 데이터나 기능에 닿는 문제입니다. 주소의 숫자만 바꾸면 남의 주문 내역이 보이거나, 일반 사용자가 관리자 기능을 부를 수 있는 경우가 대표적입니다.

• 2017년 5위에서 2021년 1위로 올랐습니다. 2021년 판 분류 표에서 이 분류에 묶인 CWE는 34개였고, 발생 건수는 31만 8천 건이 넘었습니다.
• 2025년에도 1위입니다. 2025년 판은 "시험한 애플리케이션의 100%에서 어떤 형태로든 접근 통제 실패가 발견됐다"고 적었습니다.
• 2025년에는 2021년 10위였던 서버 측 요청 위조(SSRF)가 이 분류에 합쳐졌습니다. 서버가 가면 안 되는 곳으로 요청을 보내게 만드는 것도 결국 접근 통제의 실패라는 뜻입니다.

흐름 3. 인젝션은 내려갔지만 사라지지 않았다

SQL 인젝션처럼 사용자 입력이 명령으로 실행되는 문제는 오랫동안 1위였습니다. 2021년 3위, 2025년 5위로 내려갔습니다. 2021년 판은 인젝션에 대해 "애플리케이션의 94%가 어떤 형태로든 인젝션 시험을 받았다"고 적었습니다. 널리 시험하고 막는 방법이 알려진 만큼 순위가 내려간 것으로 볼 수 있습니다.

그렇다고 사라진 것은 아닙니다. 2021년 판부터 XSS가 여기에 합쳐졌고, 새로운 형태의 인젝션도 계속 나옵니다. AI 서비스에서 문제가 되는 프롬프트 인젝션도 "입력이 지시로 해석되는" 같은 뿌리를 가집니다.

흐름 4. 설계와 설정이 앞으로 나오다

• 안전하지 않은 설계는 2021년에 새로 생긴 분류입니다. OWASP는 "안전하지 않은 설계는 완벽한 구현으로 고칠 수 없다"며, 코드를 쓰기 전에 위협을 모델링하는 일이 더 필요하다고 설명했습니다. 2025년에는 다른 분류가 앞으로 나오며 6위로 내려갔습니다.
• 보안 설정 오류는 6위(2017)에서 5위(2021), 2위(2025)로 올라왔습니다. 2021년 판은 "소프트웨어가 점점 설정으로 동작을 바꾸는 쪽으로 옮겨 가니 이 분류가 오르는 것은 놀랍지 않다"고 했고, 2025년 판은 "이번 주기의 데이터에서 설정 오류가 더 흔했다"고 적었습니다. 코드보다 설정이 동작을 정하는 부분이 늘어난 만큼, 설정도 코드처럼 검토해야 합니다.

흐름 5. 구성 요소에서 공급망으로

오픈소스 라이브러리를 쓰는 문제는 목록에서 점점 넓어졌습니다.

2025년 판은 이 분류를 라이브러리 버전 문제에서 의존성, 빌드 시스템, 배포 인프라 전체의 침해로 넓혔습니다. 설문 응답자의 정확히 50%가 이 분류를 1위로 꼽았습니다. 다만 수집 데이터에는 적게 잡혔는데, OWASP는 "시험하기 어렵기 때문이며 시험 기술이 따라오기를 바란다"고 적었습니다. 데이터보다 현장의 체감이 앞선 분류입니다.

흐름 6. 기록에서 경보로, 그리고 예외 처리

• 9위 분류의 이름이 로깅·모니터링에서 로깅·경보로 바뀌었습니다. OWASP는 "경보가 없는 훌륭한 로그는 가치가 거의 없다"고 적었습니다. 기록을 남기는 것에서 멈추지 말고, 이상한 일이 생기면 사람이 바로 알아야 한다는 뜻입니다.
• 10위에는 예외 상황 처리 미흡이 새로 들어왔습니다. 오류를 잘못 처리하거나, 문제가 생겼을 때 막지 않고 통과시키는(fail open) 경우를 다룹니다.

지금 점검할 것

AI 서비스에는 따로 목록이 있다

OWASP는 웹 목록과 별도로 LLM 애플리케이션을 위한 Top 10을 냅니다. 최신 판은 2026년 판입니다. 프롬프트 인젝션, 과도한 권한 위임처럼 생성형 AI에서 새로 생긴 위험을 다룹니다. OWASP LLM Top 10 2026 해설에서 이 목록을 자세히 풀었습니다.

자주 묻는 질문

OWASP Top 10을 모두 막으면 안전한가요?

아닙니다. OWASP Top 10은 가장 흔하고 중요한 위험을 모은 인식 개선용 목록입니다. 빠진 위험도 많고, 서비스마다 중요한 위험이 다릅니다. 첫 점검 기준으로 쓰고, 서비스에 맞는 위협 분석을 더하는 것이 좋습니다.

순위가 내려간 항목은 신경 쓰지 않아도 되나요?

아닙니다. 순위는 여러 애플리케이션에서 얼마나 자주, 얼마나 심각하게 발견됐는지를 반영합니다. 인젝션은 순위가 내려갔어도 한 번 뚫리면 피해가 큽니다. OWASP도 "공격자는 한 곳만 뚫으면 된다"는 이유로 발생 빈도보다 발생률을 씁니다.

새 판이 나오면 기존 점검 기준을 모두 바꿔야 하나요?

분류 이름과 순서가 바뀌어도 대부분은 합쳐지거나 넓어진 것입니다. 이전 판 기준으로 점검해 왔다면 새로 생긴 분류(2025년의 공급망 실패, 예외 상황 처리 미흡)부터 더하면 됩니다.

정리

세 판을 나란히 놓으면 웹 보안의 관심이 어디로 옮겨 갔는지 보입니다. 특정 공격 기법을 막는 데서, 권한과 설계와 설정을 제대로 하는 쪽으로 옮겨 갔습니다. 직접 쓰는 코드만이 아니라 가져다 쓰는 코드와 그것을 만들고 배포하는 과정까지 범위가 넓어졌습니다. 목록이 바뀌어도 기본은 같습니다. 누가 무엇에 닿을 수 있는지 서버가 매번 확인하고, 이상한 일이 생기면 바로 알 수 있어야 합니다.