모바일 앱에 XML 구성 파일을 패키징하는 순간 구조적인 보안 위험이 따라온다. 서버 측 애플리케이션과 달리 모바일 앱은 사용자와 잠재적 위협 행위자의 손에 직접 놓여 있어, 코드·리소스·데이터에 직접 접근하고 조작하는 것도 가능하다. APK에 포함된 XML은 추출과 역공학으로 확인할 수 있다는 전제 아래 평문 상태의 비밀정보가 노출되는 것이다. 이 글은 2026년 8월 26일 widedesk.co.kr SecurityDesk 채널에 발행된 DEEP DIVE REPORT “모바일 앱 XML 구성 파일 보안 점검: 하드코딩 비밀정보부터 권한·검증까지”를 근거로, XML 기반 구성 파일을 앱 패키지에 포함시키는 구조가 지니는 취약점을 세 가지 점검 프레임워크 중심으로 분석한다.
1. APK에 패키징된 순간 구성 파일은 추출 가능한 자산이 된다
구조적 노출: 서버 측 애플리케이션과의 차이
서버 측 애플리케이션은 네트워크 경계 뒤에서 동작한다. 모바일 앱은 다르다. 사용자 단말 위에 직접 설치되어 돌아간다. Digital.ai의 안드로이드 가이드에 따르면 이런 특수한 노출이 리버스 엔지니어링, 무단 접근, 민감 정보 악용의 위험을 크게 키운다. XML 구성 파일이 res/ 또는 assets/ 디렉터리에 배치된 시점부터 해당 파일은 앱 바이너리의 일부가 되어 배포 채널을 타고 사용자에게 전달된다.
적용 대상 구조
리포트가 상정하는 대상은 XML 구성 파일을 패키징하는 모바일 앱, 특히 APK 구조의 Android 앱이다. 구성 파일에 API 키 같은 장기 유효 비밀정보를 직접 포함하는 구조를 전제로 한다. 이 전제가 성립하지 않는 구성이라면 아래 분석의 적용 범위가 달라질 수 있다.
2. 하드코딩 비밀정보, 왜 XML 구성 파일에 두면 안 되는가
탈취 시 시나리오
API 검증에 사용되는 키가 하드코딩되어 있거나 리소스 폴더 등에 저장될 경우, 공격자가 검증용 키를 쉽게 유추해 임의로 API를 호출하는 피해를 입힐 수 있다. 평문 비밀정보 키가 탈취될 경우 가능한 결과로 API 쿼터 소진, 비용 발생, 리소스의 무단 변경이 제시되며, 정확한 피해 규모는 해당 키에 부여된 권한에 따라 달라진다.
여기서 “공격자의 접근”은 잠재적 경로이며, 특정 위협 행위자를 지칭하거나 이미 관측된 실제 악용을 전제하지 않는다. 이 서술은 구조적 취약점에 대한 사전적 위험 평가일 뿐, 특정 공격 건의 사후 분석이 아니다.
OWASP Mobile Top 10 2024 M1 관점
OWASP Mobile Top 10 2024의 M1 “부적절한 자격 증명 사용”은 모바일 앱의 소스 코드나 구성 파일 내에 하드코딩된 자격 증명을 취약점 발생 환경으로 명시한다. 대응 방안으로 하드코딩 자격 증명 사용 금지와 안전하게 취소 가능한 액세스 토큰 사용을 제시한다. 단, 이 인용은 DoveRunner의 2차 해설 블로그(2025-03-14 발행)에서 확인한 것이라 OWASP 공식 원문과 직접 대조하지는 못했다 [의 단일 출처 특성과 동일 성격의 2차 출처 한계].
3. 리버스 엔지니어링은 어떻게 APK의 리소스를 읽어내는가
APK 파일을 분해하면 컴파일된 바이너리에서 원본 소스 코드를 얻어내는 작업이 진행된다. 안드로이드 런타임에서 해석되는 DEX 파일은 디컴파일 도구가 JAR 파일로 바꾸고, 이후 또 다른 도구로 Java 소스 코드까지 되돌릴 수 있다. 이 과정에서 res/에 포함된 XML 파일은 평문 상태로 그대로 드러난다.
리포트의 점검이 수행되는 조건부 전제도 이 점에 기반한다. “APK에 패키징된 XML 파일은 추출될 수 있고, 앱 리소스·구성은 역공학으로 확인할 수 있다는 조건부 전제” 아래 점검이 수행된다는 명시적 서술이 있다. 이 전제가 적용되지 않는 특수 환경(예: 하드웨어 보안 모듈 내 격리된 키, 앱 외 서버에서만 해석되는 구성)이라면 역공학 경로 자체가 성립하지 않을 수 있다.
4. 난독화·암호화의 한계와 서버 측 키 관리로의 전환
방어 계층으로서의 난독화
난독화는 코드 접근 자체를 막지 못한다. 공격자가 코드를 악용하는 데 필요한 노력을 크게 키우는 방어 계층일 뿐이다. OWASP Mobile Top 10 2024 M7 “부족한 바이너리 보호”에서도 하드코딩된 민감한 데이터나 알고리즘이 포함되면 바이너리 공격에 취약해지고, 모든 앱은 기본적으로 바이너리 공격에 취약하다고 명시한다. 난독화·암호화는 근본 해결이 아니다. 다른 보안 조치와 함께 두는 필수 방어 계층으로 자리 잡는다.
Android Keystore: 조건부 권고
개발자는 API 키나 사용자 인증 정보 같은 민감 정보를 하드코딩하지 말고, 안드로이드 키스토어 같은 보안 프레임워크로 키를 관리하는 것이 원칙이다. 다만 리포트에서는 Android Keystore 활용이 애플리케이션 구조와 요구사항에 따른 조건부 권고이며, 특정 구조를 전제로 한 확정 방안이 아니라고 명시한다. Keystore가 모든 구성 파일 시나리오에 동일하게 적용된다고 단정할 수 없다.
서버 측 토큰 발급
OWASP M1 대응 방안에서 제시되는 “안전하게 취소 가능한 액세스 토큰” 사용은, 기기에 장기 유효 비밀정보를 두지 않는 원칙과 부합한다. 토큰의 유효 기간을 짧게 잡고 서버 측에서 무효화할 수 있는 구조를 갖추면, 설령 구성 파일이 추출되더라도 공격자가 활용할 수 있는 시간 창이 좁아진다.
5. 수신 트래픽 default-deny와 네트워크 보안 구성 점검
리포트의 점검 프레임워크 중 두 번째 원칙은 “신뢰하지 않는 출처에 대해 기본적으로 거부한다(default-deny)”이다. 이 default-deny의 판단 근거는 수신 트래픽의 출처에 관한 것이며, 구성 값의 출처 신뢰나 다른 탐지 지침으로 확장하지 않는다. 백엔드 서버가 XML 구성에서 수신하는 트래픽이 어떤 출처에서 오는지 검증하는 계층에 이 원칙이 적용된다는 뜻이다.
OWASP Mobile Top 10 2024 M8 “잘못된 보안 구성”은 기본 구성·권한·기본 자격 증명 미검토, 클리어 텍스트 트래픽 허용 등을 취약 환경으로 본다. 대응 방안으로 보안 네트워크 구성 검토(클리어 텍스트 트래픽 금지, 인증서 고정), 프로덕션 디버깅 비활성화, 안드로이드 백업 모드 비활성화를 제시한다. 백업 모드 비활성화는 기기 백업에 앱 데이터(구성 파일 포함)가 포함되지 않도록 하는 조치로, XML 구성 파일이 백업 아카이브로 평문 상태가 유출되는 경로를 차단한다.
6. 구성 값의 파싱·검증: 의도대로 해석되는지 확인하는 절차
리포트의 세 번째 점검 원칙은 “구성 값이 실제로 의도대로 해석되는지 파싱·검증으로 확인한다”이다. XML 구성 파싱·검증에 사용할 언어로 Dart가 지목되며, XML 구성을 Dart로 파싱·검증하는 절차가 포함된다.
다만, 구체적으로 어떤 필드를, 어떤 값 범위와 신뢰 출처 목록 기준으로 검증하는가는 해당 근거 자료에 포함되어 있지 않다. 이 절차의 구체적인 구현 사양(필드 목록, 허용 값 범위, 신뢰 출처 화이트리스트)은 개별 프로젝트의 요구사항 정의 단계에서 별도로 설계해야 한다.
리포트는 한계 중 하나로 특정 보호 조치(서명 검증, obfuscation 등)가 적용된 환경에서의 실효성은 다루지 않는다고 밝혔다. 서명 검증으로 APK 변조를 막고 obfuscation으로 리소스 이름을 가린 환경에서는 역공학 난이도가 상승할 수 있으나, 그 상승폭이 “보안”을 보장하는지는 별도 평가가 필요하다.
7. OWASP Mobile Top 10 2024 관점에서 본 XML 구성 파일 리스크 매핑
아래 표는 XML 구성 파일 패키징 시나리오를 OWASP Mobile Top 10 2024의 항목에 매핑한 것이다. 항목 명칭과 번역 표기는 DoveRunner 2차 해설 기준이며, OWASP 공식 원문과 직접 대조하지는 못했다.
| 리스크 시나리오 (XML 구성 파일 패키징) | OWASP Mobile Top 10 2024 항목 | 근거 |
|---|---|---|
| XML 구성 파일에 API 키 등 장기 유효 비밀정보 평문 포함 | M1 부적절한 자격 증명 사용 | |
| APK 역공학으로 DEX→JAR→Java 소스 복원 후 리소스 XML 추출 | M7 부족한 바이너리 보호 | |
| 클리어 텍스트 트래픽 허용, 백업 모드 비활성화 미적용 | M8 잘못된 보안 구성 | |
| 구성 값 파싱·검증 부재로 의도하지 않은 해석 발생 | M4 부족한 입력/출력 검증 | |
| 하드코딩된 알고리즘 또는 민감 데이터 포함 시 바이너리 공격 취약 | M7 부족한 바이너리 보호 |
2차 출처 한계
위 매핑에 인용된 OWASP 항목 명칭과 대응 방안 서술은 모두 DoveRunner의 2차 해설 블로그(2025-03-14 발행)에서 확인했다. OWASP 공식 원문(owasp.org, mas.owasp.org) 본문 수집이 실패하여 항목 명칭과 번역 표기가 공식 문서와 다를 수 있다. “OWASP 발표 기준”이라는 표기보다는 “2차 해설을 인용한 OWASP Mobile Top 10 2024 기준”으로 이해하는 쪽이 적절하다.
8. 점검 프레임워크 요약
리포트가 제시하는 세 가지 점검 원칙을 정리하면 다음과 같다:
-
앱에 장기 유효 비밀정보를 두지 않는다. XML 구성 파일에 API 키를 하드코딩하지 않으며, 기기에 저장하는 경우에도 안전하게 취소 가능한 액세스 토큰을 고려한다. Android Keystore 활용은 애플리케이션 구조와 요구사항에 따른 조건부 권고이며 확정 방안이 아니다.
-
신뢰하지 않는 출처에 대해 기본적으로 거부한다(default-deny). 이 원칙의 판단 근거는 수신 트래픽의 출처에 관한 것이며, 구성 값의 출처 신뢰나 다른 탐지 지침으로 확장하지 않는다. 백엔드 연계 개발자가 구성 파일을 통해 수신하는 트래픽의 소스 IP·도메인·인증 헤더를 검증하는 계층에 해당한다.
-
구성 값이 실제로 의도대로 해석되는지 파싱·검증으로 확인한다. Dart로 XML 구성을 파싱·검증하는 절차가 포함되며, 구체적 필드·값 범위·신뢰 출처 목록은 이 근거 자료에 포함되어 있지 않아 프로젝트별 설계가 필요하다.
참고 및 한계
해당 리포트의 기술 서술은 Medium 계정 sar1yeva.y의 단일 글에 기반했고, 독립적 교차 검증 자료 없이 작성되었다. 리포트 본문에는 “AI 기술로 작성된 분석 리포트를 포함하고 있다”는 명시도 있다. 원문은 전체 본문 가운데 일부만 수집되어 하드코딩 점검·권한·검증 상세 절의 실제 내용은 확인하지 못했다. 이 글은 확인된 근거 범위 안에서 기술 서술을 재구성한 것이며, 개별 프로젝트에 적용할 때는 원문 전체와 OWASP 공식 원문을 직접 대조해 보는 것을 권장한다.