Skip to main content
LadeStack LogoLadeStack
Security in Web Apps 약 24분 소요 2024년 11월 17일

OWASP Top 10: 현대 웹 애플리케이션 보안 취약점 완벽 대응 가이드 (2025년 개정판)

공식 OWASP Top 10:2025 10대 카테고리 심층 분석: 근본 원인 분석, 코드 레벨 완화 전략, 소프트웨어 공급망 보안, 심층 방어 아키텍처 완벽 해설.

OWASP Top 10:2025 웹 애플리케이션 보안 아키텍처 다이어그램

1. 컴플라이언스 체크리스트를 넘어서: 시스템 아키텍처로서의 애플리케이션 보안

OWASP Top 10:2025는 현대 웹 애플리케이션, 분산 API 및 클라우드 네이티브 환경을 위협하는 가장 치명적인 보안 위험을 정의하는 최신 국제 표준 문서입니다. 그러나 수많은 개발 조직이 “OWASP Top 10 항목을 단순 체크리스트로 처리하면 충분하다”는 치명적인 함정에 빠지곤 합니다.

자동화 취약점 스캐너에서 경고가 발견되지 않았다고 해서 시스템의 무결성이 보장되는 것은 아닙니다. Top 10은 반복적으로 나타나는 중대한 아키텍처 결함 패턴의 색인입니다. 진정한 애플리케이션 보안은 심층 방어(Defense-in-Depth), 보안 개발 수명주기(Secure SDLC)의 내재화, 지속적인 위협 모델링(Threat Modeling), 그리고 전체 기술 스택 전반에 걸친 엄격한 경계 검증을 통해서만 달성됩니다.

+--------------------------------------------------------------------------+
|                        심층 방어(Defense-in-Depth) 모델                  |
+------------------------------------+-------------------------------------+
                                     |
    계층 1: 네트워크 및 엣지          v
    [ WAF / DDoS 완화 / TLS 1.3 / 인그레스 속도 제한 ]
                                     |
    계층 2: 전송 및 게이트웨이        v
    [ API 게이트웨이 / OAuth 2.0 & OIDC 검증 / 상호 TLS (mTLS) ]
                                     |
    계층 3: 애플리케이션 및 비즈니스  v
    [ 엄격한 입력 검증 / 파라미터화된 쿼리 / RBAC 및 ABAC 인가 ]
                                     |
    계층 4: 데이터 및 스토리지        v
    [ 컬럼 수준 암호화 / 최소 권한 DB 역할 / 클라우드 Vault 시크릿 관리 ]

2. 공식 OWASP Top 10:2025 카테고리 상세 해설 및 기술적 완화책

아래 섹션에서는 공식 OWASP Top 10:2025의 10대 카테고리(A01:2025 ~ A10:2025)를 근본 원인 분석, 개발자 친화적 보안 코드 예시, 예방적 엔지니어링 전략과 함께 심층적으로 분석합니다.


A01:2025 – Broken Access Control (접근 제어 실패)

접근 제어 실패는 2025년 표준에서도 1위의 보안 위험으로 유지되었습니다. 인가(Authorization) 정책이 누락되거나 잘못 구성되었거나 클라이언트 측 검증에 의존할 때 발생하며, 공격자가 비인가 데이터에 접근하거나 최고 관리자 권한을 탈취하도록 허용합니다. 2025년 개정판에서는 서버 측 요청 위조(SSRF)가 내부 네트워크 및 클라우드 메타데이터 서비스(IMDS)에 대한 접근 제어 우회 공격으로 본 카테고리에 공식 통합되었습니다.

  • 대표적 근본 원인:
    • 안전하지 않은 직접 객체 참조(IDOR): 테넌트 권한 검증 없이 클라이언트가 전달한 객체 ID를 그대로 신뢰.
    • 기능 수준 접근 제어 누락: 권한 검사 없이 관리자 엔드포인트(/admin/deleteUser)를 노출.
    • SSRF를 통한 메타데이터 접근: 사설 IP 대역(RFC 1918) 및 클라우드 메타데이터(IMDS) 차단 없이 사용자 제공 URL을 그대로 호출.
  • 보안 아키텍처: 데이터베이스 쿼리 레벨에서 일관되게 강제되는 중앙집중식 인가 제어(RBAC 또는 ABAC).
