Security headers check

Every page your app serves comes with a set of instructions for the browser. They are called response headers, and they decide whether the browser insists on an encrypted connection, whether another site can load your app inside a frame, which scripts are allowed to run, and how much of your address is handed to the next site a visitor clicks through to. None of that is visible on the page. All of it is visible from the outside, which is exactly what this tool reads.

This is the gap almost every AI-built app ships with, and the reason is simple. Nobody writes headers. Your framework does not add them, the builder that generated your app does not add them, and your host adds one or two at most. An agent is asked to make a feature work, and a missing header never stops a feature from working. The app looks finished from the inside while the browser is being told nothing at all.

What that costs is ordinary rather than dramatic. Without strict transport security, one visitor typing the address on airport wifi gets a plain connection that anybody on that network can read. Without frame protection, your signed-in pages can be loaded invisibly inside someone else's page and clicked on behalf of your users. Without a content policy, a single injected script runs with the same authority as your own code.

The tool requests your published address once, records the status and the headers that came back, and reports each one with the evidence line it was read from and the date it was read. Findings that are already in place are shown too, because knowing what is right is part of knowing where you stand. Nothing is written to your app, nothing signs in, and no result here says an app is free of problems.

This page is for running the check. The finding page explains the issue itself, and it is the page to read or link when you want the explanation rather than the test. Read the finding page.