r/vibecoding•5개월 전•17•29

AI로 만든 앱 48개 스캔 결과, 예상보다 훨씬 심각함

Scanned 48 vibe coded apps. Results worse than expected

핵심 요약

AI 도구로 생성된 앱 48개를 보안 스캔한 결과, 90%가 취약점을 가지고 있어 보안 상태가 매우 위험한 것으로 나타남.

인증 취약점 — 44%의 앱이 로그인 없이 핵심 기능에 접근 가능한 보안 허점을 가짐.
권한 우회 문제 — 33%의 앱이 Postgres의 SECURITY DEFINER를 오용해 행 수준 보안을 무력화함.
데이터 노출 위험 — 25%의 앱이 URL 조작으로 타인의 데이터를 볼 수 있는 IDOR 취약점을 포함함.
보안 인식 부족 — LLM은 기능 구현에만 최적화되어 있어 공격 방어 로직을 전혀 고려하지 않음.

Lovable/Bolt/Replit 같은 도구로 만든 앱들이 실제로 얼마나 안전한지 궁금해서 스캐너를 직접 만들어 이 도구들로 제작된 공개 GitHub 저장소 48개를 대상으로 테스트해 봤어.

결과는 다음과 같아:

90%가 최소 한 개 이상의 보안 취약점을 가지고 있었어.

세부 내용은 이래:

44%가 인증 허점을 가지고 있었어
— 로그인 없이 누구나 접근할 수 있는 API 경로나 페이지가 있었어. 예외적인 경우가 아니라 핵심 앱 기능에서 말이야.
33%가 Security Definer RPC 함수를 사용하고 있었어
— 이게 제일 놀라웠어. AI 도구가 Postgres 함수를 생성할 때 권한 오류를 해결하려고 가끔 SECURITY DEFINER를 추가하거든. 오류는 해결되지만, 행 수준 보안 정책을 모두 우회해서 슈퍼유저 권한으로 함수를 조용히 실행해 버려. 이 앱들의 3분의 1이 운영 환경에서 이걸 쓰고 있었어.
25%가 BOLA/IDOR 취약점을 가지고 있었어
— URL의 ID만 바꾸면 남의 데이터를 볼 수 있는 고전적인 문제야. 거의 모든 AI 생성 CRUD 앱이 이래. LLM이 소유권 확인 로직 없이 WHERE id = $input으로 코드를 짜기 때문이지. 부주의해서가 아니라, LLM이 학습한 패턴 자체가 그래.
25%가 환경 설정 파일이나 설정 파일을 저장소에 그대로 커밋했어.
평균: 앱당 21개의 보안 발견 사항이 있었어.

심지어 "Secure-Renewals-2"라는 이름의 앱도 있었는데, 발견된 사항만 176개였어.

개발자들이 유일하게 잘한 점:
저장소에 실제 API 키를 그대로 둔 경우는 거의 없었어. .env 파일에 대한 교훈은 잘 습득한 모양이야. 하지만 나머지는? 여전히 다 뚫려 있어.

왜 이런 일이 발생할까:
LLM은 정상적인 경로(happy path)에서 잘 작동하는 코드를 생성하도록 최적화되어 있어. 보안은 적대적인 환경이라, 악의적인 사용자가 의도적으로 가정을 깨뜨리려 할 때 무슨 일이 벌어질지 고민해야 해. 모델들은 그런 모드로 훈련되지 않았어. 모델은 작동하는 코드를 쓰지, 공격에서 살아남는 코드를 쓰지는 않거든.

인증 문제가 좋은 예야. AI 도구들은 전체 로그인 흐름, 등록, 세션, 비밀번호 재설정 기능은 잘 만들어. 하지만 로그인 뒤에 경로를 실제로 보호하는 단계는 자주 건너뛰어. 문은 있는데 잠금장치가 없는 셈이지.

가장 놀라웠던 점:
Security Definer 문제는 눈에 보이지 않아. 오류도, 경고도, 뭔가 잘못됐다는 신호도 없어. 앱은 완벽하게 작동하거든. 하지만 모든 사용자가 그 함수를 호출해서 마치 슈퍼유저인 것처럼 테이블의 모든 행에 접근할 수 있어. 보안 감사를 받거나 해킹을 당한 뒤에야 알게 될 거야.

원문

커뮤니티 목록

r/vibecoding•5개월 전•17•29

AI로 만든 앱 48개 스캔 결과, 예상보다 훨씬 심각함

Scanned 48 vibe coded apps. Results worse than expected

핵심 요약

AI 도구로 생성된 앱 48개를 보안 스캔한 결과, 90%가 취약점을 가지고 있어 보안 상태가 매우 위험한 것으로 나타남.