// 안전한 구현 예시: 쿼리 레벨에서 테넌트 소유권 및 사용자 권한 강제
async function getUserInvoice(invoiceId: string, authenticatedUserId: string, authenticatedTenantId: string) {
  // invoiceId 단독 조회 금지; 항상 테넌트 ID와 사용자 ID를 함께 바인딩
  const invoice = await db.query(
    `SELECT id, amount, status, created_at 
     FROM invoices 
     WHERE id = $1 AND user_id = $2 AND tenant_id = $3`,
    [invoiceId, authenticatedUserId, authenticatedTenantId]
  );

  if (!invoice.rows.length) {
    throw new NotFoundOrForbiddenException('리소스가 존재하지 않거나 접근이 거부되었습니다');
  }

  return invoice.rows[0];
}

A02:2025 – Security Misconfiguration (보안 구성 오류)

2025년 개정판에서 2위로 상승한 보안 구성 오류는 멀티 클라우드, 컨테이너 오케스트레이션, 마이크로서비스 메시의 복잡성 증대에 따른 위험을 반영합니다. 불안전한 기본값 설정이나 불완전한 시스템 하드닝이 치명적인 침투 경로를 제공합니다.

  • 대표적 근본 원인:
    • 운영 데이터베이스 및 미들웨어의 기본 관리자 계정 자격 증명 방치.
    • 스택 트레이스, 데이터베이스 스키마, 환경 변수를 그대로 노출하는 과도한 에러 디버그 메시지.
    • 무제한 공개된 클라우드 스토리지 버킷, root 권한으로 실행되는 Kubernetes 파드, 보안 HTTP 헤더 누락.
  • 효과적인 완화책:
    • 코드형 인프라(Terraform, OpenTofu, Pulumi)를 통한 인프라 보안 구성 자동화.
    • 운영 빌드에서 디버그 엔드포인트와 스택 트레이스를 완전히 제거하고 모호한 에러 ID로 매핑.
    • 포괄적인 HTTP 보안 응답 헤더 강제 적용:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

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

2025년 표준에서 가장 두드러진 신규 카테고리로, 기존 “취약하고 오래된 컴포넌트”를 공급망 전체로 전면 확장했습니다. 악성 패키지 삽입, 침해된 서드파티 라이브러리, 오염된 CI/CD 빌드 파이프라인, 의존성 혼동(Dependency Confusion), 빌드 산출물 추적성 결여 문제를 포괄합니다.

  • 대표적 근본 원인:
    • 공용 레지스트리(npm, PyPI)에서 검증되지 않은 패키지나 타이포스쿼팅 라이브러리 무단 도입.
    • 커밋 SHA를 고정하지 않고 변경 가능한 브랜치 참조(예: uses: actions/checkout@v4)로 실행되는 CI/CD 액션.
    • 소프트웨어 자재명세서(SBOM) 자동 생성 및 취약점 추적 체계 부재.
  • 효과적인 완화책:
    • 암호학적으로 검증된 락파일(package-lock.json, pnpm-lock.yaml)을 강제하고 빌드 시 체크섬 검증.
    • CI/CD 파이프라인에서 지속적인 소프트웨어 구성 분석(SCA) 강제(Trivy, Snyk, Dependabot).
    • 외부 CI/CD 액션을 40자리 전체 커밋 SHA로 고정.
    • 기계 판독 가능한 SBOM(CycloneDX / SPDX)을 생성하고 Sigstore/Cosign으로 릴리스 산출물 전자 서명.
# 커밋 SHA 고정 및 취약점 스캔을 포함한 GitHub Actions 파이프라인 예시
- name: Checkout Code
  uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- name: Run Trivy Vulnerability Scanner
  uses: aquasecurity/trivy-action@d43c1f16c00cfd3978dde6c07f4bbcf9eb6993ca
  with:
    scan-type: 'fs'
    ignore-unfixed: true
    severity: 'CRITICAL,HIGH'

A04:2025 – Cryptographic Failures (암호화 실패)

전송 중, 저장 중, 메모리 처리 중인 민감 데이터를 적절한 암호화 원시값과 안전한 키 관리 아키텍처로 보호하지 못해 발생하는 취약점입니다.

  • 대표적 근본 원인:
    • 비밀번호 해싱 및 무결성 검증에 취약한 구형 알고리즘(MD5, SHA1) 사용.
    • 인증되지 않은 대칭 암호 모드 사용(인증 모드인 GCM 대신 취약한 ECB 모드 AES 사용).
    • 소스코드 내 암호화 키 하드코딩 및 평문 비밀정보 커밋.
  • 효과적인 완화책:
    • 비밀번호: 최신 메모리 집약 알고리즘만 사용: Argon2id(권장), scrypt 또는 높은 비용 인자의 bcrypt.
    • 전송 데이터: Forward Secrecy를 제공하는 TLS 1.3을 강제하고 구형 암호화 스위트 비활성화.
    • 저장 데이터: AES-256-GCM 또는 ChaCha20-Poly1305를 봉투 암호화 방식으로 적용하고 클라우드 KMS 또는 Vault로 키 순환 관리.

