다른 사용자의 기록이 내게 보일까?

로그인한 메모 앱에 내 기록만 보인다고 가정해 보자. 서버가 내 것만 보냈을까, 모두 보낸 뒤 화면에서 골랐을까? 이 글은 그 화면을 시험한 기록은 아니다. 소유자 조건을 일부러 뺀 로컬 교육용 예제에서 합성 사용자 2명·메모 4개의 응답과 저장 상태를 전후 세 쌍으로 대조했다. 실제 앱의 안전이나 플랫폼 실패율은 판단하지 않는다. 읽기뿐 아니라 내용 변경·삭제도 각각 확인했다.

개념 일러스트이며 실제 시험 화면이나 격리 성공의 증거가 아니다.

출처로 보는 기준: 누구인지와 무엇을 해도 되는지

인증은 요청자가 누구인지, 접근 권한 확인은 그 사람이 특정 기록에 특정 작업을 해도 되는지 판단하는 일이다. OWASP API 보안 지침은 기록 ID를 받아 작업하는 기능마다 해당 사용자의 권한을 확인하도록 한다. OWASP 예방 지침도 추측하기 어려운 ID가 권한 확인을 대신하지는 못한다고 설명한다. 두 문서는 2026년 10월 7일 다시 확인했다. ID의 추측 난도는 이번 실험에서 비교하지 않았다.

기록된 관찰: 일부러 소유자 조건을 뺀 예제

2026년 10월 7일 시험한 보완 전 버전은 합성 신원만 구별하고 소유자 조건을 의도적으로 뺐다. 보완 후 버전은 서버가 합성 토큰을 A/B로 연결한 값을 기준으로 ‘그 사람 소유 기록만’이라는 조건을 목록·조회·내용 변경·삭제에 적용했다. AI 제작 도구의 자연 발생 오류를 발견한 실험이 아니다.

A의 A1·A2, B의 B1·B2와 없는 ID Z0를 썼다. 토큰은 요청에 붙이는 실험용 신원 표시다. 비로그인 N은 토큰을 보내지 않았고 잘못된 토큰도 별도로 시험했다. 실제 로그인 검사는 없었다. 규칙은 A/B가 자기 목록·기록만 읽고 고치고 지우며 N은 모두 거부되는 것이었다. 직접 작업 대상은 A1·B1·Z0뿐이며 A2·B2는 목록 구성원으로만 확인했다. 잘못된 토큰은 목록과 A1만 시험했다.

같은 36사례를 전→후, 후→전, 전→후 순으로 실행해 총 216요청을 보냈다. 매 요청 전 네 기록을 복원했다. 고정된 실행기·검증기가 응답 원문과 별도로 수집한 전후 전체 저장 상태를 사전 기대값과 대조했다. AI에게 독자 양식을 실행·채점시킨 실험은 아니다.

B의 A1 읽기는 보완 전 합성 A 메모를 반환했다. 내용 변경은 A1 본문을 Synthetic replacement로 바꿨고 삭제는 A1을 없앴다. 이는 매번 원래 상태에서 시작한 세 독립 요청이다. 보완 후에는 세 요청 모두 자료 없이 거부됐고 전체 기록이 그대로였다.

세 쌍의 대응 결과는 같았다. 아래 수치는 버전별 한 번의 실행(36사례) 기준이다. ‘일치’는 사전에 정한 소유자 규칙에 따라 허용·거부, 응답 자료, 요청 뒤 전체 저장 상태가 맞았다는 뜻이다. A→B1은 A가 B1에 요청했다는 표기다.

매회 보완 전에는 36건 중 8건이 위반했고, 유지 조건 28건은 28/28 일치했다. 보완 후에는 36/36 일치했다. 보완 전도 의도적으로 만든 동작의 예측에는 36/36 맞았지만, 규칙을 어긴 8건은 여전히 위반이다. 전후 차이는 목록 2건과 교차 소유자 직접 작업 6건뿐이었다.

보완 전·후 모두 A의 A1, B의 B1 읽기는 정확했고 내용 변경은 대상 본문 하나만, 삭제는 대상 하나만 바꿨다. 보완 전 목록 응답은 네 기록을 모두 보냈다. 보완 후에는 자기 두 기록을 한 번씩 반환하고 저장 내용은 그대로였다. 화면이 어떻게 표시했는지는 측정하지 않았다.

N·잘못된 토큰 요청의 401(신원 미확인), 소유자 변경 요청의 400(잘못된 요청), A/B의 없는 Z0 요청 거부는 보완 전에도 같았다. 이 대조 사례만 통과해도 타인 접근은 열려 있을 수 있다. 세 번의 보완 후 실행 각각에서 타인 기록 직접 요청 6/6은 없는 Z0의 대응 요청과 같은 404(찾을 수 없음) 응답 본문을 반환했다. 404는 이 예제의 약속이며 모든 앱의 필수 응답은 아니다. 응답 시간이나 내부 처리 경로가 같다는 증거도 아니다. 오류·미실행은 여섯 실행 각각 0/36건, 총 0/216건이었다.

