“X-Content-Type-Options: nosniff” 대체 뭐길래?

들어가며

웹사이트를 개발하거나 API 응답을 확인하다 보면 크롬 개발자 도구의 Network 탭에서 낯선 HTTP 응답 헤더를 하나씩 발견하게 됩니다.

그중에서도 처음 보면 조금 특이하게 느껴지는 것이 있습니다.

바로

X-Content-Type-Options: nosniff

입니다.

이름부터 상당히 길고 어렵게 느껴지지만, 실제로 하는 일은 비교적 단순합니다.

쉽게 이야기하면 브라우저가 서버가 지정한 콘텐츠 타입(Content-Type)을 임의로 추측해서 다른 방식으로 해석하지 않도록 하는 보안 설정입니다.

웹사이트를 분석하다가 이 헤더를 발견했다면 “이 사이트는 어떤 보안 설정을 사용하고 있구나” 정도로 이해하면 됩니다.

오늘은 개발자 도구에서 자주 볼 수 있는 X-Content-Type-Options: nosniff가 무엇인지, 왜 필요한지, 그리고 직접 어떻게 확인할 수 있는지 정리해보겠습니다.

X-Content-Type-Options란?

먼저 이름부터 나눠서 보면 이해하기 쉽습니다.

X-Content-Type-Options는 HTTP 응답 헤더의 하나입니다.

그리고 그 값으로 nosniff가 지정되어 있는 경우가 일반적입니다.

즉 다음과 같은 형태입니다.

X-Content-Type-Options: nosniff

여기서 핵심은 마지막에 있는 nosniff입니다.

sniff라는 단어는 여기에서 브라우저가 콘텐츠의 실제 형식을 추측하는 동작을 의미한다고 생각하면 이해하기 쉽습니다.

브라우저가 서버에서 받은 파일을 처리할 때 서버가 전달한 Content-Type을 참고하는데, 특정 상황에서는 콘텐츠의 내용을 보고 형식을 추측하는 동작이 문제가 될 수 있습니다.

nosniff는 이런 MIME 타입 추측을 제한하도록 브라우저에 지시하는 역할을 합니다.

Content-Type과 어떤 관계가 있을까?

nosniff를 이해하려면 Content-Type도 함께 알아두는 것이 좋습니다.

서버는 브라우저에 데이터를 보내면서 해당 데이터가 어떤 종류인지 알려줍니다.

예를 들어 HTML이라면

Content-Type: text/html

JavaScript라면

Content-Type: text/javascript

이미지라면 이미지 형식에 맞는 MIME 타입을 전달할 수 있습니다.

브라우저는 이 정보를 참고해서 받은 데이터를 어떻게 처리할지 결정합니다.

문제는 서버가 콘텐츠 타입을 잘못 설정했거나, 예상하지 못한 방식으로 파일이 전달되는 경우입니다.

이때 브라우저가 콘텐츠의 실제 내용을 보고 “아마 이것은 이런 종류의 파일인 것 같다”고 추측해서 처리하는 것을 막기 위해 nosniff가 사용됩니다.

nosniff는 왜 필요한가?

이 설정이 중요한 이유는 웹 보안과 관련이 있기 때문입니다.

웹 브라우저는 단순히 화면에 글자만 보여주는 프로그램이 아닙니다.

HTML, JavaScript, CSS, 이미지 등 다양한 종류의 콘텐츠를 받아서 각각 다른 방식으로 처리합니다.

만약 콘텐츠의 종류를 서버가 제대로 지정하지 않았는데 브라우저가 내용을 보고 임의로 해석한다면 예상하지 못한 문제가 발생할 수 있습니다.

특히 공격자가 웹사이트에 악성 콘텐츠를 삽입할 수 있는 상황에서는 MIME 타입 처리 방식이 보안 문제와 연결될 가능성이 있습니다.

그래서 서버가 정확한 Content-Type을 보내고 브라우저가 이를 엄격하게 따르도록 만드는 것이 중요합니다.

X-Content-Type-Options: nosniff는 바로 이런 상황에서 보안 방어층의 하나로 사용됩니다.

개발자 도구에서 어떻게 확인할까?

직접 확인하는 방법은 어렵지 않습니다.

크롬에서 원하는 웹사이트를 열고 F12를 눌러 개발자 도구를 실행합니다.

그다음 Network 탭으로 이동합니다.

페이지를 새로고침하면 브라우저가 서버에 요청한 여러 파일이 목록에 나타납니다.

HTML 파일이나 CSS, JavaScript, 이미지, API 요청 등 다양한 항목이 보일 것입니다.

여기에서 하나를 클릭한 다음 Headers 메뉴를 확인합니다.

아래쪽의 Response Headers 영역을 살펴보면 여러 HTTP 응답 헤더가 표시됩니다.

그중 다음과 같은 항목이 있다면 해당 응답에 nosniff 정책이 적용되어 있는 것입니다.

X-Content-Type-Options: nosniff

사이트에 따라 모든 응답에 동일하게 적용될 수도 있고, 특정 리소스에만 적용되어 있을 수도 있습니다.

