OWASP Top 10(2025)

OWASP Top 10:2025. 4년 만에 개정된 웹 보안 위협 표준. 새로 추가된 공급망·예외 처리 항목부터 1위 접근 제어까지, 백엔드 개발자가 알아야 할 10가지를 실제 공격 예시와 대응 코드로 정리한다.

---

들어가며

2025년 11월, OWASP가 4년 만에 Top 10을 개정했다.
OWASP Top 10은 웹 애플리케이션 보안 위협을 빈도와 영향도 기준으로 추린 사실상의 업계 표준 문서다.
2021년 판을 기준으로 코드를 짜온 사람이라면, 이번에 바뀐 항목들을 한 번 짚고 넘어갈 필요가 있다.

보안은 "나중에 붙이는 기능"이 아니라 설계 단계부터 고려하는 기본값이다. OWASP Top 10은 그 출발점이다.

이 글에서는 2025년 판 10가지 항목을 무엇이 바뀌었는지와 함께, 각 항목의 실제 공격 예시 + 대응 방법을 코드로 정리한다.
예시는 Java/Spring 기준이다.

참고 — "2023년에도 개정되지 않았나?"
헷갈리기 쉬운데, OWASP에는 여러 종류의 Top 10이 있다.
이 글이 다루는 웹 애플리케이션용 OWASP Top 10은 2017 → 2021 → 2025 순으로 개정됐고,
그 사이(2023년)에 나온 것은 API 전용인 OWASP API Security Top 10 2023으로 별개의 문서다.
API 버전은 별도 글에서 다룬다.

---

2021 → 2025, 무엇이 바뀌었나

이번 개정의 핵심은 "증상이 아니라 근본 원인"에 초점을 맞춘 것이다. 큰 변화는 세 가지다.

• 신규 2개: A03 소프트웨어 공급망 실패, A10 예외 상황 처리 미흡
• 통합: 기존 단독 항목이던 SSRF(서버 측 요청 위조)가 A01 접근 제어로 흡수됨
• 확장: 기존 "취약하고 오래된 컴포넌트"가 "소프트웨어 공급망 실패"로 범위 확대

전체 순위는 다음과 같다.

순위	항목	2021 대비
A01	Broken Access Control (접근 제어 실패)	1위 유지 (+SSRF 흡수)
A02	Security Misconfiguration (보안 설정 오류)	5위 → 2위 ▲
A03	Software Supply Chain Failures (공급망 실패)	확장 ▲
A04	Cryptographic Failures (암호화 실패)	2위 → 4위 ▼
A05	Injection (인젝션)	3위 → 5위 ▼
A06	Insecure Design (안전하지 않은 설계)	4위 → 6위 ▼
A07	Authentication Failures (인증 실패)	7위 유지
A08	Software or Data Integrity Failures (무결성 실패)	8위 유지
A09	Security Logging & Alerting Failures (로깅·알림 실패)	9위 유지
A10	Mishandling of Exceptional Conditions (예외 처리 미흡)	신규 ★

---

A01. Broken Access Control — 접근 제어 실패

3년 연속 1위. 가장 흔하고, 가장 위험하다. 인증(로그인)은 됐지만 인가(권한)가 부실한 경우다.

// 취약: 본인 확인 없이 파라미터의 id를 그대로 신뢰
@GetMapping("/api/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId) {
    return orderRepository.findById(orderId).orElseThrow();
    // orderId만 바꾸면 남의 주문도 조회된다 (IDOR 취약점)
}

orderId=1001을 1002로 바꾸면 남의 주문이 보인다. 이걸 IDOR(Insecure Direct Object Reference)라고 한다.

// 대응: 리소스의 소유자가 요청자 본인인지 검증
@GetMapping("/api/orders/{orderId}")
public Order getOrder(@PathVariable Long orderId,
                      @AuthenticationPrincipal UserDetails user) {
    Order order = orderRepository.findById(orderId).orElseThrow();
    if (!order.getUserId().equals(user.getId())) {
        throw new AccessDeniedException("본인의 주문만 조회할 수 있습니다");
    }
    return order;
}

대응 요약: 모든 리소스 접근에 소유권·권한을 검증한다. 기본은 "거부", 명시적으로 허용된 것만 통과시킨다(deny by default).
이번 판부터 SSRF도 이 카테고리에 포함되므로, 외부 URL을 받아 서버가 요청을 보낼 때는 내부망·메타데이터 주소(예: 196.254.169.254)를 차단해야 한다.

---

A02. Security Misconfiguration — 보안 설정 오류

