Security

OWASP Top10 2025 A05 Injection : 입력값 검증을 넘어 ‘실행 경계’를 다루는 보안으로

Donghwi Shin

Published: 08:00, 29 Jan 2026 (Updated: 15:17, 10 Feb 2026)

💡

Editor Pick
- OWASP Top10 2025에서 Injection 순위 변화에 관심을 갖기 보단 관점의 변화에 주목
- Injection에 대한 관점 변화는 대응 전략의 변화로 이어져야 함

OWASP시리즈의 일환으로 OWASP Top10 2025의 다섯 번째 A05 Injection을 살펴보고자 한다. Injection은 OWASP Top10 2021 A03에서 OWASP Top10 2025 A05로 이동했다. 우리는 일반적으로 이와 같은 현상을 순위의 하락으로 바라보고 중요도가 떨어진 것으로 이해하는 편이다. 하지만, 이는 중요도 하락이 아닌 정의의 정교화라고 설명하는 것이 적절하다. 2021년 대비 2025년의 CWE 구성을 비교해 보면, OWASP는 Injection을 단순한 입력값 검증 실패가 아닌 경계가 무너지며 데이터가 실행 코드로 해석되는 문제로 재정의한다고 볼 수 있다. 본 지에서는 OWASP Top10 2021 A03과 2025 A05의 CWE 비교를 통해 Injection 개념이 어떻게 확장, 정리되고 있는지, 그리고 보안성 검토 시 무엇을 살펴야 할지 알아보고자 한다.

people walking near traffic cone on road during daytime — Photo by DAVIDSON L U N A / Unsplash

Injection은 줄어든 것이 아니라, 관점이 바뀌었다

OWASP Top10 2025에서 Injection은 단순한 “잘못된 입력값 처리” 문제로 바라보지 않는다. Injection의 핵심은 입력 그 자체가 아니라, 그 입력이 어디까지 도달해 무엇으로 실행되는가에 있다. 이는 OWASP가 Injection의 관점을 입력값 처리에서 “실행 중심”으로 재편했다고 볼 수 있다.

우리가 Injection에 대해 그리는 상황은 공격자가 원하는 데이터를 주입하고 그 내용이 직접 실행에 영향을 미치는 모습이다. 그러나 공격자는 이제 SQL 문장을 직접 주입하지 않더라도, ORM의 쿼리 생성 과정이나 템플릿 엔진의 표현식 평가, 규칙 엔진의 동적 해석 지점을 통해 의도치 않은 실행을 유도할 수 있다.

💡

ORM(Object-Relational Mapping): 객체와 데이터베이스 테이블 간의 매핑을 자동화하는 기술. 개발자가 직접 SQL을 작성하지 않아도 내부적으로 쿼리가 생성된다.

개발자로서 단순한 설정이나 편의 기능처럼 보이지만, 이와 같은 기능들은 공격자에게는 실행 경계를 넘을 수 있는 진입점으로 보일 수 있다.

이와 같은 상황 속에 OWASP Top10 2025가 실행 중심의 관점으로 Injection을 재정의했으며 그 결과가 CWE 구성 변화와 보안성 검토 질문의 전환으로 나타난다. 아래 문단에서는 이러한 변화를 보여주는 내용을 구체적으로 살펴본다.

a person's hand with white paint on it — Photo by Tapish / Unsplash

Injection으로 보이지 않는 CWE를 포함시키는 OWASP의 의도

OWASP Top10 2025 A05 Injection에는 CWE-20(Improper Input Validation), CWE-115(Misinterpretation of Output), CWE-129(Improper Validation of Array Index), CWE-159(Improper Handling of Invalid Use of Special Elements)처럼 직관적으로 Injection이라 보기 어려운 CWE가 포함되어 있다. 중요한 점은 이 CWE들이 2025년에 새롭게 추가된 것이 아니라, 2021년에도 Injection 범주에 포함되어 있었다는 사실이다.

OWASP가 이러한 CWE를 지속적으로 Injection에 포함시키는 이유는 명확하다. 이들 CWE는 단독으로는 명령 실행을 일으키지 않지만, SQL Injection(CWE-89), Command Injection(CWE-78), Expression Language Injection(CWE-917)과 같은 실행형 Injection의 전제 조건을 형성하기 때문이다. 예를 들어 CWE-129(Improper Validation of Array Index)는 SQL-Injection : Hibernate(CWE-564)으로 이어질 수 있고, CWE-115(Misinterpretation of Output)는 브라우저나 템플릿 엔진에서 XSS 또는 스크립트 실행으로 전이될 수 있다. 즉, OWASP는 Injection을 ‘발생 시점’이 아니라 ‘형성 과정’까지 포함하는 취약점 군으로 이해하도록 유도하고 있다고 볼 수 있다.

two cars in front of shutter doors — Photo by Dietmar Becker / Unsplash

2021 대비 2025년 CWE 변화의 구조적 특징

