열다섯 번째 발걸음고친 뒤의 결과와 다음 변경을 함께 책임진다

오류가 난 순간에 프로그램의 보안 원칙이 드러납니다. 권한 확인 서버가 응답하지 않을 때 모든 요청을 허용하는지, 데이터 저장이 실패했는데 성공 메시지를 보내는지, 외부 서비스의 시간이 초과됐는데 같은 결제를 계속 반복하는지 살펴보세요. 정상 요청만 있을 때의 동작으로는 이런 실패 경로를 알 수 없습니다. 실패했을 때도 보호할 자산과 권한의 조건을 유지하도록 동작을 정하는 것이 안전한 실패의 원칙입니다. 권한 확인 실패 시 기본적으로 거부하더라도, 사람의 안전과 필수 업무를 지키는 예외 경로가 필요하다면 그 조건과 책임을 별도로 설계해야 합니다.

예외는 적절한 경계에서 처리하고, 사용자에게 필요한 안내와 내부 조사에 필요한 기록을 나눕니다. 내부 경로·질의문·스택 추적을 그대로 응답에 내보내면 정보 노출이 될 수 있습니다. 그렇다고 오류를 모두 지우면 원인 파악과 침해 탐지가 어려워집니다. 요청 식별자로 사용자 문의와 내부 기록을 연결하되 비밀번호·세션 토큰·불필요한 개인정보는 기록하지 않는 설계가 필요합니다.

로그는 상태 변경의 결과까지 남겨야 합니다. “삭제 요청 접수”라는 기록만으로 실제 삭제가 끝났다고 단정할 수 없습니다. 승인·실행·실패·취소의 결과를 구분하고, 중요한 작업의 순서와 주체를 연결합니다. 요청 식별자와 일관된 시각은 여러 서비스의 기록을 이어 읽을 때 도움이 됩니다. 공격의 근거를 읽는 방법은 다음 방향에서 실제 로그로 이어갑니다.

보안 분류표는 빠진 질문을 찾는 지도입니다. OWASP Web Top 10:2025는 접근통제·설정·공급망·암호·인젝션·설계·인증·소프트웨어와 데이터 무결성·로그와 경보·예외 처리의 실패를 다룹니다. 이 목록은 모든 취약점의 전부도, 각 서비스에서 같은 비중으로 나타나는 통계표도 아닙니다. 자신의 데이터 흐름과 요구사항에 연결해서 사용해야 합니다.

OWASP API Security Top 10:2023은 API에서 특히 살펴볼 객체·속성·기능의 인가, 인증, 자원 소비, 민감한 업무 흐름, SSRF, 설정, 자산 목록, 외부 API 소비의 문제를 다룹니다. Web 목록과 판본·분류 목적이 다르므로 연도와 문서 이름을 함께 읽습니다. 용어 순서를 외우는 것보다 그 분류가 어떤 경계를 놓치지 말라고 하는지 설명할 수 있어야 합니다.

개편과 배포를 반복하면 오래된 API와 테스트 경로가 남을 수 있습니다. 새 화면에서 쓰지 않더라도 옛 주소가 계속 접근 가능하면 과거의 약점이 살아 있을 수 있습니다. 운영하는 호스트·버전·경로·담당자를 관리하고, 필요가 끝난 기능은 검증 후 종료합니다. “메뉴에서 지웠다”와 “서버가 더 이상 제공하지 않는다”는 다른 상태입니다.

수정된 기능만 정상인지 보는 데서 검증을 끝내지 않습니다. 공통 권한 모듈을 고쳤다면 같은 모듈을 쓰는 다른 기능과 기존 이용자의 정상 작업도 확인합니다. 이전에 동작하던 기능과 보호 조건이 변경 후에도 유지되는지 다시 살피는 회귀 검증이 필요합니다. 발견했던 결함의 재현 조건과 기대 결과를 남기면 이후 변경에서 같은 문제를 더 일찍 발견할 수 있습니다.

이제 처음의 질문으로 돌아갑니다. 정상적으로 보이는 요청에서 다른 사람의 정보가 나온 이유는 암호가 약해서만은 아닙니다. 입력의 의미, 객체의 권한, 브라우저의 자격 증명, 서버의 네트워크 접근, 업무 상태와 메모리의 경계 가운데 하나가 잘못 연결되었을 수 있습니다. 각 경계를 설명하고 그에 맞는 근거를 확인하는 것이 안전한 개발의 공통 원리입니다.

참고　[254] · [255] · [256] · [257] · [258]