reveal what a server confesses in its http headers

your server talks more than you think

before anyone runs a scanner, drops a payload, or does anything fancy, they usually just ask your server a polite question and let it answer. http headers are that answer. every response your web server sends back carries little metadata tags, and a lot of admins never bother to check what those tags are actually confessing to the world.

this one's a classic recon move because it costs nothing, leaves barely a trace, and works against basically any live website. so let's break down the command, see what it pulls, and then fix your own exposure.

the command

curl -sI https://example.com | grep -iE 'server|x-powered|set-cookie'

here's what each piece is doing:

curl -sI sends a request and only asks for the headers, not the full page body. the -s flag means silent, so curl skips the progress bar noise, and -I tells it to do a HEAD request instead of pulling the whole page.

https://example.com is obviously the target. swap in your own domain, not someone else's.

grep -iE 'server|x-powered|set-cookie' filters the wall of headers down to the interesting ones. the -i makes it case insensitive, and -E lets you use that pipe-separated pattern to match multiple keywords in one pass.

what these headers actually confess

the Server header often names the exact web server software and version, like nginx 1.18 or apache 2.4.41. that version number is a gift to anyone checking for known cves against outdated builds.

the X-Powered-By header tends to snitch on your backend framework, php version, express, asp.net, whatever's running the logic behind the scenes. again, version numbers here map directly to public exploit databases.

the Set-Cookie header can leak session cookie names that hint at your cms or framework (think wordpress_logged_in, laravel_session, phpsessid), and it also tells you whether those cookies are missing security flags like Secure, HttpOnly, and SameSite. if those flags aren't there, session hijacking gets a lot easier for anyone sniffing traffic or running xss.

why this matters for defenders

none of this requires logging in, brute forcing anything, or touching your infrastructure directly. it's completely passive from your server's point of view, your logs will just show a normal request. that's exactly why it's step one in almost every recon workflow, and exactly why you should be running it against your own stuff before someone else does.

the goal isn't to make your server silent and paranoid, it's to stop it from handing out a version-specific roadmap for free.

how to lock this down

start by checking what you're currently exposing:

curl -sI https://yourdomain.com

if you see specific version numbers next to Server or X-Powered-By, strip them:

• nginx: add server_tokens off; in your nginx.conf to drop the version string.
• apache: set ServerTokens Prod and ServerSignature Off in httpd.conf.
• php: set expose_php = Off in php.ini to kill the X-Powered-By: PHP header entirely.
• express/node: use the helmet middleware, it disables the X-Powered-By header automatically along with a bunch of other useful defaults.

for cookies, make sure your app or framework is setting Secure, HttpOnly, and SameSite=Strict or Lax on every session cookie. most modern frameworks let you set this globally in one config line, there's no reason to skip it.

and separately from hiding headers, actually patch your stuff. hiding a version number doesn't fix a vulnerability, it just makes the attacker work slightly harder to guess it. keep your server software, php, and dependencies updated regardless of what your headers say.

the takeaway

your headers are a handshake, and right now they might be handing out way more than a polite hello. run the command on your own domain, see what you're leaking, strip the version info, lock down your cookies, and patch the underlying software anyway. it takes ten minutes and it closes off the easiest, quietest recon path there is.