Property-Based Testing이 __proto__ 보안 버그를 잡아낸 이야기

뭘 만들다가 발견했나

• Kiro(AWS의 AI IDE)로 채팅 앱의 스토리지 서비스를 구현하는 과정에서 발견된 실제 사례임. API 키를 provider 이름을 키로 localStorage에 저장/조회하는 단순한 기능이었음
• SDD(Specification-Driven Development) 워크플로우에 따라 요구사항을 정의하고, 테스트 가능한 속성을 추출하고, 코드를 구현했는데 — 코드 리뷰도 통과했을 법하고, 기존 유닛 테스트도 다 통과했음

75번째 반복에서 터짐

• 라운드트립 속성을 테스트한 거임: 임의의 provider와 key로 저장 → 조회하면 같은 값이 나와야 한다는 것
• fast-check 라이브러리로 PBT(Property-Based Testing)를 돌렸더니, 75번째 반복에서 provider가 "__proto__"일 때 실패함
• __proto__를 키로 객체에 값을 쓰면 JavaScript 엔진이 이걸 프로토타입 체인으로 해석해서 문자열 값을 거부하고, 나중에 읽으면 빈 객체 {}가 반환됨

왜 이게 보안 문제인가

• 현재 구현에서는 직접적으로 익스플로잇 불가능함 — 객체가 직렬화 후 바로 해제되고, JSON.stringify가 __proto__ 필드를 건너뛰기 때문
• 하지만 리팩토링 과정에서 새 코드 경로가 추가되면 공격자가 프로토타입에 값을 주입해 이후 속성 읽기를 오염시킬 수 있는 프로토타입 오염(prototype pollution) 취약점으로 발전할 수 있음

PBT가 여기서 빛나는 이유

• 유닛 테스트는 작성자(사람이든 LLM이든)의 편향(bias)에 갇힘. 구현할 때 생각 못 한 엣지 케이스를 테스트할 때도 생각 못 함
• PBT는 fast-check 커뮤니티가 축적한 "잘 알려진 버그 문자열" 지식을 테스트 생성기에 인코딩해둔 거라서, __proto__ 같은 함정을 자동으로 시도함
• numRuns: 100이 기본값인데, 이번 건은 75번째에서 잡힌 거임. 확신이 필요하면 숫자를 올리면 되고, 성능이 중요하면 낮추면 됨
• 속성(property)이 요구사항에서 직접 도출되기 때문에, 실행 가능한 명세(executable specification) 역할을 함. 요구사항과 테스트 사이의 간극을 메워줌