검증과 용량 제한

파일 시그니처로 봅니다. 확장자와 클라이언트가 보낸 타입은 근거가 되지 않습니다.

시그니처도 완벽하지는 않습니다. 앞부분만 정상으로 위장할 수 있습니다. 그래서 이미지처럼 다시 인코딩할 수 있는 형식은 변환해서 다시 저장하는 편이 안전합니다. 변환이 성공하면 그것이 곧 검증이고, 숨어 있던 데이터도 함께 사라집니다.

흔한 실수: 확장자 허용 목록으로 충분하다고 답하는 것. 허용 목록은 실수로 올린 파일을 걸러 주지만 의도적인 우회는 막지 못합니다. 두 목적을 구분해야 합니다.

격리 영역과 공개 영역을 나눕니다. 상태 컬럼만으로 구분하지 않습니다.

1) 클라이언트가 격리 영역에 올린다
2) 완료 통보를 받고 검사한다
3) 통과하면 공개 영역으로 옮긴다
4) 실패하면 지우고 알린다

같은 자리에 두고 상태 컬럼으로만 구분하면, 어딘가에서 상태 확인을 빠뜨렸을 때 검사 전 파일이 그대로 노출됩니다. 조회 경로가 여러 개면 전부에 조건을 넣어야 하고, 하나만 빠져도 구멍이 됩니다.

경계는 코드가 아니라 저장 위치로 만드는 편이 안전합니다. 공개 영역에 있다는 것 자체가 검사를 통과했다는 뜻이 됩니다.

흔한 실수: 검사를 동기로 만들어 업로드 응답을 늦추는 것. 직접 업로드는 앱이 사후에만 보므로 애초에 동기 검사가 불가능하고, 억지로 맞추면 앱을 다시 경로에 넣는 셈입니다.

업로드 세션 단위로 따로 셉니다. 파트별 서명으로는 막을 수 없습니다.

서명은 한 번의 요청을 제한합니다. 파트 하나에 10MB 상한을 걸어도, 파트를 계속 올리면 전체 크기는 얼마든 커집니다.

그래서 업로드를 시작할 때 선언한 크기를 기록하고, 파트 서명을 발급할 때마다 누적을 확인해 초과하면 더 발급하지 않습니다. 선언 크기 자체도 서버 정책과 대조합니다.

흔한 실수: 파트 개수 상한으로 대신하려는 것. 파트 크기가 가변이면 개수 상한이 전체 크기를 정하지 않습니다. 세야 하는 것은 바이트입니다.

요구사항입니다. 무엇을 포기할 수 있는지가 검증 깊이를 정합니다.

모든 파일을 깊게 검사하면 비용과 지연이 커집니다. 이 서비스는 실시간 미리보기가 범위 밖이라, 검사가 몇 초에서 몇 분 걸려도 됩니다. 그동안 목록에 안 보이면 사용자는 눈치채지 못합니다.

흔한 실수: 검증을 보안 요구로만 보고 최대한 깊게 하려는 것. 검증은 지연과 비용을 쓰는 선택이고, 그 예산은 요구사항에서 나옵니다. 무엇을 검사하지 않을지 말할 수 있어야 설계가 끝난 것입니다.