오래된 앱 보안 점검 5가지

오래된 앱이 위험한 이유

앱을 안 건드렸다고 안전한 게 아닙니다. 코드는 멈춰 있어도 취약점은 새로 발견되고, 규칙은 느슨하게 방치됩니다. 쓰던 라이브러리에서 보안 결함이 공개되고, 처음엔 문제없던 서버 설정이 지금 기준으론 위험한 경우가 많습니다. 방치 기간이 길수록 점검이 시급합니다(관련: 방치 앱 점검 체크리스트).

점검 1: API 키·비밀정보 노출

앱 코드나 저장소에 API 키·비밀번호가 그대로 박혀 있으면, 디컴파일이나 공개 저장소를 통해 새어 나갈 수 있습니다. 키가 노출되면 요금 폭탄이나 데이터 유출로 이어집니다. 노출된 키는 즉시 재발급하고 사용 범위를 제한하며, 민감한 키는 서버를 경유하도록 구조를 바꿔야 합니다(관련: 앱 API키 노출 위험과 조치).

점검 2: 서버·DB 접근 규칙

가장 흔한 사고가 DB가 사실상 전체 공개로 열려 있는 경우입니다. Firebase 같은 서비스는 초기 테스트 규칙을 그대로 두면 누구나 데이터를 읽고 쓸 수 있습니다. 인증된 사용자만, 자기 데이터만 접근하도록 규칙을 좁히세요(관련: 파이어스토어 보안규칙 흔한 실수).

점검 3: 라이브러리·OS 취약점

• 오래된 라이브러리 — 알려진 취약점이 공개된 버전을 쓰고 있는지
• 최소 지원 OS — 보안 업데이트가 끊긴 옛 OS만 지원하는지
• 타깃 API 레벨 — 스토어 정책 미달로 업데이트가 막히는지

업데이트가 밀린 앱은 취약점이 겹겹이 쌓입니다. 라이브러리 버전을 점검하고 단계적으로 올리는 계획이 필요합니다.

점검 4: 개인정보·암호화

이름·연락처·결제 같은 개인정보를 평문으로 저장·전송하면 유출 시 피해가 큽니다. 전송 구간은 HTTPS로, 저장 데이터는 필요한 항목을 암호화하고, 로그에 민감정보가 남지 않는지 확인하세요. 개인정보처리방침도 실제 처리와 일치해야 합니다(관련: 개인정보 암호화).

점검 5: 백업과 복구

보안 사고나 장애가 나면 결국 백업이 마지막 보루입니다. DB·서버가 자동으로 백업되는지, 복구를 실제로 해본 적 있는지 확인하세요. "백업은 하고 있는데 복구는 안 해봤다"는 경우가 의외로 많고, 정작 필요할 때 복구가 안 되면 백업이 없는 것과 같습니다(관련: 앱 서버·DB 백업).

자주 묻는 질문