Does your site stop browsers from guessing file types?
The file type check looks for the X-Content-Type-Options header set to nosniff on your responses. It tells browsers to trust the file type your server declares instead of guessing from the content.
What does this check look at?
It looks at whether responses tell browsers not to guess a file type. MDN says the header indicates that the declared types should be respected and not changed. Lockpick's own guide puts it this way. Content type protection stops the browser from guessing what a file is, which could turn an uploaded image into a script.
Pulse and Deep scans both run it.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Pass | The responses read send nosniff. | Nothing. |
| Attention | At least one response did not. | Add the header to every response. |
A missing setting is a hardening gap, not proof that any file can be run as a script. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.
How serious is a finding?
Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. The report lists what to fix by how directly someone could use it, not by the severity label.
What does a confirmed finding have to show?
| Part | For this check |
|---|---|
| Where it starts | Content or a frame an attacker can influence |
| The protection that should stop it | A browser protection header is missing or weak |
| What is reached | How browsers treat your pages |
| What follows | A hardening gap; no exploit was shown |
Which standards does it relate to?
| Standard | Reference |
|---|---|
| OWASP Top Ten | A02:2025 Security Misconfiguration |
| CWE | CWE-693 |
| ASVS | v5.0.0-3.4.4 |
Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.
Fix it with your AI
This is one header, safe to add almost everywhere, as long as your files declare the right type.
Add the response header X-Content-Type-Options: nosniff to every response my site serves, including pages, scripts, styles and API responses. Set it once in my host or framework config. Then check that my scripts, stylesheets and fonts still load, since browsers will now refuse a script served with the wrong Content-Type.How to check
Say Atlas, our example app at atlas.example, sets nosniff on pages but not on uploaded files. The check names the response that lacked it.
The free quick check covers this on your homepage with no account, and a Pulse scan from your account adds your scripts and public records. Pulse or Deep explains the difference.
Questions people ask
Can adding nosniff break my site?
Only when a file is served with the wrong type, for example a script labelled as text. The fix is to correct the type, which is worth doing anyway.
Is this the same check as the one on API responses?
No. API responses have their own check in Deep scans, which also looks at caching and cross-origin rules.
See what your site shows from outside
A quick check reads your homepage the way a visitor would and gives you a score. No account needed.
Check your siteSources
- How we rate findings Lockpick docs, read on October 7, 2026
- Security settings your site sends to browsers Lockpick docs, read on October 7, 2026
- X-Content-Type-Options header MDN Web Docs, read on October 7, 2026