OWASP Top 10은 Open Worldwide Application Security Project가 발표하는, 웹 애플리케이션 보안 리스크 중 가장 중요한 범주를 정리한 목록으로 널리 참조됩니다. 대기업은 이를 보안 개발 프로그램 수립에 활용하지만, 고객 포털, 온라인 쇼핑몰 또는 SaaS 제품을 운영하는 중소기업에도 똑같이 유용합니다. 이 가이드는 각 범주를 중소기업이 자사 애플리케이션과 공급업체에 던질 수 있는 쉬운 질문으로 풀어 설명합니다.
무엇인가
Top 10은 인식 제고를 위한 문서로, 팀이 가장 흔한 웹 애플리케이션 위험에 집중하도록 돕습니다. 각 범주는 관련된 약점을 묶은 것입니다. 2021년 목록을 대체한 현행 2025년판은 다음을 다룹니다. 취약한 접근 제어(이제 서버 측 요청 위조도 포함), 보안 설정 오류, 소프트웨어 공급망 실패, 암호화 실패, 인젝션, 안전하지 않은 설계, 인증 실패, 소프트웨어 또는 데이터 무결성 실패, 로깅 및 경보 실패, 예외 상황의 부적절한 처리입니다. 많은 설문지와 계약이 여전히 2021년판을 참조하므로, 요구 사항을 정할 때 고객이나 파트너가 어느 판을 기대하는지 확인하십시오. 중소기업에게 가치는 목록을 외우는 데보다 질문 체크리스트로 활용하는 데 있습니다. 누가 무엇을 볼 수 있는지, 비밀번호와 세션은 어떻게 처리되는지, 어떤 구성 요소가 오래되었는지, 진행 중인 공격을 누군가 알아챌 수 있는지 등입니다.
누구를 위한 것인가?
이 체크리스트는 다음을 위해 작성되었습니다.
- 고객 대상 웹 애플리케이션, 포털 또는 온라인 쇼핑몰을 운영하는 중소기업
- 에이전시나 프리랜서에게 개발을 맡기며 근거 있는 질문을 해야 하는 창업자와 관리자
- 전담 보안 인력이 없는 소규모 내부 팀
- OWASP를 언급하는 고객 보안 설문에 대비하는 기업
무엇을 명확히 하는 데 도움이 되는지
각 범주를 하나씩 점검하면 다음이 명확해집니다.
- 사용자가 자신의 역할에서 허용된 데이터만 보고 변경할 수 있는지
- 어떤 서드파티 라이브러리, 플러그인, 프레임워크가 오래되었거나 유지 관리되지 않는지
- 설정, 시크릿, 오류 메시지가 필요 이상으로 정보를 노출하는지
- 로깅을 통해 의심스러운 활동을 인지하고 조사할 수 있는지
포함된 내용
- 접근 제어: URL이나 요청의 ID를 바꿔 사용자가 다른 고객의 기록을 보거나 수정할 수 없는지 테스트하고, 애플리케이션이 호출하도록 만들 수 있는 내부·외부 주소를 제한
- 암호화: 모든 구간의 HTTPS, 최신 TLS, 비밀번호가 강력한 해시 알고리즘으로 저장되는지 확인
- 인젝션: 입력값이 검증되고 데이터베이스 쿼리가 매개변수화되어 있는지 확인
- 설계: 비밀번호 재설정, 결제, 환불 같은 민감한 워크플로가 어떻게 동작해야 하는지 악용 사례를 포함해 문서화
- 잘못된 설정: 기본 계정을 제거하고, 디버그 출력을 비활성화하며, 보안 헤더를 검토
- 공급망: 라이브러리, 플러그인, 빌드 도구 목록을 유지하고, 정해진 일정에 따라 패치하며, 유지 관리되지 않는 구성 요소를 제거
- 인증: 관리자에게 다중 인증을 제공하고 반복적인 로그인 시도를 제한
- 무결성: 빌드 및 배포 파이프라인을 보호하고 업데이트가 신뢰할 수 있는 출처에서 오는지 검증
- 로깅 및 경보: 로그인, 권한 변경, 관리 작업을 기록하고, 경보가 이를 검토하는 사람에게 전달되도록 함
- 예외 상황: 오류, 타임아웃, 예상치 못한 입력이 스택 트레이스를 노출하거나 보안 검사를 건너뛰지 않고 안전하게 실패하도록 함
포함되지 않은 것
- Top 10에 대응하면 애플리케이션이 안전해진다는 진술(더 넓은 커버리지를 위한 유용한 출발점입니다)
- 인증 또는 공식 컴플라이언스 승인
- 단계별 악용 기법
- 내부 네트워크나 물리 보안 등 웹 애플리케이션 밖의 리스크
선택해야 할 때
새 기능을 계획할 때, 개발 공급업체를 도입할 때, 그리고 출시나 주요 릴리스 전에 이 체크리스트를 활용하십시오. '모르겠다'는 답이 여러 개라면, 추측에 의존하기보다 독립적인 검토를 의뢰해야 한다는 신호입니다. 고객이나 파트너가 OWASP 기준에 맞춘 테스트의 증거를 요청한다면, 일반적으로 자체 평가보다 문서화된 애플리케이션 보안 검토나 침투 테스트가 더 설득력이 있습니다.
우리의 접근 방식
접근 제어와 인증부터 시작하십시오. 업무용 애플리케이션에서 심각한 문제가 자주 나타나는 영역이기 때문입니다. 개발자나 공급업체에게 각 역할이 화면에서 숨겨지는 데 그치지 않고 서버에서 어떻게 강제되는지 설명해 달라고 요청하십시오. 그런 다음 구성 요소 목록을 작성하고 업데이트 절차를 합의합니다. 시크릿이 코드 저장소에 보관되지 않는지, 오류 페이지가 스택 트레이스를 드러내지 않는지 확인하십시오. 독립적인 시각이 필요하다면, 당사의 Application Security Review는 합의된 웹 애플리케이션과 API를 OWASP 범주를 포함한 일반적인 애플리케이션 리스크에 비추어 검토하고, 심각도별 발견 사항과 조치 지침을 제공합니다. 주된 우려가 CMS 기반 웹사이트라면 웹사이트 보안 강화가 더 적정한 단계일 수 있습니다. 무엇을 선택하든 보안을 출시 전 일회성 이벤트로 다루지 말고, 체크리스트를 릴리스 프로세스에 포함해 변경할 때마다 이에 비추어 검토하십시오.
자주 묻는 질문
관련 기사
시작하기
웹 애플리케이션에 대한 독립적인 시각이 필요하십니까?
애플리케이션, 사용자 역할, 예정된 출시나 고객 요청에 대해 알려 주십시오. 범위를 정한 검토를 제안해 드리겠습니다.
서면 범위 요청하기