따라서 개발자 도구에서 여러 요청을 클릭해보면서 헤더가 어떻게 설정되어 있는지 비교해보는 것도 좋은 방법입니다.

Content-Type을 잘못 설정하면 어떻게 될까?

여기에서 nosniff가 실제로 어떤 영향을 주는지 궁금할 수 있습니다.

예를 들어 JavaScript 파일을 서버에서 제공하고 있다고 생각해보겠습니다.

서버는 브라우저에 JavaScript 파일이라고 알려줘야 합니다.

그런데 서버가 잘못된 MIME 타입을 전달하면 브라우저가 해당 파일을 정상적으로 처리하지 못할 수 있습니다.

특히 nosniff가 적용된 상황에서는 브라우저가 서버의 Content-Type을 무시하고 임의로 다른 형식이라고 판단하는 것을 제한하기 때문에, 잘못된 서버 설정이 오히려 바로 문제로 나타날 수도 있습니다.

개발자 입장에서는 이것이 불편하게 느껴질 수 있지만, 반대로 생각하면 서버에서 잘못된 콘텐츠 타입을 보내고 있다는 사실을 빠르게 발견할 수 있다는 장점도 있습니다.

nosniff 때문에 JavaScript가 실행되지 않는 경우

웹 개발을 하다 보면 가끔 JavaScript 파일을 분명히 불러왔는데 실행되지 않는 문제가 발생할 수 있습니다.

이럴 때 콘솔에 MIME 타입과 관련된 오류가 표시되는 경우가 있습니다.

이런 상황이라면 무조건 JavaScript 코드 자체를 의심하기보다 Network 탭에서 해당 .js 파일의 응답을 확인해볼 필요가 있습니다.

특히 다음 항목을 같이 확인하면 좋습니다.

• Request URL
• Status Code
• Content-Type
• X-Content-Type-Options
• Response

JavaScript 파일을 요청했는데 서버가 엉뚱한 콘텐츠를 반환하고 있거나 Content-Type이 제대로 설정되어 있지 않다면 코드가 정상적으로 실행되지 않을 수 있습니다.

예를 들어 서버 설정 문제로 JavaScript 요청에 HTML 오류 페이지가 반환되는 경우도 있습니다.

이런 경우 소스 코드를 아무리 수정해도 문제가 해결되지 않습니다.

Network 탭을 확인해야 원인을 찾을 수 있습니다.

nosniff가 있다고 해서 무조건 완벽하게 안전한 것은 아니다

여기서 한 가지 중요한 점이 있습니다.

X-Content-Type-Options: nosniff가 설정되어 있다고 해서 웹사이트의 보안 문제가 모두 해결되는 것은 아닙니다.

웹 보안은 하나의 HTTP 헤더만으로 완성되는 것이 아니기 때문입니다.

HTTPS 적용 여부부터 시작해서 Content Security Policy(CSP), 쿠키의 보안 설정, 인증 및 권한 관리, 입력값 검증 등 여러 가지 요소가 함께 고려되어야 합니다.

따라서 nosniff는 웹 보안을 위한 여러 방어 수단 가운데 하나라고 생각하는 것이 가장 정확합니다.

개발자 도구를 공부하면 보이는 것들

처음에는 개발자 도구의 Headers 영역에 영어가 너무 많아서 무엇을 봐야 할지 모를 수 있습니다.

하지만 하나씩 의미를 알아가다 보면 상당히 많은 정보를 확인할 수 있습니다.

앞서 살펴본 Request Method에서는 GET이나 POST 같은 요청 방식을 확인할 수 있고, Cache-Control에서는 캐시와 관련된 정책을 살펴볼 수 있습니다.

그리고 이번에 알아본

X-Content-Type-Options: nosniff

에서는 브라우저의 콘텐츠 타입 처리와 관련된 보안 설정을 확인할 수 있습니다.

이런 항목들을 하나씩 연결해서 보면 단순히 웹페이지를 보는 것과는 완전히 다른 시각으로 웹사이트를 바라볼 수 있게 됩니다.

마무리

X-Content-Type-Options: nosniff는 이름만 보면 상당히 어려운 보안 기술처럼 보입니다.

하지만 핵심만 정리하면 간단합니다.

서버가 전달한 콘텐츠 타입을 브라우저가 마음대로 추측해서 처리하지 않도록 하는 보안 관련 HTTP 응답 헤더입니다.

개발자 도구에서 이 항목을 발견했다면 Content-Type과 함께 확인해보는 것이 좋습니다.

특히 JavaScript나 CSS 같은 리소스가 제대로 동작하지 않을 때 MIME 타입과 관련된 문제가 없는지 확인하는 데 도움이 됩니다.

앞으로 크롬 개발자 도구의 Network 탭을 볼 때 단순히 파일이 정상적으로 로딩됐는지만 확인하지 말고 Response Headers도 한 번씩 살펴보세요.

처음에는 복잡해 보이던 HTTP 헤더들이 하나씩 눈에 들어오기 시작하면, 웹사이트가 브라우저와 어떻게 통신하고 어떤 방식으로 보안을 적용하고 있는지도 조금씩 이해할 수 있게 됩니다.