많은 사장님은 사고가 터진 후에야 보안을 떠올립니다. 관리자 페이지에 누군가 로그인해 가격을 바꾸고, 사용자 휴대폰 번호가 대량으로 유출되고, 공식 웹사이트 첫 페이지에 이상한 링크가 걸리는 식입니다. 돌아보면 개발자는 "기능은 다 테스트했다"고 말합니다. 문제는 바로 여기에 있습니다. 기능 테스트가 통과되었다고 해서 보안이 통과된 것은 아닙니다.
웹사이트 개발에서 발생하는 보안 취약점은 대부분 고도화된 공격이 아니라 몇 가지 기본 단계를 제대로 하지 않아 생깁니다. 아래에서는 실제 프로젝트에서 가장 자주 밟는 함정을 하나씩 명확히 설명하겠습니다.
1. 권한 우회 접근: 로그인했다고 해서 모든 것을 볼 수 있는 것은 아님
기업 웹사이트와 관리자 시스템에서 가장 흔한 문제입니다. 사용자 A가 로그인한 후 주소창의 주문 ID를 1001에서 1002로 바꾸면 사용자 B의 주문을 볼 수 있습니다. 개발자는 흔히 프런트엔드에서 버튼만 숨기고 백엔드 API에서는 "이 데이터가 당신의 것인지"를 검증하지 않습니다.
방법은 간단합니다. 모든 API에서 현재 로그인한 사람이 이 데이터를 조작할 권한이 있는지 검증해야 하며, 단순히 "로그인 여부"만 판단해서는 안 됩니다. 역할 권한도 명확히 구분해야 하며, 일반 직원과 재무가 보는 메뉴와 호출할 수 있는 API는 반드시 달라야 합니다.
주의점: 권한 판단을 프런트엔드에 작성하지 마세요. 프런트엔드 코드는 사용자가 수정할 수 있으므로 백엔드가 마지막 관문입니다. 오픈 전에 개발자에게 ID가 관련된 모든 API를 나열하게 하고, 각각의 소유권 검증을 하나씩 확인하세요.
2. 인젝션 취약점: 문자열 연결은 언젠가 사고를 냄
SQL 인젝션은 오래된 문제이지만 오늘날에도 발생합니다. 전형적인 시나리오는 검색창이나 필터 조건에서 개발자가 사용자 입력을 SQL 문에 직접 연결하는 경우입니다. 공격자가 특수 문자를 입력하면 조건을 우회하고 테이블 전체를 빼낼 수 있습니다.
올바른 방법은 전부 파라미터화 쿼리 또는 ORM의 바인딩 파라미터를 사용하고 수동으로 연결하지 않는 것입니다. 명령 실행, 템플릿 인젝션도 마찬가지이며, 사용자 입력을 코드로 실행하는 모든 곳에서 화이트리스트 검증을 해야 합니다.
주의점: 코드에 문자열 연결 SQL이 나타나면 기본적으로 반려할 수 있습니다. 또한 데이터베이스 계정은 root를 사용하지 말고 업무에 필요한 권한만 부여하면 사고 발생 시 손실을 절반으로 줄일 수 있습니다.
3. 파일 업로드와 다운로드: 가장 쉽게 간과되는 진입점
기업 웹사이트에서는 제품 이미지, 계약서 첨부 파일을 업로드하고, 미니프로그램 개발에서는 프로필 사진과 신분증 사진을 업로드합니다. 업로드 API가 확장자만 검증한다면 공격자는 스크립트를 .jpg로 바꿔 업로드한 뒤 실행되도록 만들 수 있습니다.
방법: 파일 유형은 확장자가 아니라 실제 내용으로 검증하고, 업로드 디렉터리에서는 스크립트 실행을 금지하며, 파일 이름을 변경하여 저장해야 합니다. 다운로드 API도 권한을 검증해야 하며, 경로만 바꿔 서버의 설정 파일을 다운로드하게 해서는 안 됩니다.
주의점: 업로드 디렉터리와 웹사이트 프로그램 디렉터리는 분리해야 합니다. 많은 사고가 이미지와 코드를 같은 실행 가능 디렉터리에 두어 발생합니다.
4. API 인증과 민감 정보 노출
App 개발과 미니프로그램 개발에서 API는 주요 공격 표면입니다. 흔한 문제는 세 가지입니다. API에 빈도 제한이 없어 인증 코드를 무한히 시도할 수 있고, 반환 데이터에 제공해서는 안 되는 필드까지 함께 제공되며(예: 사용자 목록에 주민등록번호 포함), 오류 메시지가 너무 상세하여 데이터베이스 오류를 프런트엔드에 그대로 노출합니다.
방법: 로그인, SMS, 결제 관련 API는 반드시 속도 제한과 재전송 방지를 적용하고, 반환 필드는 필요에 따라 잘라내며, 오류 메시지는 통일해야 합니다. 로그에 비밀번호와 전체 휴대폰 번호를 평문으로 기록하지 마세요.
주의점: 테스트 환경 데이터를 운영 환경에 그대로 동기화하지 마세요. 많은 유출은 테스트 DB에 실제 사용자 데이터가 있고 테스트 환경의 보호가 거의 없기 때문에 발생합니다.
5. 오픈은 끝이 아님: 보안 테스트는 프로세스에 포함되어야 함
많은 팀이 보안을 일회성 점검으로 생각하고 오픈 후에는 관리하지 않습니다. 실제로 신규 기능 오픈, 의존성 업그레이드, 서버 설정 변경 등으로 문제가 다시 발생할 수 있습니다.
보안 테스트를 배포 프로세스에 포함할 것을 권장합니다. 매번 큰 개편 시 API와 권한을 재점검하고, 정기적으로 의존성 취약점을 스캔하며, 중요한 시스템은 매년 침투 테스트를 수행합니다. 공식 웹사이트 개편 같은 프로젝트는 페이지 수정 후 폼, 검색, 관리자 로그인을 함께 점검하면 비용이 높지 않고 대부분의 저수준 문제를 막을 수 있습니다.
주의점: 스캔 보고서의 건수만 보지 마세요. 도구가 스캔한 고위험 항목은 실제 악용 가능 여부를 사람이 확인해야 하며, 오탐과 누락이 모두 흔하므로 최종적으로는 사람이 비즈니스 로직 취약점을 판단해야 합니다.
어떤 경우 MIC Studio에 적합한가
팀에 전담 보안 인력이 없거나, 공식 웹사이트 개편, 예약 미니프로그램, 관리자 시스템을 준비 중이면서 오픈 후 수동적으로 대응하고 싶지 않다면 보안 부분을 맡길 수 있습니다.
MIC Studio는 기업 웹사이트, 미니프로그램 개발, App 개발을 하며 스크립트 개발과 웹사이트 보안 테스트, 리버스 테스트도 수행합니다. 우리는 사고가 난 후 보완하기보다 개발 단계에서 권한, 업로드, API 문제를 체크리스트로 점검하는 것을 더 선호합니다.
실행 가능한 세 가지 제안
1. 오픈 전에 API 목록을 작성하고 로그인 검증, 데이터 소유권 검증, 속도 제한 세 가지가 갖춰졌는지 하나씩 확인하며, 빠진 항목은 할 일로 기록하세요.
2. 업로드와 다운로드를 별도의 위험 요소로 검토하고 저장 디렉터리가 실행 불가능한지, 파일 유형을 내용으로 판단하는지, 다운로드가 권한 검증을 거치는지 확인하세요.
3. 보안 테스트에 예산과 시간을 배정하고 중요한 버전 배포 전에 점검을 수행하며, 보안을 오픈 후 선택 사항으로 여기지 마세요.