인증 취약점 — 44%의 앱이 로그인 없이 핵심 기능에 접근 가능한 보안 허점을 가짐.
권한 우회 문제 — 33%의 앱이 Postgres의 SECURITY DEFINER를 오용해 행 수준 보안을 무력화함.
데이터 노출 위험 — 25%의 앱이 URL 조작으로 타인의 데이터를 볼 수 있는 IDOR 취약점을 포함함.
보안 인식 부족 — LLM은 기능 구현에만 최적화되어 있어 공격 방어 로직을 전혀 고려하지 않음.

결과는 다음과 같아:

90%가 최소 한 개 이상의 보안 취약점을 가지고 있었어.

세부 내용은 이래:

44%가 인증 허점을 가지고 있었어
— 로그인 없이 누구나 접근할 수 있는 API 경로나 페이지가 있었어. 예외적인 경우가 아니라 핵심 앱 기능에서 말이야.
33%가 Security Definer RPC 함수를 사용하고 있었어
— 이게 제일 놀라웠어. AI 도구가 Postgres 함수를 생성할 때 권한 오류를 해결하려고 가끔 SECURITY DEFINER를 추가하거든. 오류는 해결되지만, 행 수준 보안 정책을 모두 우회해서 슈퍼유저 권한으로 함수를 조용히 실행해 버려. 이 앱들의 3분의 1이 운영 환경에서 이걸 쓰고 있었어.
25%가 BOLA/IDOR 취약점을 가지고 있었어
— URL의 ID만 바꾸면 남의 데이터를 볼 수 있는 고전적인 문제야. 거의 모든 AI 생성 CRUD 앱이 이래. LLM이 소유권 확인 로직 없이 WHERE id = $input으로 코드를 짜기 때문이지. 부주의해서가 아니라, LLM이 학습한 패턴 자체가 그래.
25%가 환경 설정 파일이나 설정 파일을 저장소에 그대로 커밋했어.
평균: 앱당 21개의 보안 발견 사항이 있었어.

심지어 "Secure-Renewals-2"라는 이름의 앱도 있었는데, 발견된 사항만 176개였어.

주요 댓글

r/vibecoding

작성자가 자신의 글쓰기 방식에 대한 피드백을 수용하면서, 본인이 사용한 보안 스캐닝 도구의 기술적 원리와 한계를 상세히 설명하는 분위기.

공정하게 말하자면, 가장 인기 있거나 최고인 앱 말고 그냥 평범하게 직접 만든 앱들도 비슷하게 스캔해봐야 해. 상황이 별로 나을 것 같지 않거든.

좋은 생각이네. 근데 요즘은 수작업으로 만든 앱을 찾기가 더 힘든 것 같아. 다들 바이브 코딩으로 만들었으면서 아니라고 하는 경우가 많거든. 뭐 이건 내 개인적인 생각이라 틀릴 수도 있겠지만. 아무튼 좋은 아이디어네, 나도 내 스캐너로 한번 테스트해 봐야겠어.

아니! 예상보다 결과가 더 안 좋네! [움짤 반응]

ㅋㅋㅋ

진짜 공포를 맛보고 싶으면 'vibe coding'으로 만든 안드로이드 앱에서 데이터를 추출해 봐. 내가 악의적인 마음을 먹었다면 원하는 건 뭐든 무료로 API를 쓸 수 있었을걸.

AI로 글 쓰지 말고 직접 좀 써봐. 톤뿐만 아니라 긍정적인 내용 다음에 부정적인 내용이 나오는 구성 때문에 AI 쓴 거 너무 티 나.

-4

네, 알고 있습니다. 제가 영어가 모국어가 아니라서 메시지를 전달하거나 개선할 때 AI의 도움을 좀 받으려고 해요. 그래도 조언 감사합니다. 다음 포스트부터는 노력해 볼게요!

그 앱들 검토할 때 AI 썼음? 썼다면 어떤 프롬프트를 줬는지 궁금함. LLM으로 그런 허점들을 쉽게 찾을 수 있다면, 왜 vibe coder들이 AI 기반 보안 검사를 안 하는지 모르겠음. 흔한 함정들 활용해서 AI한테 코드 핵심 부분 짚어주고 스캔 돌리면 꽤 쉬울 텐데. 물론 사람이 직접 꼼꼼하게 검토하는 걸 대체할 순 없겠지만.

정적 스캐너가 패턴 매칭으로 찾아내는 건 매번 결과가 똑같아요. AI는 그 위에 얹혀서 파일 간의 발견 사항들을 연결해 공격 체인을 만드는 거죠. LLM한테 코드 리뷰를 시키는 거랑은 달라요. 탐지 자체가 LLM에 의존하는 게 아니니까요. 스캐너가 패턴을 찾거나 못 찾거나 둘 중 하나죠. 그래도 뭐, 사람의 리뷰를 대체할 순 없죠. 이건 그냥 그 전 단계에서 더 빠르게 처리하고, 비기술자들에게 자기 코드의 문제점을 알려주는 용도예요!

원문r/vibecoding