재현 정보: macOS 27.0 arm64, Python 3.9.6의 내장 sqlite3 모듈, SQLite 3.54.0을 썼으며 통신은 이 컴퓨터 안(127.0.0.1)에 한정했다. 코드·자료·기대값을 측정 전 고정하고 파일 지문값(해시)으로 변경 여부를 확인했다. 측정 약 0.945초, 분석 73.4초, 추가 외부 비용 0달러이며 전체 제작 시간은 아니다. 고정 전 기계적 요약 정정 1회, 측정 중 정정 0회였다. 원문·저장 상태·방법은 별도로 보관한 실험 기록에 남겼다.

작성자 판단: 접근표와 증거를 함께 요청하자

아래는 이 로컬 예제의 점검 항목을 옮긴 미검증 독자 양식이다. 통과해도 앱이 안전하다는 보증은 아니다. 실행 전에 의도표를 고정하고, 독자나 고정된 별도 검증기가 실제 원문·전체 상태와 대조해야 한다. AI의 요약만으로 이 절차를 대신할 수 없다.

① 직접 채울 접근표

시험은 자기 앱의 격리된 시험 환경에서만 한다.
저장소 전체를 합성 자료만 든 버릴 수 있는 복사본으로 준비한다.
차단에 실패하면 내용 변경·삭제가 실제로 일어난다.
기록 종류: ____ / 소유자·공유 규칙: ____
각 칸의 의도한 허용/거부·반환 범위를 실행 전에 고정하기:
목록 요청: A ____ / B ____ / 비로그인 ____
이 예제의 목록 규칙: 자기 기록 포함·타인 기록 제외.
요청자 → 대상       직접 읽기     내용 변경     삭제
A → 자기 것         ____         ____         ____
A → B의 것          ____         ____         ____
B → 자기 것         ____         ____         ____
B → A의 것          ____         ____         ____
비로그인 → 각 대상  ____         ____         ____
없는 ID ____ / 잘못된 토큰 ____ / 소유자 변경 시도 ____
다른 구조라면 별도 사례와 기대값 설계(이번 실험 밖):
공유 ____ / 관리자·서비스 권한 ____ / 목록 전체 거부 ____

② AI에 보낼 요청

위의 격리된 합성 자료 환경에서만 각 칸을 실행해 줘.
실제 사용자가 쓰는 것과 같은 방식·권한으로 요청하고,
시험 신원·실제 요청·응답 원문 파일을 보존해 줘.
예상 밖 실제 자료가 나오면 중단하고 가려 줘. 본문을 AI에 보내지 마.
저장 상태는 HTTP 점검 기능을 새로 만들지 말고 별도 로컬 시험 도구로 수집해 줘.
그 권한을 사용자 요청에 쓰거나 그 도구를 배포 앱에 남기지 마.
매 요청 전 합성 자료를 복원하고 전후 전체 상태 파일을 남겨 줘.
의도표를 결과에 맞춰 고치거나 미실행 결과를 예상값으로 채우지 마.
점검: 자기 자료 누락·타인 자료 혼입, 거부 뒤 모든 기록 불변,
정상 내용 변경·삭제에서 의도한 기록만 바뀜을 각각 대조해 줘.
오류·미실행은 거부 성공으로 세지 말고 따로 표시해 줘.
보완 뒤 같은 표로 재시험해 줘.

‘적용했다’는 답만으로는 확인되지 않는다. 저장된 요청·응답 원문과 전체 상태 파일을 직접 열어 의도표와 대조하자. 사용하는 제작 도구·데이터베이스 문서는 권한과 사용자 요청 방식을 이해할 배경이며 실행 증거를 대신하지 않는다. 다른 구조의 목록은 일부 반환 대신 전체 거부가 맞을 수도 있어 기대값부터 따로 정해야 한다.

저장된 기록 하나를 행이라고 한다. 이번에는 SQLite 파일에 접근하는 앱의 소유자 조건을 시험했다. 데이터베이스 자체가 적용 대상 역할의 행 접근을 제한하는 행 수준 보안(RLS)은 미측정이다. 관리자·서비스 권한이나 DB 파일 직접 접근까지 이 표로 확인한 것은 아니다.

미측정 항목은 실제 로그인·인증 강도·비밀번호·세션·탈취 토큰, 공유·관리자 역할, 동시 요청·경쟁 상태, 화면·배포, DB 파일 접근, 내보내기·백업·스토리지, 시간 차이에 의한 정보 추론과 모든 우회다. 새 기록 만들기는 초기 자료 준비에만 썼고 시험하지 않았다. 클라우드도 미측정이며 플랫폼·인증 시스템·RLS와 앱 검사·대체 방어책 간 비교는 없다. 세 번은 이 로컬 환경에서 결과가 반복된 관찰뿐이다. AI 제작 도구·플랫폼이 얼마나 자주 이런 오류를 내는지, AI가 결함의 원인인지, 운영 앱이 안전한지는 증명하지 않는다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.