이전에 언급한 내용을 기반으로 보면 OWASP Top10 2025 A05의 변화는 개별 CWE의 추가/삭제보다 Injection을 바라보는 구조적 관점의 이동에 가깝다. OWASP Top10 2021이 “어떤 입력이 어떤 명령으로 실행되는가”에 초점을 맞췄다면, OWASP Top10 2025는 “입력이 어디에서 해석되고, 어떤 경계를 넘어 실행되는가”를 중심으로 Injection을 바라보는 것이다. 이 변화는 OWASP Top10 2025 A05에 대한 설명과 대응 방안에 반영되어 있다.

첫째, 입력값이 아니라 ‘실행 경계(Interpreter Boundary)’ 중심으로 재정렬되었다.

OWASP Top10 2021에서 Injection은 SQL, OS Command, XSS 등 공격 방식의 분류가 중심이었다. 반면 OWASP Top10 2025에서는 입력을 어떤 인터프리터(Interpreter)가 해석하는지가 중요하다고 설명한다. 그러므로 SQL 엔진, 운영체제, 템플릿 엔진, 웹 브라우저까지 모두 인터프리터로 간주하고, 입력 데이터가 경계를 넘는 순간을 Injection으로 판단한다. 예를 들어 ORM 환경에서 사용자 입력이 쿼리 문자열이 아닌 정렬 필드, 조건식, 표현식으로 전달되더라도 여전히 SQL 인터프리터에 의해 해석되는 실행 경계 침해다. 이와 같은 관점은 OWASP Top10 2025 A05의 "How to Prevent" 단락에서 강조하는 “데이터와 명령의 명확한 분리”는 바로 이 경계를 흐리지 말라는 지침에서 명확하게 드러난다.

둘째, 전통적 Injection의 ‘전제 조건’을 형성하는 CWE가 구조적으로 부각되었다.

OWASP Top 2025 A05에는 CWE-129(Improper Validation of Array Index), CWE-115(Misinterpretation of Output), CWE-116(Improper Encoding or Escaping of Output)처럼 단독으로는 실행을 일으키지 않는 CWE들이 포함되어 있다. OWASP는 이들을 독립 취약점이 아닌 실행형 Injection으로 이어지는 취약점들로 바라보는 것이다. 예를 들어 배열 인덱스 검증 실패는 ORM에서 컬럼 선택, 조건 분기, 동적 매핑에 영향을 주어 쿼리 구조 자체를 변형할 수 있고, 출력 해석 오류는 템플릿 엔진이나 브라우저가 데이터를 코드로 오인하게 만드는 출발점이 된다. 이는 “Injection은 한 번에 터지는 공격이 아니라, 단계적으로 형성되는 실행 조건의 축적”이라는 관점을 반영한다.

셋째, XSS를 ‘웹 전용 취약점’이 아닌 Injection의 전형으로 재확인했다.

OWASP가 XSS를 Injection 카테고리에 포함시킨 것은 2021년부터 이어지지만, 2025에서는 그 의미가 더 명확해진 것으로 보인다. 그 이유로 꼽을 수 있는 것은 OWASP가 웹 브라우저를 HTML, JavaScript, DOM을 해석하는 복합 인터프리터로 판단하기 때문이다. 즉 XSS는 “스크립트가 삽입되었는가”의 문제가 아니라, 입력 데이터가 브라우저 인터프리터에서 코드로 해석되는 실행 경계를 넘었는가의 문제다. 이와 같은 OWASP의 관점에서 보면 템플릿 엔진의 표현식 실행, DOM 기반 XSS, 클라이언트 사이드 렌더링 문제는 모두 Injection의 범주에 놓이는 것이 합리적이라 할 수 있다.

넷째, 추상화 계층에 대한 과도한 신뢰를 구조적 위험으로 명시했다.

OWASP Top10 2025 A05는 ORM, 템플릿 엔진, Rule Engine 같은 추상화 계층이 Injection을 “자동으로 제거해준다”는 인식의 문제점을 제기한다. OWASP에서는 추상적 계층이 오히려 실행 경계를 감추고, 보안 검토 지점을 흐릴 수 있다고 지적한다. 개발자가 직접 SQL이나 스크립트를 작성하지 않더라도, 입력이 쿼리 구조, 표현식, 렌더링 로직에 영향을 준다면 Injection의 위험은 여전히 존재한다고 인식하고 있어야 하는 것이다. 이는 SAST 또는 DAST 같은 도구로 탐지하기 어려운 비지니스 로직 기반의 취약점이 증가하고 있음을 반영한 것으로 보인다.

위 내용을 정리하자면 OWASP Top10 2021 대비 OWASP Top10 2025의 변화는 Injection을 실행 모델 관점에서 재정의했다는 것으로 보고 맥락을 파악하는 것이 효과적일 것이다. OWASP Top10 2025 A05에서 개발자와 보안 담당자에게 더 이상 “어떤 문자열이 들어오는가?”를 묻지 않고 “어떤 입력이, 어떤 해석기에서, 어떤 방식으로 실행될 수 있는가?”라는 질문을 던지고 있는 것이다.

people raising their hands — Photo by Edwin Andrade / Unsplash

보안성 검토와 대응 전략: Injection 방어를 위해 던져야 할 질문