A05:2025 – Injection (인젝션)

신뢰할 수 없는 사용자 입력값이 실행 엔진(SQL, NoSQL, OS 쉘, LDAP, XPath, GraphQL)에 의해 명령어나 쿼리 구문으로 해석되어 실행되는 취약점입니다.

  • 대표적 근본 원인:
    • SQL 쿼리 생성 시 문자열 연결 방식 사용("SELECT * FROM users WHERE name = '" + input + "'").
    • 검증되지 않은 사용자 입력을 시스템 쉘 명령어로 직접 전달(child_process.exec("ping " + host)).
  • 효과적인 완화책:
    • 파라미터화된 쿼리(Prepared Statements) 또는 타입 세이프 ORM 전면 사용.
    • 스키마 검증 라이브러리(Zod, JSON Schema)를 통한 엄격한 경계 입력값 검증.
    • HTML, JavaScript, CSS 렌더링 시 컨텍스트 맞춤형 출력 인코딩 적용.
// 안전한 구현 예시: 파라미터화된 쿼리를 통한 인젝션 원천 차단
const result = await pool.query(
  'SELECT id, email, role FROM users WHERE email = $1 AND active = $2',
  [sanitizedEmail, true]
);

A06:2025 – Insecure Design (안전하지 않은 설계)

요구사항 정의 및 아키텍처 설계 단계에서 보안 고려가 누락되어 단순한 코드 패치로는 해결할 수 없는 근본적인 구조적 결함 및 비즈니스 로직 취약점입니다.

  • 대표적 근본 원인:
    • 제한 없는 비즈니스 흐름(속도 제한 없는 비밀번호 재설정 또는 OTP 검증).
    • 내부 마이크로서비스 간 통신은 무조건 안전하다는 위험한 가정(Zero Trust 아키텍처 부재).
    • 주요 금융 트랜잭션 및 계정 생성에 대한 자동화 공격 방어책 부재.
  • 효과적인 완화책:
    • 설계 단계에서 STRIDE 위협 모델링(신원 도용, 데이터 변조, 부인, 정보 유출, 서비스 거부, 권한 상승) 수행.
    • 안전한 기본값(Secure Defaults) 원칙 적용: 실패 시 닫힘(Fail-Closed) 정책 및 중요 기능 다요소 인증 강제.

A07:2025 – Authentication Failures (인증 실패)

기존 “식별 및 인증 실패”에서 명칭이 정제되었으며, 인증 프로토콜 약점, 세션 탈취, 자격 증명 검증 결함에 집중합니다.

  • 대표적 근본 원인:
    • 복잡도 검증이나 유출 데이터베이스(HaveIBeenPwned) 대조 없이 취약한 비밀번호 허용.
    • 안전하지 않은 세션 관리: 예측 가능한 세션 ID, 토큰 순환 부재, 로그아웃 후 세션 미파기.
    • 관리자 계정의 다요소 인증(MFA) 미적용.
  • 효과적인 완화책:
    • TOTP(RFC 6238) 또는 FIDO2/WebAuthn 하드웨어 키를 통한 다요소 인증 의무화.
    • 암호학적으로 안전한 무작위 난수(최소 128비트 엔트로피) 세션 쿠키(HttpOnly; Secure; SameSite=Strict) 사용.
    • OAuth 2.0 / OpenID Connect 구현 시 PKCE(S256) 기반 인가 코드 흐름 적용.

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

소프트웨어 업데이트, 중요 데이터 파이프라인, 직렬화된 객체에 대해 암호학적 무결성 검증 없이 신뢰함으로써 발생하는 보안 실패입니다.

  • 대표적 근본 원인:
    • 안전하지 않은 역직렬화(Insecure Deserialization): 신뢰할 수 없는 원격 바이너리 객체를 그대로 역직렬화하여 실행.
    • 암호화되지 않은 HTTP를 통해 바이너리를 다운로드하거나 전자서명을 검증하지 않는 자동 업데이트.
    • 서명되지 않은 JWT(alg: "none") 허용 또는 알고리즘 혼동 공격(RS256 vs HS256) 방치.
  • 효과적인 완화책:
    • 신뢰할 수 없는 데이터의 원시 바이너리 역직렬화를 전면 금지하고 스키마 기반 엄격한 JSON 파싱 적용.
    • 외부 바이너리 및 컨테이너 이미지 실행 전 전자서명과 해시 다이제스트 검증.
    • JWT 검증 라이브러리에서 허용 알고리즘 화이트리스트 명시적 지정.

