요청의 Host 헤더로 비밀번호 재설정 링크를 만들고 있습니다. 어떤 검증이 필요한가요?

Host는 요청자가 보낼 수 있는 값이므로 신뢰된 외부 기본 주소와 허용 도메인 정책 없이 보안 링크 생성에 쓰면 안 됩니다. 프록시가 전달하는 host도 신뢰 체인과 재작성 계약을 확인합니다.

동작 원리와 전제

악의적인 Host가 링크에 들어가면 사용자가 토큰을 다른 도메인에 보낼 수 있습니다. 비밀번호 재설정 링크는 구성된 canonical origin을 사용하고 테넌트별 도메인은 검증된 등록 정보에서 선택합니다. 요청 헤더의 임의 도메인을 그대로 등록하지 않습니다.

선택과 실패 처리

가상 호스트 라우팅과 캐시 키도 Host를 사용하므로 허용하지 않은 host는 경계에서 거절합니다. 포트·대소문자·국제화 도메인·프록시 헤더의 파싱 규칙을 일관되게 둡니다. 단순 문자열 contains 검사는 하위 도메인 혼동을 만들 수 있습니다.

구체적인 사례와 검증

재설정 토큰을 올바르게 생성해도 링크의 host가 공격자 도메인이면 사용자가 토큰을 그쪽으로 전달할 수 있습니다. 따라서 토큰 생성의 안전성과 URL 생성의 신뢰를 따로 검증합니다. multi-tenant 서비스의 custom domain은 소유권 확인과 등록 상태를 거친 값을 사용합니다. 허용 도메인 검사에서 example.com.evil 같은 문자열이나 userinfo가 포함된 URL을 잘못 허용하지 않게 정식 파서와 정확한 비교를 사용합니다. 프록시가 X-Forwarded-Host를 전달할 때도 같은 정책이 적용되어야 하며 테스트 환경의 편한 wildcard가 운영 설정으로 넘어가지 않는지 확인합니다.

위조 Host·Forwarded·직접 앱 접속·다중 tenant 캐시를 시험합니다. URL 생성과 요청 라우팅의 신뢰 근거를 따로 확인하고 재설정 토큰은 짧은 수명·단일 사용·대상 사용자에 묶습니다. 헤더 검증은 토큰 보호의 한 경계이며 전체 복구 보안을 대신하지 않습니다.