피드로 돌아가기
Type Your File Validation Library as a Security Boundary
Dev.toDev.to
Security

Runtime Check를 Compile-time Boundary로 전환하는 타입 시스템 설계

Type Your File Validation Library as a Security Boundary

venkatesh m2026년 5월 13일17intermediate

Context

기존의 { valid: boolean; data?: File } 구조는 유효성 검사와 데이터 존재 여부 사이의 타입 연결성이 결여된 설계임. 이로 인해 개발자가 ! Non-null assertion을 남용하게 되며, 검증 단계를 생략해도 컴파일 단계에서 감지하지 못하는 보안 취약점이 발생함.

Technical Solution

  • Discriminated Unions 도입을 통한 결과 상태의 상호 배제적 정의 및 데이터 접근 제어
  • Branded Types 적용으로 검증된 파일(ValidatedFile)과 일반 파일(File)을 물리적으로 구분하여 타입 혼용 방지
  • Exhaustiveness Checks 강제를 통한 새로운 에러 케이스 추가 시 모든 소비처의 수정 사항을 컴파일 타임에 강제
  • Validation을 단순한 'Check'가 아닌, 신뢰할 수 없는 데이터가 신뢰 영역으로 진입하는 'Security Boundary'로 재정의
  • 에러 사유를 단순 String이 아닌 구조화된 타입으로 정의하여 텔레메트리 및 UI 대응력 강화

1. Boolean 플래그와 Optional 필드 조합의 반환 타입을 Discriminated Union으로 교체했는가?

2. 검증 완료된 데이터에 Branded Type을 부여하여 검증 전 데이터와 엄격히 구분하고 있는가?

3. switch-case 문과 타입 가드를 사용하여 모든 가능한 상태(Pending, Expired 등)를 Exhaustive하게 처리했는가?

4. Non-null assertion(`!`) 사용을 최소화하고 타입 시스템이 데이터 존재를 보장하도록 설계했는가?

원문 읽기