5위에서 2위로 크게 올랐다. 설정 기반 동작이 늘면서 misconfiguration도 함께 늘었다.
기본 비밀번호, 불필요하게 열린 디버그 모드, 과도한 에러 노출 등이 해당된다.

# 취약: 운영 환경에서 상세 에러와 디버그 노출
server:
  error:
    include-stacktrace: always   # 스택트레이스가 사용자에게 노출
spring:
  h2:
    console:
      enabled: true              # 운영에 H2 콘솔이 열려 있음

# 대응: 운영 프로파일에서는 최소 정보만
server:
  error:
    include-stacktrace: never
    include-message: never
spring:
  h2:
    console:
      enabled: false

대응 요약: 운영/개발 설정을 프로파일로 분리하고, 기본 계정·샘플 페이지·불필요한 포트를 제거한다.
보안 헤더(HSTS, X-Content-Type-Options 등)를 기본 적용한다.

---

A03. Software Supply Chain Failures — 공급망 실패 (신규)

이번에 가장 주목받은 신규 항목. 내가 짠 코드가 아니라 내가 가져다 쓴 의존성에서 사고가 난다.
오픈소스 라이브러리, 빌드 시스템, 배포 인프라 전체가 공격 표면이다. Log4Shell이 대표적 사례다.

# 대응 1: 의존성 취약점 스캔을 빌드에 포함
./gradlew dependencyCheckAnalyze   # OWASP Dependency-Check

# 대응 2: 알려진 취약점 확인
npm audit

// 대응 3: 의존성 버전 고정 + 출처 검증
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web:3.4.1")
    // 버전을 명시적으로 고정 (latest, + 같은 동적 버전 금지)
}

대응 요약: 의존성 버전을 고정하고, CI에 취약점 스캔(Dependency-Check, Snyk, Dependabot)을 넣는다.
SBOM(소프트웨어 자재 명세서)을 관리해 무엇을 쓰고 있는지 추적한다.

---

A04. Cryptographic Failures — 암호화 실패

민감 데이터를 평문으로 저장하거나, 약한 알고리즘을 쓰는 경우다. 비밀번호를 단순 해싱하는 게 대표적 실수다.

// 취약: SHA-256 단순 해싱 (레인보우 테이블에 취약, 너무 빠름)
String hashed = DigestUtils.sha256Hex(password);

// 대응: bcrypt 같은 느린 해시 + 자동 솔트
@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();   // 솔트 자동 생성, 의도적으로 느림
}

// 사용
String hashed = passwordEncoder.encode(rawPassword);
boolean matches = passwordEncoder.matches(rawPassword, hashed);

대응 요약: 비밀번호는 bcrypt/Argon2 같은 적응형 해시로 저장한다.
전송 구간은 TLS, 저장 데이터는 AES-256으로 암호화한다.
MD5·SHA-1·DES 같은 약한 알고리즘은 쓰지 않는다.

---

A05. Injection — 인젝션

SQL Injection, XSS 등을 포함한다. 사용자 입력을 코드/쿼리의 일부로 신뢰할 때 발생한다.

// 취약: 문자열 결합으로 쿼리 생성
String sql = "SELECT * FROM users WHERE email = '" + email + "'";
// email에 "' OR '1'='1" 를 넣으면 전체 행이 노출된다

// 대응: 파라미터 바인딩 (PreparedStatement / JPA)
@Query("SELECT u FROM User u WHERE u.email = :email")
User findByEmail(@Param("email") String email);   // 값으로만 처리됨

대응 요약: 쿼리는 항상 파라미터 바인딩으로 만든다.
문자열 결합 금지. ORM을 써도 네이티브 쿼리·JPQL 동적 결합에서 뚫릴 수 있으니 주의한다. XSS는 출력 시 이스케이프 처리한다.

---

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

코드 버그가 아니라 설계 자체의 결함이다. 예를 들어 비밀번호 재설정에 횟수 제한이 없으면, 구현이 완벽해도 무차별 대입에 뚫린다.

// 대응 예: 민감한 기능에 비율 제한(rate limit) 설계 반영
@RateLimiter(name = "passwordReset", fallbackMethod = "tooManyRequests")
public void requestPasswordReset(String email) {
    // 분당 N회로 제한 → 무차별 시도 차단
}

대응 요약: 설계 단계에서 위협 모델링(threat modeling)을 한다.
"이 기능이 악용되면 어떻게 될까"를 먼저 묻고, 비율 제한·다단계 인증·최소 권한을 설계에 포함한다.

---

A07. Authentication Failures — 인증 실패

약한 비밀번호 허용, 세션 관리 미흡, 무차별 대입 방어 부재 등. 이전 글의 JWT 인증과도 직결된다.

