I Checked the Security Headers on 30 Nepali Government Websites

There is a claim that circulates about Nepali government websites: that a significant share run over plain HTTP, or have HTTPS misconfigured badly enough to be meaningless. I have read it in several places. Nobody publishes the measurement.

So on 5 September 2026 I checked. Thirty .gov.np domains, one HEAD request each, reading only the response headers a browser receives on an ordinary visit. No scanning, no probing, nothing that is not public.

The claim is wrong. What is actually true is narrower, more specific, and considerably easier to act on.

The headline number

All 30 responded over HTTPS with a valid certificate. Not 25, not most — all of them. Whatever was true two or three years ago, transport encryption on Nepali government domains is done.

I want to be clear about the limits of that: a valid certificate says the connection is encrypted and the domain is who it claims to be. It says nothing about the application behind it, the CMS version, or whether anybody is patching. But the specific claim I set out to test does not survive contact with the data.

What the headers actually show

That first cluster is better than I expected. Three headers at 26 of 30 is not an accident — that is a platform default. Fourteen of the thirty domains resolve to a single IP address, which strongly suggests a shared government hosting arrangement, and whoever configured it set sensible defaults. Credit where it is due.

The interesting part is the cliff. The three headers that come free with a decent server config are nearly universal. The three that require somebody to make a decision are nearly absent.

Why two of thirty on HSTS is the number that matters

Of everything above, the HSTS gap is the one I would fix first, and it is worth explaining why rather than just listing it.

Every one of these sites serves HTTPS correctly. But without HSTS, the first request a visitor makes is still typically plain HTTP, which then redirects. That first unencrypted request is the window. On a shared network — a campus, a café, a municipal office — it is enough for an attacker to intercept the redirect and hold the visitor on HTTP for the rest of the session. The padlock never appears and most people never notice it is missing.

HSTS closes that window by telling the browser to refuse HTTP for this domain in future, before any request goes out. It is one response header. For a site that already has working HTTPS — which is all thirty — it costs nothing to add and removes an entire attack class.

Twenty-eight of thirty Nepali government sites have done the expensive part and skipped the free part.

Four sites with nothing at all

Four of the thirty returned none of the six headers. Not a reduced set — none. These are also, unsurprisingly, not on the shared platform that supplies the defaults.

I am not naming them individually. The point is not to put a target on four specific government departments, and the fix is identical for all of them: it is a configuration block, not a rebuild.

The part I would actually worry about

Twenty-seven of thirty announce their server software in the response. Most of that is unremarkable — nginx/1.26.1 on seventeen sites, which is current.

Four are not unremarkable:

Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips

CentOS 7 reached end of life in June 2024. OpenSSL 1.0.2 reached end of life in December 2019. Both stopped receiving security updates years ago. Four Nepali government websites are telling every visitor, in a header, that they are running on an unsupported stack.

A further five disclose their PHP version through X-Powered-By.

Version disclosure is not itself a vulnerability, and I want to be careful not to overstate it — plenty of well-run sites disclose versions deliberately. What it does is remove work from an attacker's side. Instead of probing to find out what you are running, they read it off the response and go straight to the list of known issues for that version. When the disclosed version is one that stopped receiving patches in 2019, that list is not short.

The disclosure takes one line to turn off. The end-of-life stack underneath it does not, and that is the real finding here: the header is a symptom, and what it is a symptom of is infrastructure nobody has migrated.

What I would do, in order

1. Add HSTS to the 28 sites without it. Start with a short max-age, confirm nothing breaks, then raise it. This is the highest return in the entire list.
2. Turn off version disclosure. One directive in nginx or Apache.
3. Migrate the four EOL stacks. Slow, expensive, and the only item here that genuinely matters more than the others.
4. Add the three missing headers to the four sites that have none.
5. CSP last. It is the most powerful header and the only one that can break a working site if you get it wrong. Six sites have it; the other 24 should not rush.

Method, so you can check me

Thirty .gov.np domains, each verified by DNS resolution and an actual HTTP response before entering the sample — nothing was assumed to exist. One HEAD request per domain over HTTPS, following up to four redirects, reading the final response headers. Certificate validation was performed strictly first; any failure would have been retried leniently to distinguish "no TLS" from "bad certificate". No failures occurred.

Two domains I originally shortlisted were dropped because they are .org.np rather than .gov.np, and the article claims to be about government domains. Four candidates did not resolve or did not respond and were excluded.

This measures response headers only. It says nothing about application security, CMS patching, access control or anything behind the front door — and a site can pass every check here and still be compromised. I know that specifically: I found two live remote-code-execution backdoors on my own hosting account this year, on a site with clean headers. That is the subject of a separate piece.

The wider technical picture for Nepali business sites is in the 34-site audit, and the aggregate counts are published with the method. If you run one of these domains and want the specific result for it, ask me — I will send it rather than publish it.