What Your Website Says Before the Page Even Loads

A practical look at HTTP response headers, security headers, caching, CORS, cookies, and the information your server quietly sends with every request

When someone visits a website, the visible page is only part of the conversation.

Before the browser renders a heading, loads an image, or gives JavaScript another opportunity to ruin your afternoon, the server sends an HTTP response containing a collection of headers.

These headers can influence security, caching, privacy, cross-origin behavior, cookies, content handling, and even what the browser is allowed to do with the page.

Most visitors will never see them.

Developers probably should.

That was the idea behind ScanHeaders.com, a small web tool I built to make HTTP response headers easier to inspect and understand.

https://scanheaders.com/

HTTP headers are small, but they carry a lot of responsibility

A typical response may contain headers such as:

• Content-Security-Policy • Strict-Transport-Security • Cache-Control • Referrer-Policy • Permissions-Policy • Content-Type • Set-Cookie • Vary • ETag • CORS-related headers • Server and proxy information

Some of these directly affect browser security. Others control caching, cross-origin access, cookies, or response handling.

And some are simply informational.

That distinction matters.

A missing header is not automatically a vulnerability, and the presence of a header does not automatically mean it is configured well. Security would be much easier if configuration worked like collecting Pokémon cards, but unfortunately context still exists.

Security headers are only one part of the picture

Security headers tend to get most of the attention.

For good reason.

A strong Content-Security-Policy can limit which scripts, styles, images, and other resources a browser is allowed to load. HSTS can tell browsers to use HTTPS for future requests. X-Content-Type-Options: nosniff can prevent certain types of MIME confusion.

But a useful response-header review should go beyond a simple "security headers present or missing" report.

Caching matters too.

A response may be perfectly secure while still being cached in a way that causes stale content, poor performance, or wonderfully mysterious behavior five minutes before a deadline.

That is why ScanHeaders separates findings into areas such as Security Headers, Caching Headers, and CORS & Cookies.

Security Headers: https://scanheaders.com/security-headers/

Caching Headers: https://scanheaders.com/caching-headers/

CORS & Cookies: https://scanheaders.com/cors-cookies/

CORS is more nuanced than "wildcard bad"

Cross-Origin Resource Sharing is another area where simplistic scanners can produce misleading results.

For example:

Access-Control-Allow-Origin: *

is not inherently insecure.

For a public resource that is intentionally available to anyone, a wildcard may be completely appropriate.

The important questions are things like:

• Is the response supposed to be public? • Are credentials involved? • Are cookies or authorization headers expected? • Is the server reflecting arbitrary origins? • Are several CORS headers contradicting one another?

The browser cares about combinations and context.

A scanner should too.

"Wildcard detected, panic immediately" makes for dramatic dashboards, but not especially useful analysis.

Cookies deserve the same treatment

Cookie attributes can affect confidentiality, cross-site behavior, and JavaScript access.

Important attributes include:

Secure HttpOnly SameSite Domain Path Partitioned

But again, context matters.

Not every cookie needs HttpOnly. Some cookies are deliberately read by JavaScript.

SameSite=None is not automatically bad either. It is required for legitimate cross-site cookie use, although modern browsers require it to be combined with Secure.

A useful report should explain what was observed without pretending to understand the entire architecture of an application from one HTTP response.

That would be impressive, but it would also be fiction.

Caching headers are surprisingly easy to misunderstand

One classic example is:

Cache-Control: no-cache

Despite the name, this does not mean "never store this response."

Because apparently naming things clearly would have been too relaxing.

It generally means the response may be stored, but it must be revalidated before reuse.

If storage should be prohibited, no-store is the more relevant directive.

Headers such as ETag, Last-Modified, Expires, and Vary also influence how browsers and intermediate caches behave.

These details matter for performance, but they can also matter when content changes frequently or when responses vary by things such as encoding or request headers.

Raw headers still matter

Automated interpretation is useful, but sometimes you simply want to see exactly what the server returned.

That is why I wanted ScanHeaders to retain a Raw Response Headers section rather than hiding everything behind friendly summaries.

Custom headers, CDN headers, framework headers, hosting headers, proxy headers, and future HTTP fields can all appear there.

The scanner does not need to invent a security judgment for every unknown header.

Sometimes the correct answer is simply:

"This is what your server sent."

Which is less exciting than a flashing red warning badge, but considerably more useful.

A header scan is not a security audit

This part matters.

HTTP response headers are one layer of a website.

They cannot tell you whether application code contains an SQL injection vulnerability, whether authentication is implemented correctly, whether a dependency is compromised, or whether a server has an unrelated configuration problem.

A good header report is a technical snapshot.

It can reveal useful information, configuration mistakes, and areas worth reviewing, but it should not be treated as proof that a site is secure.

A green report is nice.

It is not a magical certificate of immortality.

I wrote more about the actual scanning process and its limitations here:

https://scanheaders.com/how-scans-work/

Keeping the tool deliberately small

ScanHeaders itself is intentionally lightweight.

There is no user account system, no permanent personal scan history, no advertising stack, and no giant application framework sitting behind the input box waiting for an excuse to become a platform.

The site is built with PHP, HTML, CSS, and vanilla JavaScript.

The scanner focuses on one job: request a public website, inspect the HTTP response, and present the returned information in a form that is easier to understand.

That simplicity was intentional.

There are plenty of tools that try to become an entire security platform.

Sometimes you just want to know what the server sent.

Preferably without excavating developer tools, twelve tabs, and three documentation pages to figure it out.

Try ScanHeaders