A09:2025 – Security Logging and Alerting Failures (보안 로깅 및 경고 실패)

2025년 개정판에서 명칭이 변경되어, 단순한 로그 저장에 그치지 않고 **능동적이며 즉각 조치 가능한 경고(Alerting)**가 동반되지 않으면 침해 사고를 막을 수 없음을 명시했습니다. 모니터링되지 않는 텍스트 파일에 로그가 방치되어 침해 사고를 수개월간 인지하지 못하는 사태를 방지합니다.

  • 대표적 근본 원인:
    • 로그인 실패, 권한 상승, 인가 거부 등 고위험 보안 이벤트 기록 누락.
    • 평문 비밀번호, 세션 토큰, 결제 정보 등 민감 데이터를 애플리케이션 로그에 출력.
    • 공격자가 흔적을 삭제할 수 있는 웹 서버 로컬 디스크에만 로그 보관.
  • 효과적인 완화책:
    • 타임스탬프, 이벤트 유형, 액터 ID, 클라이언트 IP, 상관관계 추적 ID를 포함한 구조화된 JSON 감사 로그 생성.
    • 위변조가 불가능한 중앙 집중식 SIEM(Elasticsearch, Splunk, Datadog)으로 로그 실시간 전송.
    • 비정상 행위 발생 시 실시간 자동 경보 설정(예: 동일 IP 대역에서 60초 내 10회 이상 로그인 실패 시 경보).

A10:2025 – Mishandling of Exceptional Conditions (예외 조건의 부적절한 처리)

OWASP Top 10:2025에서 신설된 핵심 카테고리입니다(기존 SSRF가 접근 제어 실패로 통합되면서 10위에 신규 배정). 에러 핸들링 결함, 미처리 예외, 예상치 못한 경계 조건, 그리고 실패 시 열림(Fail-Open) 상태로 인한 취약점을 다룹니다.

  • 대표적 근본 원인:
    • 실패 시 열림 상태(Fail-Open): 인증 및 인가 필터가 예기치 않은 입력(null 포인터, 비정상 토큰)으로 인해 예외를 던지며 크래시될 때, 보안 검사를 생략하고 요청을 그대로 통과시키는 결함.
    • 경쟁 조건(Race Conditions) 및 상태 불일치: 검사 시점과 사용 시점(TOCTOU) 사이의 간극을 악용하여 동시 요청으로 잔액을 중복 인출하거나 제한을 우회하는 공격.
    • 자원 고갈(Resource Exhaustion): 무제한 작업에 대한 메모리, CPU, 연결 타임아웃 미설정으로 인한 서비스 거부(DoS).
  • 효과적인 완화책:
    • 실패 시 닫힘(Fail-Closed) 아키텍처 구현: 미처리 예외나 필터 오류 발생 시 요청을 통과시키지 않고 즉시 접근 거부(HTTP 500/403) 응답 반환.
    • 상태 전이 중 경쟁 조건을 방지하기 위해 데이터베이스 행 잠금(SELECT FOR UPDATE) 또는 분산 락(Redis Redlock) 적용.
    • 모든 외부 I/O 작업에 엄격한 자원 할당량, 요청 바디 크기 제한, 소켓 타임아웃 구성.
// 안전한 구현 예시: 실패 시 닫힘(Fail-Closed) 원칙을 준수하는 인가 미들웨어
export async function enforcePolicyMiddleware(req: Request, res: Response, next: NextFunction) {
  let isAuthorized = false; // 기본값은 거부 (Fail-Closed)

  try {
    const user = extractAuthenticatedUser(req);
    isAuthorized = await policyEngine.evaluate(user, req.path, req.method);
  } catch (error) {
    // 예기치 못한 예외를 상관 ID와 함께 안전하게 로깅
    logger.error('인가 정책 엔진 평가 중 예기치 못한 크래시 발생', { error, path: req.path });
    isAuthorized = false; // 크래시 발생 시에도 인가를 명시적으로 거부 유지
  }

  if (!isAuthorized) {
    return res.status(403).json({ error: '접근 거부됨: 보안 정책에 의해 요청이 거절되었습니다' });
  }

  next();
}

3. 역사적 변천 비교: OWASP Top 10 2021 vs. 2025