OWASP Top10 2025 A05는 Injection 대응을 “취약점을 어떻게 막을 것인가”가 아닌 “어디에서 실행이 발생할 수 있지 어떻게 식별할 것인가”의 문제로 전환한다. 이에 따라 보안성 검토와 대응 전략 역시 개별 기술 대응이 아닌, 실행 경계를 중심으로 하는 질문에서 출발해야 한다.

첫째, 이 입력은 어떤 인터프리터에서 해석되는가?

OWASP Top10 2021은 방어를 위해 “SQL인가, XSS인가”처럼 공격 유형을 식별하는 데 집중했다. 그러나 OWASP Top10 2025에서는 앞선 문단들에서 지속적으로 언급한 것과 같이 입력을 해석하는 인터프리터가 무엇인지가 핵심 질문이다. SQL 엔진, OS 뿐 아니라 ORM의 쿼리 빌더, 템플릿 엔진의 표현식 처리기, Rule Engine, 그리고 웹 브라우저까지 모두 검토 대상이다. 대응 전략 역시 특정 Injection 패턴 차단이 아닌 데이터와 명령의 명시적 분리 그리고 인터프리터 경계를 넘는 설계이다. 끊임없이 생겨나는 비지니스 로직과 다양한 페이로드를 모두 패턴을 기반으로 차단할 수 없다. 그러므로 이제는 데이터와 명령의 분리 그리고 인터프리터 경계에 대한 철저한 통제를 목표로 삼아야 한다.

둘째, 개발자가 직접 작성하지 않은 ‘추상화 계층’에서도 실행이 발생하는가?

OWASP Top10 2025 A05는 ORM, 템플릿 엔진, 프레임워크 설정 영역을 Injection의 주요 맹점으로 지목한다. 개발자가 SQL이나 스크립트를 직접 작성하지 않더라도, 입력값이 쿼리 구조, 표현식, 렌더링 로직에 영향을 준다면 실행은 여전히 발생한다. 그러므로 보안성 검토 시 “직접 명령을 작성했는가”가 아니라 “입력이 로직을 구성하는 요소로 사용되는가”를 질문해야 한다. 이를 위해 OWASP에서는 안전한 API 사용 여부 검토, 동적 쿼리/표현식 생성 제한, 프레임워크의 보안 옵션 설정 등을 강조하고 있다.

셋째, 실행으로 이어지는 ‘전제 조건 CWE’가 누적되고 있지는 않은가?

CWE-129(Improper Validation of Array Index), CWE-115(Misinterpretation of Output), CWE-116(Improper Encoding or Escaping of Output) 단독으로 공격이 성립되지 않을 수 있다. 그러나 OWASP는 이들을 Injection의 구조적 토대가 될 수 있다고 바라보고 있다. 그러므로 보안성 검토는 개별 취약점 존재 여부가 아닌 앞서 언급한 CWE 그리고 다른 취약점이 연쇄적으로 이어질 수 있는지 확인해야 한한다. 결국 개별 취약점 대응, 입력 검증, 출력 인코딩의 단편적 적용이 아닌 문맥을 기반으로 하는 검증이 필요하다.

넷째, 보안 도구는 실행 맥락까지 관찰하고 있는가?

OWASP Top10 2025는 기존 보안 점검 도구의 한계를 간접적으로 설명하고 있다. 기존 분석 도구들이 문자열 기반 Injection에는 효과적일 수 있으나, ORM, 템플릿, 표현식 기반 실행 흐름은 따라가기 쉽지 않다. 따라서 OWASP는 대응 전략으로 IAST와 같은 런타임 관찰 기법, 코드 리뷰에서의 실행 경계 분석, 아키텍처 단계에서의 위협 모델링을 강조한다. 나아가 AI를 활용하여 실행 흐름을 이해하며 따라가는 방향으로 도구를 활용할 수 있어야 한다. 이는 단순히 더 나은 도구 추가가 아닌, Injection을 실행 모델로 이해하고 검증하는 방식으로의 전환을 의미한다.

결국 OWASP Top10 2025 A05가 던지는 메시지는 명확하다. Injection 방어의 핵심은 “무엇을 필터링할 것인가”가 아니라, “어디에서 실행이 시작될 수 있는가를 인식하고 통제하는가”에 있다. 보안성 검토와 대응 전략은 이제 같은 질문을 공유해야 하며, 그 질문은 실행 경계를 중심으로 재정의해야 한다

결론 : Injection을 바라보는 시선의 변화

OWASP Top10 2025 A5 Injection은 Injection을 다시 정의한다고 바라보는 것이 적절하다. 여기서 핵심은 입력값이 언제, 어디서 실행 코드로 해석되는지 판단해야 한다는 것이다. 일부 CWE가 제거되고 일부가 추가되었지만, 이는 중요도의 변화가 아닌 Injection을 보다 현실적이고 실행 중심적인 취약점 군으로 재정의한 것이다. 이제 OWASP Top10 2025 이후 Injection 대응의 성패는 필터 규칙의 개수가 아니라, 애플리케이션 전반에서 데이터와 실행을 분리하고 실행 경계를 통제하는 설계 역량에 달려 있다고 할 수 있다.