// 대응: 로그인 실패 횟수 제한 + 계정 잠금
public void login(String email, String password) {
    if (loginAttemptService.isBlocked(email)) {
        throw new LockedException("로그인 시도가 너무 많습니다. 잠시 후 다시 시도하세요");
    }
    if (!passwordEncoder.matches(password, user.getPassword())) {
        loginAttemptService.recordFailure(email);  // 실패 카운트
        throw new BadCredentialsException("인증 실패");
    }
    loginAttemptService.reset(email);
}

대응 요약: 다단계 인증(MFA)을 제공하고, 로그인 실패 제한·세션 타임아웃·안전한 토큰 관리를 적용한다.
검증된 인증 프레임워크(Spring Security 등)를 쓰는 것이 직접 구현보다 안전하다.

---

A08. Software or Data Integrity Failures — 무결성 실패

검증되지 않은 출처의 코드·데이터를 신뢰할 때 발생한다.
서명 검증 없는 자동 업데이트, 신뢰할 수 없는 데이터의 역직렬화 등이 해당된다.

// 취약: 신뢰할 수 없는 데이터를 그대로 역직렬화
ObjectInputStream in = new ObjectInputStream(untrustedInput);
Object obj = in.readObject();   // 역직렬화 가젯 공격에 취약

대응 요약: 외부 데이터는 역직렬화하지 않거나, 허용 목록(allowlist) 기반으로만 처리한다.
업데이트·아티팩트는 디지털 서명으로 무결성을 검증한다. CI/CD 파이프라인의 접근 권한도 통제한다.

---

A09. Security Logging & Alerting Failures — 로깅·알림 실패

이번에 이름이 "모니터링"에서 "알림"으로 바뀌었다.
로그만 쌓고 알림이 없으면 침해를 제때 발견하지 못한다는 점을 강조한 것이다.

// 대응: 보안 이벤트를 구조화해서 기록 + 알림 연동
log.warn("AUTH_FAILURE user={} ip={} attempts={}",
         email, clientIp, attemptCount);
// 임계치 초과 시 Slack/PagerDuty로 알림 발송하도록 연동

대응 요약: 로그인 실패, 권한 거부, 입력 검증 실패 같은 보안 이벤트를 기록한다.
단, 로그에 비밀번호·토큰·개인정보를 남기지 않는다.
그리고 핵심은 임계치 초과 시 실제로 알림이 가도록 연동하는 것이다.

---

A10. Mishandling of Exceptional Conditions — 예외 처리 미흡 (신규)

이번에 새로 추가된 항목. 잘못된 에러 처리, 논리 오류, "실패 시 열림(fail open)" 같은 비정상 상황 대응 결함이다.

// 취약: 권한 검사 중 예외가 나면 통과시켜 버림 (fail open)
public boolean hasPermission(User user, Resource res) {
    try {
        return permissionService.check(user, res);
    } catch (Exception e) {
        return true;   // 예외 시 허용 → 치명적
    }
}

// 대응: 실패 시 안전한 쪽으로 닫는다 (fail secure)
public boolean hasPermission(User user, Resource res) {
    try {
        return permissionService.check(user, res);
    } catch (Exception e) {
        log.error("권한 검사 실패, 접근 거부 처리", e);
        return false;   // 예외 시 거부 (fail closed)
    }
}

대응 요약: 보안 결정은 예외가 나면 거부 쪽으로 닫는다(fail secure).
에러 메시지에 내부 정보를 노출하지 않고, 모든 비정상 경로를 명시적으로 처리한다.

---

마치며

OWASP Top 10:2025의 메시지는 분명하다. 증상이 아니라 근본 원인을 보라.
공급망 실패와 예외 처리 미흡이 새로 들어온 것도, 개별 버그보다 "설계와 프로세스 차원의 결함"이 더 위험해졌다는 신호다.

10가지를 다 한 번에 적용할 필요는 없다. 우선순위는 분명하다.
접근 제어(A01), 보안 설정(A02), 의존성 관리(A03)부터 점검하는 게 효율적이다.
이 셋이 지금 가장 흔하게 뚫리는 지점이다.

보안은 한 번 짜고 끝나는 게 아니라 계속 점검하는 과정이다.
새 기능을 추가할 때마다 "이게 악용되면 어떻게 될까"를 한 번씩 떠올리는 습관이, 그 어떤 도구보다 효과적인 방어다.

---

참고 출처

• OWASP Top 10:2025 공식 — https://owasp.org/Top10/2025/
• OWASP Cheat Sheet Series — https://cheatsheetseries.owasp.org/
• Spring Security Reference — https://docs.spring.io/spring-security/reference/