사용자가 올린 파일을 다시 제공할 때는 응답의 Content-Type이 실제 표현과 맞는지 확인합니다. MIME을 잘못 알리면 브라우저가 콘텐츠를 다르게 해석할 수 있으므로 X-Content-Type-Options: nosniff를 함께 검토합니다.
알 수 없는 사용자 파일을 브라우저에서 바로 렌더링하지 않으려면 Content-Disposition: attachment와 보수적인 application/octet-stream을 검토합니다. 이 헤더들은 업로드 검증·저장 위치·접근 권한을 대신하지 않습니다.
업로드된 파일도 내려주는 순간 브라우저 입력이 됩니다
파일을 서버에 안전하게 보관했더라도 다시 브라우저에 전달할 때 응답 헤더에 따라 문서처럼 표시될 수 있습니다. Content-Type은 응답 본문의 미디어 유형을 알리고, X-Content-Type-Options: nosniff는 브라우저가 선언한 MIME을 무시해 유형을 추측하는 동작을 제한합니다. 콘텐츠가 사용자가 제공한 것이고 브라우저에서 렌더링될 예정이면 유형과 실제 본문이 맞는지 특히 주의해야 합니다.
가상 응답 세 개를 비교합니다
| 가상 파일 | 응답 헤더 | 브라우저 표시 의도 | 판정 |
|---|---|---|---|
| 사용자가 올린 알 수 없는 콘텐츠 | Content-Type: text/html; Content-Disposition: inline | 브라우저 안에서 문서로 렌더링 | 활성 콘텐츠 해석 위험을 검토 |
| 동일한 미확인 파일의 내려받기 | Content-Type: application/octet-stream; Content-Disposition: attachment; X-Content-Type-Options: nosniff | 인라인 대신 다운로드 유도 | 표시 위험을 줄이는 방어 조합 |
| 검증된 PNG 응답 | Content-Type: image/png; X-Content-Type-Options: nosniff | 이미지 유형을 명시 | 실제 파일과 MIME 유형 일치 여부 확인 |
두 번째 행은 브라우저에 안전한 파일이라고 증명하지 않습니다. attachment는 브라우저가 파일을 다운로드하도록 유도하고, nosniff는 MIME 추측을 줄이며, application/octet-stream은 유형을 모르는 바이너리 파일에 쓰는 보수적 유형입니다. 파일 이름이나 확장자만 보고 실제 내용 유형이 검증됐다고 단정하지 않습니다.
응답 헤더와 업로드 검증은 서로 다른 단계입니다
OWASP File Upload 지침은 업로드 요청의 Content-Type 자체를 사용자가 쉽게 위조할 수 있으므로 신뢰하지 말라고 설명합니다. 허용 확장자, 파일 서명과 내용 검사, 안전한 파일명, webroot 밖 저장, 접근 권한 등은 저장 전에 검토할 통제입니다. 다운로드 응답에 nosniff를 붙여도 이미 저장된 악성 파일이 정화되거나 권한 없는 사용자의 다운로드가 차단되지는 않습니다.
다운로드 응답 점검 순서
- 파일 유형을 서버가 어떤 근거로 결정했는지 확인합니다. 사용자가 보낸 MIME을 그대로 신뢰하지 않습니다.
- 브라우저 안에서 보여 줄 파일과 내려받게 할 파일을 제품 기능에 따라 분류합니다.
- 미확인 또는 바이너리 콘텐츠는
application/octet-stream등 보수적 유형을 검토합니다. - 인라인 표시가 필요하지 않다면
Content-Disposition: attachment를 설정합니다. - 응답에
X-Content-Type-Options: nosniff가 있는지 확인합니다. - 다운로드 권한·파일 소유자·저장 위치·검사 여부를 응답 헤더와 별도로 검증합니다.
- 지원 브라우저에서 정상 파일과 잘못된 MIME 파일의 표시·다운로드 경로를 테스트합니다.
nosniff 하나로 모든 파일 위험이 사라지지 않습니다
헤더는 브라우저가 응답을 해석하는 방식을 제어하는 방어층입니다. 악성 내용 삭제, 바이러스 검사, 권한 부여, 파일 크기 제한, 고립된 다운로드 도메인 운영은 별도 작업입니다. 문서의 헤더 조합을 적용했더라도 실제 파일과 브라우저가 어떻게 처리하는지 확인하고, 사용자 제공 파일을 신뢰된 사이트의 실행 가능한 HTML로 무심코 렌더링하지 않도록 설계해야 합니다.
복습: attachment는 파일을 정화하나요?
문제: 사용자가 보낸 HTML 파일에 attachment, application/octet-stream, nosniff를 설정했습니다. 이제 악성 파일 검사가 필요 없다고 결론 내릴 수 있나요?
정답: 아닙니다. 이 조합은 브라우저에서 인라인 실행·MIME 추측 위험을 줄이려는 응답 방어입니다. 파일 검증·저장·검사·접근 권한은 별도로 점검해야 합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
알 수 없는 사용자 제공 파일을 인라인으로 표시 중이며 응답 MIME은 text/html입니다. 어떤 다운로드 헤더를 검토할지 쓰고, 이것이 업로드 콘텐츠 검증을 대체하는지 답하세요.
정답과 해설 확인
인라인이 필요하지 않다면 Content-Disposition: attachment, 알 수 없는 바이너리는 Content-Type: application/octet-stream, 그리고 X-Content-Type-Options: nosniff를 검토합니다. 업로드 검증은 대체하지 않습니다.OWASP는 정확한 Content-Type과 nosniff, 다운로드 attachment를 권고하지만 파일 콘텐츠와 저장·권한 검증을 별도 통제로 다룹니다.