OWASP Top 10:2025: 웹 보안 위험을 개발 점검으로 바꾸기

1장 개념과 보호 목표#

OWASP Top 10은 주요 웹 애플리케이션 보안 위험을 알리는 문서입니다. 전체 보안 요구사항이나 인증 규격은 아니므로 목록에 없는 문제까지 배제하는 근거로 사용할 수 없습니다. 이 글은 2025판을 기준으로 설명합니다.

2장 원리와 구분#

2025판에서는 접근통제 실패, 보안 설정 오류, 소프트웨어 공급망 실패, 암호화 실패, 인젝션, 안전하지 않은 설계, 인증 실패, 소프트웨어·데이터 무결성 실패, 보안 로그·알림 실패, 예외 상황의 잘못된 처리를 다룹니다. 2021판의 번호를 그대로 가져오면 분류가 달라 혼동이 생깁니다.

예외 상황의 잘못된 처리는 오류가 발생했을 때 인증 검사가 건너뛰어지거나 작업 상태가 일부만 반영되는 등의 문제를 포함해 검토할 수 있습니다. 실패 시 기본 거부, 거래의 일관성과 자원 해제를 검증합니다. 공급망 점검은 의존성 취약점 목록 외에 패키지 출처·빌드 권한·업데이트 경로까지 확인해야 합니다.

3장 위험 목록을 출시 전 검증으로 바꾸기#

각 위험에 대상 기능·실패 시나리오·기대 결과·담당자·증거를 연결합니다. 위험 이름을 문서에 적는 것과 실제 요청이 거부되는 것은 다릅니다. 하나의 기능이 여러 범주에 관련될 수 있어 팀별로 목록을 나누고 경계의 문제를 놓치지 않아야 합니다.

flowchart LR
 R["위험 범주"] --> F["우리 서비스의 기능"]
 F --> S["실패·남용 시나리오"]
 S --> T["코드·설정·운영 검증"]
 T --> E["결과·수정·재검증"]

4장 A01·A02: 권한과 설정은 연결되지만 다르다#

접근통제는 누가 어떤 객체·필드·기능을 사용할 수 있는지, 설정은 관리 경로·계정·공개 범위·허용 옵션이 무엇인지를 봅니다. 비공개 API라도 권한 검증은 필요하고 인가 코드가 맞아도 공개 스토리지의 잘못된 설정은 데이터를 노출할 수 있습니다.

일반 사용자·다른 조직의 직접 요청과 실제 배포 설정을 각각 시험합니다. 개발 환경의 안전한 결과를 운영 설정까지 확대해서 기록하지 않습니다.

5장 A03·A08: 공급망과 무결성의 연결#

의존성·패키지 출처·빌드·배포 권한·업데이트 경로를 조사합니다. 무결성은 산출물·중요 데이터가 정당한 값인지 검증하는 요구와 연결됩니다. SBOM의 존재는 취약점 조치나 진본 검증이 완료되었다는 뜻이 아닙니다.

CI의 비밀·승인·서명·산출물 보관과 실제 배포 버전을 연결합니다. 업데이트에서 검증을 우회하거나 임의의 외부 코드를 실행하는 경로가 없는지 확인합니다.

6장 A04·A05: 암호화와 인젝션을 구분한다#

암호화 실패는 보호할 데이터·키·모드·전송과 관련됩니다. 인젝션은 외부 데이터가 SQL·명령·템플릿 등 실행 문법으로 해석되는 경계입니다. DB를 암호화해도 취약한 SQL 입력 경로가 수정되지는 않습니다.

파라미터 바인딩·안전한 API·문맥 처리를 적용하고 암호는 별도의 키·Nonce·태그·오류 시험을 수행합니다. 같은 코드의 여러 위험을 하나의 제품 도입으로 해결했다고 보지 않습니다.

7장 A06: 설계에서 빠진 남용을 찾는다#

정상 입력만 처리하도록 만든 기능도 대량 예약·쿠폰 반복·재시도·경쟁 요청에 악용될 수 있습니다. 신뢰 경계·상태·한도·승인과 실패 시나리오를 요구사항으로 정합니다. 특정 악성 문자열이 없다고 업무가 안전한 것은 아닙니다.

위협 모델과 상태 전이를 테스트로 연결합니다. 코드 수정 전에 기능의 허용 범위와 업무 의미를 합의해야 같은 문제가 다른 경로에서 반복되지 않습니다.

8장 A07: 로그인·복구·세션은 하나의 흐름이다#

비밀번호·MFA·패스키뿐 아니라 계정 복구·새 인증 수단 등록·세션 만료와 회수를 봅니다. 강한 로그인 뒤 약한 복구로 모든 통제를 해제할 수 있는지, 로그인한 일반 계정의 업무 권한이 정확한지도 확인합니다.

정상 로그인 성공과 인증 실패, 탈취 세션, 권한 변경 후 기존 토큰의 동작을 구분해 검증합니다. 인증 도구의 통과를 객체 인가까지 완료한 결과로 기록하지 않습니다.

9장 A09: 조사할 수 있는 로그와 알림#

