HTTP Security Headers: The Small Details Attackers Love You to Ignore

There is a moment every attacker waits for.

It is not the flashy RCE.
It is not the SQL injection dumping millions of records.
The real moment happens when they realize the target ignored the basics.

A missing HttpOnly.
A forgotten Content-Security-Policy.
Session cookies traveling without Secure because nobody bothered to configure them properly.

That is when the attack stops being hard.

Many developers treat HTTP Security Headers like stickers on a laptop: nice to have, but optional. In practice, those headers are often the thin line between a minimally hardened application and a trivial compromise.

And attackers know that.

The Attack Surface Almost Nobody Watches

During assessments, one of the first things I look at is not even the JavaScript framework or backend language. It is the HTTP response headers.

Because headers tell stories.

They show whether the team understands the browser security model.
They reveal how seriously the organization takes session management.
And sometimes, they practically hand over the keys to the application.

Take cookies without the HttpOnly flag, for example.

If an attacker can execute an XSS and the session cookie does not have HttpOnly, it is over. The browser hands the cookie to JavaScript without resistance, and now the attacker has the victim’s authenticated session.

No brute force.
No MFA bypass.
Just bad configuration.

Then comes the classic: the absence of the Secure flag.

An authentication cookie traveling over HTTP is basically a postcard passing through hostile territory. Anyone positioned correctly can read it.

And the industry keeps making the same mistakes.

Security Headers Are Not an “Extra Layer”

They are security.

Headers such as:

• Content-Security-Policy
• X-Frame-Options
• Strict-Transport-Security
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

exist because browsers are dangerous by default.

The browser executes JavaScript from untrusted origins.
Renders third-party content.
Stores credentials.
Maintains authenticated sessions for users who click on anything.

Security Headers exist to force the browser to operate under strict rules instead of relying on implicit behavior.

Without that, the attacker gets freedom.

And attackers like freedom.

Cookies: Small Flags, Massive Impact

Cookie flags are one of the most underestimated defensive controls on the internet.

Three small attributes can drastically reduce the impact of attacks:

• HttpOnly
• Secure
• SameSite

That is all.

Even so, countless production applications still deliver authentication cookies without these protections.

SameSite=None without any need.
Session cookies accessible via JavaScript.
Tokens traveling without encryption.

Every missing flag increases the attack surface.

From the attacker’s perspective, misconfigured cookies are a gift. They reduce complexity. They eliminate steps. They turn multi-stage attacks into simple payloads.

Why I Modified shcheck

I have always liked shcheck because it is lightweight, fast, and extremely useful for auditing HTTP Security Headers.

But during assessments, I constantly ended up manually validating cookies after running the tool.

That made no sense.

Headers and session security should go hand in hand.
Analyzing one without the other gives you an incomplete view of the application.

So I forked the project and added checks related to cookie flags directly into the tool.

https://github.com/pog007/shcheckv2

It can now identify insecure cookie configurations alongside classic security header issues, helping detect situations such as:

• Missing HttpOnly
• Missing Secure
• Weak or insecure SameSite configurations
• Inconsistent protections across cookies

Because when we talk about web security, session protection deserves the same attention as any HTTP header.

Attackers pay attention to that.

Defenders should too.

Final Thoughts

Attackers rarely need exotic techniques when basic protections are missing.

The uncomfortable truth is that many compromises happen because organizations ignore defensive details that browsers have supported for years.

Security Headers will not stop every attack.
Cookie flags will not eliminate every risk.

But they force the attacker to work harder.

And in the offensive world, friction matters.

A single missing header may seem irrelevant to a developer racing to meet a deadline.

To an attacker, it may be exactly the entry point that starts the entire compromise.