상세 사용 매뉴얼

MANUAL · 목차

1. 점검 요청

점검할 웹앱의 도메인과 결과를 받을 이메일을 입력하고 «점검 요청»을 누릅니다. 그 요청에만 묶인 고유 토큰이 발급됩니다. 이 시점에는 아직 아무것도 스캔하지 않습니다.

2. 통제 증명 (핵심 단계)

발급된 토큰을 도메인에 두어 소유를 증명합니다. 두 방법 중 하나면 됩니다. 그 자리에 토큰을 둘 수 있다는 것 자체가 증명입니다.

3. 검증 후 점검 실행

«동의 확인하기»를 누르면 서버가 토큰 위치를 읽어 검증합니다. verified 가 되면 그 도메인만 허용 목록에 올라 자동 점검 대기열에 들어갑니다. 외부 점검은 읽기 전용 GET 요청만 씁니다 — 주입·무차별·과부하 없음. 단 하나의 예외가 있습니다: 점검 대상 번들에 Supabase 프로젝트 주소(*.supabase.co)와 anon 키가 실려 있으면, 그 프로젝트 호스트 한 곳에 읽기 전용 GET 으로 RLS 가 켜져 있는지 시험합니다. 번들이 이미 부르는 테이블 이름만, 테이블당 1건씩이며, 행의 값은 읽지도 저장하지도 않습니다.

4. 영수증 읽기

점검이 끝나면 영수증을 이메일로 받습니다. 각 항목의 판정은 세 값 중 하나이며(실패는 심각도를 함께 표시), 변조 방지 해시 체인으로 남습니다:

무엇을 점검하나

안전·개인정보

동의를 증명한 도메인만 점검합니다. 결과는 귀하에게만 전달하고 어디에도 게시하지 않습니다. 자금·결제 수단은 받지 않으며, 후원은 지갑으로 직접 이뤄집니다.

점검 배지 (선택)

점검이 끝나면 사이트에 «star365 점검» 배지를 달 수 있습니다. 배지는 귀하가 켰을 때만 나옵니다 — 동의 파일(또는 TXT 레코드)에 토큰과 함께 badge=on 한 줄을 적어 두세요. 켜지 않으면 배지 주소는 404 이고, 점검을 받았다는 사실조차 드러나지 않습니다. 실제 영수증이 있는 도메인만 배지가 나오며(위조 불가), 실패 건수는 공개로 노출하지 않습니다. 아래 코드의 도메인만 귀하 것으로 바꾸세요:

CI 에서 배포마다 점검

최초 한 번만 사람이 합니다: 아래 명령이 동의 파일 내용과 영수증 키를 출력합니다. 파일 내용(맨 끝 standing=on 줄 포함)을 사이트에 올리고, 출력된 NONCE·RECEIPT_KEY 를 CI 비밀로 저장하세요.

그다음은 배포 파이프라인에 한 단계를 더합니다(GitHub Actions 예시 — action.yml 과 star365-audit.sh 를 저장소에 함께 둡니다. 다른 CI 에서는 bash star365-audit.sh rescan):

- uses: ./.github/actions/star365-audit   # action.yml + star365-audit.sh
  with:
    nonce: ${{ secrets.STAR365_NONCE }}
    receipt-key: ${{ secrets.STAR365_RECEIPT_KEY }}
    fail-on: crit

종료코드: 0 통과 · 1 실패(기본은 «위험» 등급만 실패로 봄, fail-on: warn 이면 «주의»도) · 2 판정 불가(대기 시간 초과·동의 없음). 같은 도메인은 1시간에 한 번만 점검합니다. 반복 점검을 멈추려면 동의 파일에서 standing=on 줄을 지우세요 — 다음 요청부터 거절됩니다.

문제 해결

«토큰을 찾지 못했습니다»가 나와요

파일 URL 이 정확한지(오타·대소문자), 내용에 토큰만 있는지 확인하세요. DNS 방법이면 전파가 끝났는지 기다린 뒤 다시 «동의 확인하기»를 누릅니다.

«확인 불가»는 실패인가요?

아니요. 우리가 그 항목을 읽지 못했다는 뜻이며, 통과로 감추지 않고 그대로 알려드리는 것입니다. 필요하면 소스 위치나 SSH 내부 점검으로 확인할 수 있습니다.

점검이 언제 실행되나요?

동의가 verified 되면 자동 대기열에 올라 곧 실행되고, 끝나면 이메일로 영수증을 보냅니다.

비용

외부 점검은 무료입니다. SSH 내부 점검·정기 감시는 범위에 따라 상담 후 진행합니다. 도움이 됐다면 자발적 후원(비수탁)이 가능합니다.