2021년 카테고리 2025년 카테고리 주요 구조적 변화
A01:2021 – Broken Access Control A01:2025 – Broken Access Control 1위 유지; SSRF를 접근 제어 우회 메커니즘으로 공식 통합.
A05:2021 – Security Misconfiguration A02:2025 – Security Misconfiguration 멀티 클라우드, 컨테이너, 마이크로서비스 확산으로 인해 2위로 상승.
A06:2021 – Vulnerable and Outdated Components A03:2025 – Software Supply Chain Failures 단순 라이브러리 관리를 넘어 CI/CD 파이프라인과 SBOM을 포괄하는 공급망 전체로 전면 확장.
A02:2021 – Cryptographic Failures A04:2025 – Cryptographic Failures 4위로 이동; 민감 데이터 보호, 최신 암호 스위트, KMS 키 관리 요건 유지.
A03:2021 – Injection A05:2025 – Injection 5위로 하향; 파라미터화된 쿼리 및 엄격한 스키마 검증 필수성 유지.
A04:2021 – Insecure Design A06:2025 – Insecure Design 6위로 이동; 코딩 전 STRIDE 위협 모델링과 안전한 기본 설계 원칙 강조.
A07:2021 – Identification and Authentication Failures A07:2025 – Authentication Failures 명칭 간소화; MFA(TOTP/WebAuthn), 세션 엔트로피, PKCE 적용 의무화.
A08:2021 – Software and Data Integrity Failures A08:2025 – Software or Data Integrity Failures 서명되지 않은 산출물, 위험한 역직렬화, 파이프라인 무결성 검증에 집중.
A09:2021 – Security Logging and Monitoring Failures A09:2025 – Security Logging and Alerting Failures 침해의 장기화를 차단하기 위해 실행 가능한 실시간 경고의 중요성 강조.
A10:2021 – Server-Side Request Forgery (SSRF) A10:2025 – Mishandling of Exceptional Conditions 에러 처리 및 실패 시 열림을 다루는 신규 10위. SSRF는 A01로 통합.

4. 자동화 취약점 스캐너의 한계

동적 애플리케이션 보안 테스팅(DAST)과 정적 코드 분석(SAST) 도구는 유용한 진단을 제공하지만, 단독으로는 완벽한 보안을 보장할 수 없습니다:

  1. 비즈니스 로직 취약점: 스캐너는 인증된 사용자가 타인의 계좌 잔액을 수정하거나 테넌트 경계를 넘나들 수 있는지 판단하지 못합니다.
  2. 컨텍스트 없는 인가 검증: 자동화 도구는 공개 리소스와 테넌트 전용 민감 리소스를 스스로 구별하기 어렵습니다.
  3. 경보 피로와 거짓 음성: 수백 개의 사소한 경고가 엔지니어의 주의를 분산시켜 치명적인 구조적 결함을 간과하게 만듭니다.

완벽한 애플리케이션 보안은 자동화 스캔과 함께 인간 전문가의 위협 모델링, 엄격한 코드 리뷰, 주기적인 독립 모의해킹(Penetration Testing)을 융합해야만 달성됩니다.


요약 OWASP Top 10:2025 검증 체크리스트

  • A01 접근 제어 실패: 테넌트별 쿼리 레벨 인가 강제, SSRF 아웃바운드 차단 필터링.
  • A02 보안 구성 오류: IaC 하드닝 적용, 운영 환경 디버그 정보 차단, CSP 및 HSTS 활성화.
  • A03 소프트웨어 공급망 실패: 락파일 무결성 검증, CI/CD 액션 커밋 SHA 고정, SBOM 생성.
  • A04 암호화 실패: Argon2id/bcrypt 비밀번호 해싱, TLS 1.3 강제, 봉투 암호화 적용.
  • A05 인젝션: 파라미터화된 SQL 쿼리 의무화, 엄격한 스키마 검증, 문자열 연결 금지.
  • A06 안전하지 않은 설계: STRIDE 위협 모델링 도입, 트랜잭션 흐름 안전한 기본값 설정.
  • A07 인증 실패: 다요소 인증 의무화, 높은 엔트로피의 HttpOnly; Secure; SameSite=Strict 쿠키.
  • A08 소프트웨어 또는 데이터 무결성 실패: 바이너리 역직렬화 금지, Cosign 기반 산출물 서명.
  • A09 보안 로깅 및 경고 실패: 구조화된 JSON 로깅, 위변조 방지 SIEM 연동, 실시간 자동 경보.
  • A10 예외 조건의 부적절한 처리: Fail-Closed 예외 처리, 동시성 락, 자원 할당량 제한.

공식 참고 자료 (2026년 10월 검증)

More Engineering Articles