# Do your API responses send the right protective headers?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

This Deep scan check reads JSON responses from your API for nosniff, cache rules on personal data and a restricted cross-origin rule.

This check reads JSON responses from your API for three protective settings. Type sniffing should be off, personal answers should not be cacheable, and any website should not be allowed to read them.

## What does this check look at?

It looks at whether JSON responses from your API send the headers that stop type guessing, keep personal answers out of shared caches and limit which websites can read them. MDN explains that the no-store directive tells every cache, private or shared, not to store the response.

Only a Deep scan runs it, after you prove you own the site.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Medium finding | Any website may read the response. | Restrict Access-Control-Allow-Origin to trusted origins. |
| Low finding | nosniff is missing, or a personal-looking answer has no cache rule. | Add the missing headers to API routes. |

A missing header is a gap in defence, not a data leak anyone has shown. 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 | Other websites and shared caches |
| The protection that should stop it | nosniff, a cache directive or a CORS restriction is missing on a JSON response |
| What is reached | How browsers and caches handle the response |
| What follows | A hardening gap; no data access was shown |

## Which standards does it relate to?

No OWASP, CWE or ASVS reference fits this check closely enough to state, so the report and this page leave it unmapped.

## Fix it with your AI

Set these once in API middleware so every route gets them.

:::fix-prompt any
Add protective headers to every JSON response from my API, in shared middleware rather than per route. Send X-Content-Type-Options: nosniff on all of them, Cache-Control: no-store on any response that contains user or account data, and replace Access-Control-Allow-Origin: * with an allowlist of my own front-end origins unless the API is meant to be public. Show me the middleware change.
:::

## How to check

Say Atlas, our example app at `atlas.example`, returns account details from an API route with no cache header and a wildcard origin. A Deep scan flags both on that one response.

Deep scans come with the Deep plan, and [pricing](/pricing) shows what it includes. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/checks) shows the rest.

## Questions people ask

### Is a wildcard origin dangerous on a public API?

Not for data meant to be public. It matters on responses that return personal data, because any website could read them in a visitor’s browser.

### Did the scan read personal data?

No. It read the response once without credentials and kept no values.

## Sources

- [Cache-Control header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control), MDN Web Docs, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07