Weak transport-security response headers
The server is missing one or more standard security headers on its responses, or opens itself to any browser origin.
What it means
The scanner reads the response headers that come back on the first probe and reports four common problems: - Access-Control-Allow-Origin set to "*" together with Access-Control-Allow-Credentials "true". Browsers reject this combination and it is often an auth bypass misconfiguration. "*" alone is also flagged with a milder note because it opens the server to any browser origin. - No Strict-Transport-Security header on an HTTPS endpoint. The first connection over HTTPS is still open to a downgrade attack. - No X-Frame-Options and no frame-ancestors directive in a Content-Security-Policy, or a frame-ancestors directive that allows anyone. The response can be framed cross-origin. - X-Content-Type-Options is not "nosniff". Error responses may be MIME-sniffed by browsers. All four are passive. No extra request is made. The check stays silent if the server was not reachable.
How to fix
Set X-Content-Type-Options: nosniff on every response. On HTTPS set Strict-Transport-Security with a max-age of at least 15552000. Set X-Frame-Options: DENY or a Content-Security-Policy with a restrictive frame-ancestors directive (not "*"). Review Access-Control-Allow-Origin if the endpoint is not meant to be reachable from arbitrary browser origins.
Run the check against your own server:
npx -y @patchbay-nebius/agent audit <url-or-directory>No install: scan an MCP server in the browser and get a shareable report.
Disagree with this finding on your server? Open an issue with the --json output. False-positive reports are the most useful feedback.