← 홈으로
SYNTHETIC SAMPLE · REPORT FORMAT

출시 전 QA 샘플 리포트

고객이 실제로 받는 리포트의 판정, 재현 근거, 수정 우선순위와 AI 수정 프롬프트 형식을 미리 확인할 수 있습니다.

자료 성격: 이 페이지는 의도적으로 취약하게 만든 로컬 테스트 앱을 점검한 합성 예시입니다. 실제 고객 사례·고객 성과·운영 서비스의 취약점을 의미하지 않으며, 제품 정확도를 입증하는 통계로 사용하지 않습니다.

1. 점검 범위

검사는 먼저 공개 표면을 읽기 요청으로 확인한 뒤, 승인된 테스트 계정 A·B로 권한 경계를 교차 검증하는 순서로 진행했습니다. 각 발견은 요청 조건, 관찰한 응답, 사용자 영향과 수정 후 기대 결과를 분리해 기록했습니다. 자동 경고만 나온 항목은 확정 취약점으로 올리지 않고 사람이 같은 조건을 재현했을 때만 판정에 반영했습니다.

BLOCKED

2. 출시 판정

출시 전에 Critical·High 항목 수정이 필요합니다. 확인하지 못한 영역은 안전하다고 표시하지 않고 ‘접근 필요’로 남깁니다.

3. 우선 수정 예시

CRITICAL

로그인 없이 보호된 API 접근 가능

재현: 쿠키와 인증 헤더가 없는 요청으로 보호 대상 API를 호출했을 때 데이터가 포함된 200 응답을 확인했습니다.

영향: 인증되지 않은 사용자가 사용자 데이터나 보호 기능에 접근할 수 있습니다.

수정: 서버에서 세션을 검증하고 미인증 요청에는 401을 반환하며, 데이터 계층에서도 사용자별 접근 정책을 적용합니다.

AI 수정 프롬프트: 이 API에 서버 측 인증 검사를 추가하고, 유효한 세션이 없으면 401을 반환하도록 수정해줘. 프론트 화면만 숨기는 방식은 사용하지 말아줘.

CRITICAL

객체 ID 변경으로 다른 사용자 데이터 조회

재현: 테스트 계정 A의 세션으로 객체 ID만 B의 값으로 바꿨을 때 B의 데이터가 반환되는 시나리오를 확인했습니다.

수정: 요청 객체의 소유자와 인증 사용자 ID를 서버에서 비교하고 불일치하면 403을 반환합니다. Supabase라면 같은 조건을 RLS에도 적용합니다.

HIGH

결제 결과를 클라이언트 상태만으로 신뢰

위험: 브라우저 값만 변경해 유료 기능이 열리면 결제 우회로 이어질 수 있습니다.

수정: 결제 제공자의 서명된 웹훅과 서버 조회 결과를 검증한 뒤 서버 데이터의 구독 상태만 권한 판정에 사용합니다.

4. 근거 수준과 판정 기준

표시의미출시 판단
확인됨합의한 계정과 요청으로 같은 결과를 반복 재현하고 응답 근거를 보관했습니다.Critical·High는 수정 전 출시 차단 또는 명시적 위험 수용이 필요합니다.
조건부위험 신호는 있으나 권한·환경 제약 때문에 영향 전체를 재현하지 못했습니다.추가 접근이나 서버 로그를 확보한 뒤 판정을 갱신합니다.
미점검범위 밖 기능이거나 안전한 테스트 조건을 만들 수 없었습니다.통과로 계산하지 않으며 담당자가 별도 확인해야 합니다.

5. 수정 후 재검증 방식

수정본에서는 기존 재현 요청을 같은 계정·권한 조건으로 다시 실행합니다. 미인증 API는 데이터 없는 401, 다른 사용자 객체 접근은 403 또는 비노출 응답, 결제 권한은 서버가 검증한 완료 상태에서만 열리는 것을 통과 기준으로 삼습니다. 수정 때문에 정상 사용자 흐름이 막히지 않았는지도 함께 확인하고, 결과를 ‘해결됨·부분 해결·재현됨’으로 구분합니다.

이 샘플은 보고서의 형식과 판단 방식을 보여주기 위한 자료입니다. 모든 프레임워크·배포 환경의 취약점을 자동으로 찾는다는 정확도 보증, 법률 자문, 침투 테스트 인증을 의미하지 않습니다. 실제 점검 범위는 대상 서비스와 사전 합의한 계정·행동에 따라 달라집니다.

6. 실제 리포트에 함께 제공되는 것

관련 출시 전 확인 가이드

직접 점검하려면 .env와 비밀키 노출 확인법, Supabase RLS 권한 체크리스트, 결제 상태·웹훅 출시 체크리스트를 함께 사용하세요.

내 앱 무료 예비 진단검사·편집 기준