X-Content-Type-Options nosniff 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

X-Content-Type-Options nosniff 기준 정리

X-Content-Type-Options는 서버가 선언한 Content-Type을 브라우저가 임의로 추정해 바꾸지 않도록 돕는 HTTP 응답 헤더다. 2026년 5월 27일 기준 MDN과 WHATWG Fetch Standard를 보면, 이 헤더는 nosniff 값 하나만 사용하며 특히 script와 style 요청에서 MIME 타입이 맞지 않으면 로딩을 차단한다.

실무에서는 정적 파일 서버, 업로드 파일 제공 경로, CDN, 프록시 캐시를 운영할 때 이 헤더와 올바른 Content-Type 설정을 함께 점검하는 편이 안전하다. 이 글은 공식 문서 기준으로 nosniff가 실제로 무엇을 막는지와 언제 빠뜨리기 쉬운지를 정리한다.

X-Content-Type-Options는 정확히 무엇을 할까?

MDN은 이 헤더를 서버가 보낸 MIME 타입을 존중하라고 브라우저에 알리는 응답 헤더로 설명한다. 핵심은 브라우저가 응답 본문 내용을 보고 다른 타입으로 추정하는 동작, 즉 MIME sniffing을 줄이는 데 있다.

문법은 단순하다. 공식 문서 기준으로 사용할 수 있는 값은 nosniff 하나뿐이다. 즉 이 헤더는 세부 정책을 여러 값으로 조정하는 형태가 아니라, 켜거나 끄는 성격에 가깝다.

nosniff가 막는 것은 무엇일까?

Fetch Standard는 nosniff가 있을 때 요청 목적지가 script 계열인데 MIME 타입을 파싱할 수 없거나 JavaScript MIME 타입이 아니면 차단하도록 정의한다. style 요청도 마찬가지로 text/css가 아니면 차단한다.

MDN은 여기에 더해, 다른 응답 유형에서는 브라우저가 선언된 Content-Type을 그대로 사용하고 내용을 보고 HTML 등으로 추정하지 않는다고 설명한다. 예를 들어 본문에 HTML 마크업이 있어도 Content-Type: text/plain과 X-Content-Type-Options: nosniff를 함께 보내면 브라우저는 이를 HTML 문서로 해석하지 않는다.

왜 보안 설정으로 자주 같이 언급될까?

MDN의 보안 가이드는 모든 사이트가 X-Content-Type-Options: nosniff를 설정하고, 동시에 각 파일에 맞는 Content-Type을 정확히 보내야 한다고 권장한다. 잘못된 MIME 타입을 선언한 스크립트나 스타일시트가 우연히 실행되거나 해석되는 일을 줄이기 때문이다.

특히 사용자가 올린 파일을 그대로 제공하는 경로나, 프록시가 원본의 Content-Type을 잘못 전달할 수 있는 환경에서는 이 헤더만 넣는 것으로 끝나지 않는다. 응답 헤더 자체가 정확해야 하고, 업로드 파일을 HTML이나 JavaScript로 오해할 수 없도록 타입과 제공 위치를 함께 관리해야 한다.

언제 효과를 체감하기 쉬울까?

1. 정적 자산의 MIME 타입이 잘못 나갈 때

app.js가 실수로 text/plain으로 나가면, nosniff가 없는 환경에서는 브라우저별 동작 차이가 문제를 숨길 수 있다. 반면 nosniff가 있으면 스크립트 로딩이 차단되어 설정 오류가 더 빨리 드러난다.

2. 업로드 파일을 별도 도메인 없이 직접 제공할 때

MDN은 브라우저가 비HTML 타입 응답을 HTML로 해석하지 않도록 만드는 효과를 설명한다. 따라서 사용자 업로드 파일을 같은 서비스 안에서 제공하는 경우, Content-Type과 nosniff 조합은 기본 점검 항목에 가깝다.

3. CDN이나 리버스 프록시가 헤더를 바꿀 수 있을 때

원본 서버는 올바르게 설정했더라도, 중간 계층이 Content-Type을 잘못 캐시하거나 기본 타입으로 덮어쓸 수 있다. 이 경우 nosniff는 문제를 숨기지 않고 드러내는 역할을 한다.

무엇을 함께 확인해야 할까?

• Content-Type이 실제 파일 종류와 맞는지 확인해야 한다.
• 스크립트는 JavaScript MIME 타입으로, 스타일시트는 text/css로 나가야 한다.
• 업로드 파일 제공 경로가 애플리케이션 본문과 같은 origin인지 분리 전략이 필요한지 검토해야 한다.
• CSP, 다운로드 강제, 별도 파일 도메인 같은 다른 방어 수단이 필요한지 함께 봐야 한다.

X-Content-Type-Options는 리소스 출처 허용 범위를 정하는 정책은 아니다. 어떤 스크립트를 어디서 불러올 수 있는지는 CSP 같은 별도 정책이 담당한다. 따라서 nosniff는 MIME 타입 검증 축의 설정으로 이해하는 편이 정확하다.

 

 

기본값처럼 생각해도 될까?

MDN의 보안 가이드는 모든 사이트에 nosniff 설정을 권장한다. 다만 이것은 헤더 하나만 추가하면 끝난다는 뜻이 아니라, 잘못된 MIME 타입을 내보내는 자산이 없는지 먼저 확인하라는 의미에 가깝다.

운영 중인 서비스에 이 헤더를 새로 켜면, 이전에는 브라우저가 관대하게 받아주던 잘못된 정적 파일 설정이 바로 드러날 수 있다. 그래서 적용 전에는 자주 쓰는 JavaScript, CSS, 업로드 파일 응답 헤더를 먼저 점검하는 편이 현실적이다.

FAQ

Q. 값은 nosniff 말고 다른 것도 있나?

2026년 5월 27일 기준 MDN과 Fetch Standard는 X-Content-Type-Options에 대해 nosniff만 정의한다. 다른 값으로 세밀한 정책을 조정하는 헤더는 아니다.

Q. JavaScript와 CSS에만 영향이 있나?

Fetch Standard는 차단 규칙을 script 계열과 style 목적지에 대해 명시한다. MDN은 여기에 더해, 다른 응답 유형에서도 선언된 Content-Type을 그대로 사용해 HTML 등으로 추정하지 않는 효과가 있다고 설명한다.

Q. Content-Type이 정확하면 굳이 필요 없을까?

MDN 보안 가이드는 정확한 Content-Type과 nosniff를 함께 권장한다. 즉 둘 중 하나를 고르는 관계가 아니라 같이 설정하는 관계에 가깝다.

정리

X-Content-Type-Options: nosniff는 브라우저가 MIME 타입을 추정해 스크립트나 스타일시트를 받아들이는 일을 줄이고, 다른 응답도 선언된 타입대로 해석하도록 돕는 기본 방어선이다. 2026년 5월 27일 기준 공식 문서상 핵심은 간단하다. nosniff를 켜고, Content-Type을 정확히 보낸다.

실무에서 확인할 기준도 명확하다. 정적 파일 서버, CDN, 업로드 파일 경로에서 실제 응답 헤더가 올바른지 먼저 보고, 그다음 nosniff를 일관되게 적용하는 편이 안전하다.

참고 자료

• MDN: X-Content-Type-Options header
• MDN: MIME type verification
• WHATWG: Fetch Standard