4,000개 앱이 이미 뚫려 있다 — Perfai가 던진 access control의 함정

핵심 요약 (TL;DR)

바이브코딩 앱 전용 취약점 자동 스캐너 Perfai Security가 2026-07-09 Product Hunt 데일리 3위로 데뷔했습니다. 자체 데이터로 4,000개+ 앱을 검사해 28,400개+ 취약점을 발견·수정했다고 밝혔고, 학술 연구는 바이브코딩 리포지토리 90%에 최소 하나의 취약점이 존재하며 LOC당 도입율이 수동 코딩의 9배라고 보고합니다.

Cursor로 만든 로그인 페이지가 정상 작동하는 걸 확인하고 배포합니다. 유저 몇 명이 붙습니다. 그런데 어느 날 한 유저가 다른 유저의 데이터를 볼 수 있다고 제보합니다. 로그를 뒤져보니 URL의 user_id 파라미터 하나만 바꾸면 남의 대시보드가 통째로 열리는 상태였습니다. 이걸 IDOR(Insecure Direct Object Reference)이라 부릅니다. 그리고 이 문제는 대부분의 테스트로는 안 잡힙니다.

왜 바이브코딩 앱은 access control이 뚫리는가

Perfai Security 페이지의 슬로건이 예리합니다. "작은 앱도 access control이 수천 개다." 로그인 여부, 이 유저가 이 조직의 멤버인지, 이 문서를 볼 권한이 있는지, 이 API로 write 할 수 있는지… 페이지 하나에 30~50개의 조용한 검증 포인트가 숨어 있는 거죠. LLM은 눈에 보이는 UI와 API를 만드는 데 능숙합니다. 눈에 안 보이는 30번째 검증 로직은 프롬프트에 명시하지 않는 이상 그냥 통과합니다.

숫자가 이를 뒷받침합니다. arXiv 2606.23130 논문은 바이브코딩 리포지토리 90%에 최소 하나의 취약점이 있고, 76%가 high/critical이며, LOC당 도입율이 수동 코딩의 9배(0.76 vs 0.08 per 1k LOC)라고 보고했습니다. 정적 스캐너는 이 중 상당수를 놓칩니다. access control은 '데이터가 흐르는 문맥'을 봐야 잡히는 종류라, 코드만 훑는 도구로는 무력하거든요.

Perfai가 접근한 방식 — 3층 스캔과 원-프롬프트 패치

Perfai는 UI 페이지, API 엔드포인트, DB 레벨 세 층에서 자율 에이전트가 트리를 훑고, 취약점을 발견하면 하나의 프롬프트로 패치를 제안합니다. Replit, Lovable, Claude Code, Cursor, Copilot, WindSurf, Gemini, Codeium으로 만든 앱을 모두 지원한다고 명시했습니다. 페이지에 박힌 누적 수치는 4,000개+ 앱 보호, 28,400개+ 취약점 발견·수정, 예방 가정 기준 $27.5M 버그바운티 절감입니다.

이 숫자들은 회사 내부 계산이라 3자 검증이 어렵습니다. 다만 데뷔 24시간 만에 upvote가 두 배 넘게 뛴 걸 보면 시장이 '문제 존재 자체'에는 크게 동의하는 것 같아요. Pro 플랜 50% 할인 코드 PRODUCTHUNT50도 열려 있고, 이번 창이 지나면 사라질 예정입니다.

바이브코더가 지금 당장 할 세 가지

첫째, 배포된 앱 하나를 골라 URL의 리소스 ID를 다른 유저 것으로 바꿔보세요. 남의 데이터가 보이면 IDOR가 있는 겁니다. 둘째, API 엔드포인트마다 '이 유저가 이 리소스의 소유자인가'를 검사하는 코드가 서버에 있는지 확인하세요. UI에서 버튼을 안 보여주는 건 방어가 아닙니다. 셋째, Perfai든 유사 도구든 하나를 붙여 자동 스캔을 정기적으로 돌리세요. 스캐너 없이도 최소한 체크리스트는 갖고 있어야 합니다.

프롬프트 차원에서 예방하려면 이렇게 명시하세요. "이 엔드포인트에 로그인·소유권·역할 3층 검증을 넣어줘." 완벽하진 않지만 확률은 크게 올라갑니다.

FAQ

Q. 소규모 사이드 프로젝트도 스캔이 필요할까요?
유저가 1명이라도 개인 데이터를 저장한다면 필요합니다. 취약한 앱은 크기와 무관하게 봇 스캐너에 걸립니다.

Q. Perfai 없이 직접 점검하는 최소한의 방법은?
Burp Suite Community로 요청을 가로채서 파라미터를 하나씩 바꿔보는 게 무료로 할 수 있는 최선입니다. 익숙해지는 데 하루면 됩니다.

Q. 학습 데이터가 오염된 LLM이 문제라면 프롬프트로 예방할 수 있나요?
어느 정도는 가능합니다. access control 3층 검증을 명시하면 확률이 올라가지만, 놓치는 건 여전히 남습니다. 그래서 스캐너가 필요한 거죠.

소스: Perfai Security on Product Hunt · Vibe-coded application security research (arXiv 2606.23130)