앱 화면 밖의 요청까지 확인하다: 모바일 앱·서버 보안 검증 사례

먼저 점검 대상과 허용 범위를 정했습니다

보안 검증은 어디든 자유롭게 시험하는 작업이 아닙니다. 어떤 앱과 서버, 어떤 기능과 요청을 대상으로 할지 합의한 범위가 있어야 합니다.

R사에서는 착수 전에 점검 범위를 서면으로 확정하고 앱과 서버의 항목을 나눠 실행했습니다. 출시 전에 확인할 대상을 명확히 했습니다.

범위를 먼저 정해야 결과도 정확하게 설명할 수 있습니다. 일부 API를 점검한 결과를 서비스 전체의 보안으로 확대하거나, 특정 버전의 결과를 이후 모든 버전에 그대로 적용해서는 안 됩니다.

이 사례에서도 점검한 항목과 범위 밖에 둔 항목을 구분해 기록했습니다.

단말과 통신, 서버는 서로 다른 질문을 받았습니다

앱에서는 단말에 남는 데이터, 통신 구간, 인증 흐름을 확인했습니다. 서버에서는 API 권한과 입력 검증을 살폈습니다.

단말

앱 사용 과정에서 어떤 데이터가 남는가?

통신·인증

데이터 전달과 이용자 확인이 어떻게 처리되는가?

서버 API

해당 요청을 허용할 권한이 있는지, 입력을 검증하는가?

하나의 테스트로 이 질문에 모두 답할 수는 없습니다. 그래서 앱이 로그인에 성공했다고 해서 모든 서버 요청의 권한이 맞게 처리된다고 결론 내릴 수 없습니다.

기능을 사용할 수 있는지와 그 기능을 사용할 자격을 확인하는지는 다른 검증 대상입니다.

화면을 거치지 않은 요청도 확인했습니다

서버 검증에서는 앱 화면을 거치지 않고 서버를 직접 호출하는 요청도 실행했습니다. 화면의 제한에만 의존하지 않고 서버가 요청을 처리하는 기준을 확인했습니다.

이런 검증의 목적은 특정 공격 기법을 많이 실행하는 데 있지 않습니다. 정상적인 이용 흐름에서 감춰질 수 있는 권한과 입력 처리의 경계를 살피는 데 있습니다.

예를 들어 어떤 동작이 화면에서 제한돼 있더라도 그 제한이 서버에서도 적용되는지는 별도로 확인해야 합니다. 해당 서비스에서 특정 침해가 발생했다는 뜻이 아니라 검증에서 물어야 할 질문입니다.

R사에서는 이렇게 앱과 서버를 함께 보며 확인한 문제를 심각도와 재현 조건이 있는 기록으로 정리했습니다.

수정됐다는 답변 이후에도 같은 조건을 다시 실행했습니다

결함을 보고한 다음에는 수정 결과를 재검증했습니다. 같은 항목을 다시 실행해 조치 여부를 확인하는 과정입니다.

수정한 코드가 있다는 것과 원래 확인한 문제가 해결됐다는 것은 다른 상태입니다. 변경이 실제로 반영된 환경에서 같은 조건을 확인해야 조치 결과를 설명할 수 있습니다.

이 점검에서는 보고와 수정 확인을 분리하지 않았습니다. 무엇을 발견했고 그 항목을 어떻게 다시 확인했는지가 이어지도록 했습니다.

다만 확인한 결함의 조치가 서비스에 다른 문제가 전혀 없다는 뜻은 아닙니다. 보안 검증 결과는 대상 버전과 범위, 사용한 조건 안에서 해석해야 합니다.

출시 판단에 필요한 경계와 근거를 남겼습니다

프로젝트에는 앱·서버 점검 결과, 결함과 조치 확인 기록, 검증 범위와 제외 항목이 남았습니다. 이후 릴리스에서 다시 참고할 수 있는 점검 목록도 정리했습니다.

이 결과물의 가치는 안전하다는 한 문장으로 서비스 전체를 평가하는 데 있지 않습니다. 어디까지 확인했고 어떤 조치를 다시 검증했는지 설명할 수 있다는 데 있습니다.

앱의 품질을 화면의 동작으로만 판단하면 놓치는 영역이 있습니다. 단말에 남는 정보와 통신, 서버가 요청을 받아들이는 조건도 서비스의 일부입니다.

R사 사례는 출시 전 검증의 범위를 앱 안에 가두지 않고 데이터를 처리하는 서버까지 연결해 살핀 프로젝트입니다.