비정상 로그인·권한 변경·중요 내보내기·실패 상태를 필요한 식별자로 연결합니다. 로그가 많아도 시각·사용자·자산이 연결되지 않으면 사건을 이해하기 어렵습니다. 비밀·개인정보의 과도한 기록도 제한합니다.

수집 지연·누락·변조·경보 전달 실패를 시험합니다. 경보가 울렸을 때 담당자가 필요한 증거와 조치로 이어갈 수 있는지까지 확인해야 운영 검증이 됩니다.

10장 A10: 오류가 권한을 열지 않게 한다#

인증 서버·DB·외부 결제가 실패해도 권한 검사를 건너뛰거나 일부 거래를 정상 완료로 등록하지 않아야 합니다. 실패 시 기본 거부, 자원 해제와 상태 일관성의 조건을 정합니다. 예외를 무조건 삼키는 구현은 안전한 처리가 아닙니다.

외부 결제 성공 / 주문 저장 실패
인가 조회 시간 초과
파일 검사 중단 / 공개 상태 변경
동시 요청 / 중복 지급
각 상태의 허용·거부·보상·재시도를 설계

11장 주문 API 하나로 여러 범주를 검증한다#

주문 소유권은 A01, 질의 바인딩은 A05, 중복 주문과 비용 제한은 A06, 결제 실패 후 상태는 A10에 연결할 수 있습니다. 실제 기능을 중심으로 시험하면 위험 분류를 외우는 데서 벗어나 어떤 증거가 필요한지 알 수 있습니다.

자동 스캐너 결과와 설계·업무 인가·동시성의 수동 검증을 함께 사용합니다. 목록에 없는 서비스 고유의 위험도 추가해야 하며 Top 10은 모든 보안 요구의 완성 목록이 아닙니다.

12장 적용 사례와 운영 방법#

개발팀은 위험 이름을 코드·설정·운영의 확인 항목으로 바꿔야 합니다. 접근통제는 타인 자원 요청 테스트로, 공급망은 의존성과 빌드 산출물 관리로, 예외 처리는 실패 시 권한이 열리지 않는지 확인하는 검증으로 연결합니다. 상세 요구사항에는 OWASP ASVS 같은 기준을 함께 검토할 수 있습니다.

13장 2025판의 위험을 검증 항목에 매핑하기#

번호	위험 범주	서비스에서 확인할 질문
A01	접근통제 실패	다른 사용자·조직의 자원에 접근 가능한가?
A02	보안 설정 오류	기본 계정·관리 경로·과도한 공개 설정이 남는가?
A03	소프트웨어 공급망 실패	의존성·빌드·배포의 출처와 권한을 확인하는가?
A04	암호화 실패	데이터·키·전송 구간의 보호가 적절한가?
A05	인젝션	외부 데이터가 명령·질의로 해석되는가?
A06	안전하지 않은 설계	남용과 실패 시나리오가 설계에서 빠졌는가?
A07	인증 실패	로그인·복구·세션의 신뢰가 유지되는가?
A08	소프트웨어·데이터 무결성 실패	업데이트와 중요 데이터의 진본을 검증하는가?
A09	보안 로그·알림 실패	중요한 이상을 기록하고 조사할 수 있는가?
A10	예외 상황의 잘못된 처리	실패해도 권한·거래·자원 상태가 안전한가?

14장 목록을 업무 흐름과 연결하는 방법#

주문 API를 점검한다면 A01은 주문 소유권, A05는 DB 질의 바인딩, A06은 중복 주문과 비정상 구매 흐름, A10은 결제 오류 후 상태를 확인하는 식으로 나눕니다. 같은 코드가 여러 범주와 관련될 수 있으며 번호 하나로 담당팀을 고정하면 경계의 문제를 놓칠 수 있습니다.

검증 기록에는 위험 범주·대상 기능·실패 입력·기대 동작·실제 결과·수정 담당자를 남깁니다. 자동 도구의 검사 결과와 업무 인가·동시성·상태 전이 같은 수동 검증을 함께 연결합니다. 항목의 수를 채우기보다 실제 위험과 증거를 확보하는 것이 목적입니다.

15장 적용 전 확인할 사항#

문서의 판본과 위험 분류를 기록한다
범주마다 실제 실패 사례와 검증 방법을 둔다
설계·구현·운영 담당자의 책임을 연결한다

16장 자주 묻는 질문#

Top 10을 모두 점검하면 보안 검증이 끝나나요?#

서비스의 데이터·기능·위협에 맞는 추가 요구사항이 필요합니다. 위험 목록을 출발점으로 사용하고 상세 기준과 실제 공격 경로 검증을 결합해야 합니다.

2021판 체크리스트를 그대로 2025판으로 부르면 되나요?#

분류와 번호가 달라졌으므로 매핑과 누락 검토가 필요합니다. 판본을 표시하고 현재 위험 범주에 맞춰 기능별 검증 항목을 갱신합니다.

Top 10은 보안 인증서 발급 기준인가요?#

주요 위험을 알리는 자료입니다. 상세 요구사항·검증 수준은 서비스의 위협과 관련 기준을 별도로 정해야 합니다.