How this site is secured

A security engineer's website should be able to explain itself. This page documents how kiranc.me is built and hardened, and links you to independent tools so you can verify every claim rather than trust it.

// architecture: nothing to attack

The site is static HTML and CSS. The most effective security control here is subtraction:

Zero JavaScript. Nothing executes in your browser. There is no script to inject into, no DOM to poison, no client-side dependency to compromise.
Zero dependencies. No framework, no build pipeline, no node_modules. There is no supply chain to patch on someone else's schedule.
Zero third-party requests. Self-hosted fonts and images. Your browser talks to exactly one origin, and no analytics, trackers, or cookies exist to leak anything.

// response headers

Every response is served with:

Content-Security-Policy: default-src 'none': resources are denied by default, and only same-origin styles and images are allowed back in. No scripts, no frames, no forms. Trusted Types are required with no policies allowed, a DOM-XSS defense declared for a site that runs no DOM scripting at all.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload: browsers refuse plain HTTP for two years, and the domain is on the browser preload list ↗ so even the very first visit is HTTPS.
X-Frame-Options / frame-ancestors: DENY: this site cannot be embedded, which is what kills clickjacking.
Referrer-Policy: no-referrer: following a link out of this site tells the destination nothing about where you came from.
Permissions-Policy: camera, microphone, geolocation, payment, USB, and ad-topics APIs are all explicitly disabled.
COOP / COEP / CORP: the complete cross-origin isolation triad: same-origin opener policy, require-corp embedder policy, same-origin resource policy. Full process isolation, rarely all three even on major sites.
X-Content-Type-Options: nosniff: declared content types are final.

Check from your own terminal:

$ curl -sI https://kiranc.me | grep -iE 'security|policy|frame'

// dns & email posture

Minimal zone. The DNS zone holds exactly what the site needs: no stale records, no dangling subdomains pointing at machines I no longer control.
DNSSEC. The zone is cryptographically signed, so resolvers can verify these records weren't tampered with in transit. Check the chain at DNSViz ↗ or with dig +dnssec kiranc.me.
HTTPS resource record (RFC 9460). A type-65 DNS record tells browsers, before the first connection, that this name speaks HTTPS over h2, an HSTS-like signal at the DNS layer.
CAA pinning. 0 issue "letsencrypt.org" means only Let's Encrypt may issue certificates for this domain; a mis-issued cert from any other CA is invalid by policy.
This domain sends no email, and publishes policy saying so. A null SPF record (v=spf1 -all) plus a strict-alignment DMARC reject policy means any message claiming to be from @kiranc.me is spoofed, and receiving servers are instructed to drop it.
security.txt (RFC 9116): a machine-readable disclosure contact, where security tooling expects it.

// monitoring & judgment calls

Certificate Transparency monitoring. The public CT logs are checked weekly for certificates issued for this domain; anything that isn't a routine Let's Encrypt renewal for the two expected hostnames raises an alert. Detection, not just prevention.
Rejected: DANE/TLSA. Pinning certificates in DNS doesn't fit a managed platform that rotates certs automatically; a stale pin is an outage, and browsers don't validate TLSA anyway.
Rejected: CSP violation reporting. Report endpoints would have browsers ship telemetry to a third party, breaking the zero-third-party-request promise for marginal benefit on a zero-script site.
Waiting on: Encrypted Client Hello. The SNI in your TLS handshake is the one plaintext signal this site can't yet remove; ECH closes it, and lands here when the hosting edge supports it.

// verify it yourself

Don't take this page's word for any of it. The same rule applies here as to the credential badges on the certifications section. Live, third-party checks:

Mozilla HTTP Observatory ↗: full header and configuration scan, scored.
securityheaders.com ↗: independent header grade.
Certificate Transparency log ↗: every certificate ever issued for this domain, on the public record.
Qualys SSL Labs ↗: TLS configuration deep-dive.

Found something anyway? See security.txt. I'd genuinely like to know.