Web security · XB Field Notes

Certificate expiry is a date, not a dashboard color

Wed, 10 Jun 2026 00:00:00 +0000

An HTTPS process can be healthy while the public certificate is close to expiry, issued for the wrong name, or served differently on another edge. A useful check asks the public endpoint for the certificate it would give to a real client.

Inspect the certificate a real client sees, then verify separately. Expiry alerts need a service-specific response threshold, handshake checks, renewal-failure alerts, and sampling of relevant edges and address families.

Include the hostname

TLS virtual hosting depends on the server name. Pass the hostname as SNI and inspect the peer certificate:

host=www.example.test
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
 | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256

The command is read-only. It does not renew anything and it does not prove that every intermediate certificate is accepted by every client. It does give you the not-before, not-after, subject, issuer, and fingerprint of the certificate presented for that hostname.

Alert on a threshold

Choose a threshold that leaves time for a failed renewal, a DNS problem, and a human response. The exact number belongs to the service’s recovery target; a universal “30 days” rule is not a substitute for that decision. The companion TLS expiry check prints the expiry and exits non-zero when the remaining interval is below the threshold you pass.

Run the check from outside the host when possible. A local process may see a different listener, certificate file, or proxy path than a visitor on the public network.

Separate observation from verification

SNI selects a virtual host; it does not verify that the certificate matches that name. This pipeline prints a certificate even when s_client reports verification problems, and stderr is suppressed. Use a separate hostname-and-chain verification check with visible diagnostics and a known trust store. Do not turn this inspection pipeline’s final exit code into a TLS-health verdict.

The companion helper tests notAfter with OpenSSL -checkend; it does not establish hostname validity, trust, revocation status, or that notBefore has arrived. Pair expiry alerts with handshake checks and renewal-failure alerts. Choose a threshold smaller than the certificate’s normal lifetime, especially for short-lived certificates, and sample each relevant edge/address family.

Sources

Caddy Automatic HTTPS, automatic TLS certificate management, checked 2026-10-15.
OpenSSL s_client documentation, SNI and certificate inspection options, checked 2026-10-15.
OpenSSL x509 documentation, certificate parsing, dates, and fingerprints, checked 2026-10-15.

HSTS should be rolled out with a recovery plan

Tue, 23 Jun 2026 00:00:00 +0000

HTTP Strict Transport Security tells a supporting browser to use HTTPS for a host during a cached period. That persistence is the feature and the risk: removing the header does not immediately erase policy already stored by clients.

Extend HSTS only after observation. Decide descendant scope and preload separately. Recovery needs valid HTTPS and cannot instantly erase every stored or preloaded policy.

Verify the HTTPS path first

Before sending HSTS, confirm that the canonical hostname serves a valid certificate and that HTTP redirects to the intended HTTPS URL without depending on user input:

curl -sS -D - -o /dev/null --max-redirs 0 http://www.example.test/
curl -sS -D - -o /dev/null https://www.example.test/

Check representative deep routes and error pages. HSTS cannot repair a certificate error because the browser requires a valid HTTPS connection before accepting the policy.

Start with a short max-age

A staged rollout limits the recovery window while configuration is new:

Strict-Transport-Security: max-age=300

After observing the site and renewal path, increase the duration deliberately. Record the date, chosen value, and rollback conditions. A final policy might use a year, but the number is a commitment rather than a scanner score.

Treat includeSubDomains as a separate decision

includeSubDomains extends policy to every subdomain. Inventory names first, including old services, delegated zones, and hostnames used only on internal networks. One HTTP-only descendant is enough to make the option disruptive for clients that received the parent policy.

Preload is not ordinary header configuration

Browser preload programs can distribute policy outside the normal response cycle. Their requirements and removal delays are stricter than setting a header. Do not request preload merely because a scanner recommends it; confirm long-term ownership of the domain and all covered names.

Verify the public response

curl -sS -D - -o /dev/null https://www.example.test/ \
 | awk 'tolower($1) == "strict-transport-security:" { print }'

Test the canonical public edge, not only an origin port. Proxies may add, remove, or duplicate the header.

Know what rollback can clear

A valid HTTPS response with max-age=0 clears that host’s learned policy only for clients that receive it. Removing the header or sending it over HTTP does not clear a cached policy. A child cannot opt out of a parent’s still-active includeSubDomains, and clearing a parent does not delete policies independently learned for children.

Scope follows the host that sends the header: policy from www.example.test covers that host and, with includeSubDomains, its descendants, not the sibling api.example.test or the parent example.test. Keep HTTPS working during recovery. Preload removal is a separate browser-update process, not an immediate response-header rollback.

Sources

RFC 6797 — HTTP Strict Transport Security, policy processing and scope, checked 2026-10-15.
MDN: Strict-Transport-Security, directives and deployment cautions, checked 2026-10-15.
HSTS preload program, submission requirements and removal constraints, checked 2026-10-15.

Security headers should describe the actual page

Thu, 23 Jul 2026 00:00:00 +0000

Security headers are not a substitute for secure code, but they make the browser enforce useful boundaries. The policy should describe the page that is actually served, not a generic template copied from another project.

Treat headers as a deployment contract: match actual resources, distinguish enforced and report-only policy, and verify exact host scope and browser behavior.

Start from the resource graph

If a site serves HTML, a local stylesheet, a favicon, and no executable JavaScript, a narrow policy can be understandable:

Content-Security-Policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:

The script-src 'none' choice is only correct while the site does not require executable scripts. Adding search, comments, or an analytics tag changes the resource graph and should trigger a deliberate policy review.

Add transport and framing protections

For an HTTPS-only site, the following headers are common starting points:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()

Only enable HSTS with includeSubDomains when every subdomain is prepared to serve HTTPS. A header is a contract with future deployments, not merely a score in a scanner.

Check behavior, not just presence

Request a normal page, a missing page, and a static asset. Error responses should carry the same important security headers as successful responses. Also confirm that compression and caching do not change the content type or expose an internal path.

The Caddy example in this site is a starting point, not a universal policy. Adapt the host names, certificate handling, and application routes to your own deployment.

Deliver the CSP as a response header. frame-ancestors is ignored in a meta policy and does not inherit default-src; form-action also needs its own directive. style-src 'self' does not allow inline styles by itself, so test the generated theme, including dark mode. Keep data: in img-src only when the page actually needs data images.

Content-Security-Policy-Report-Only can reveal violations during a rollout, but does not enforce the policy; a reporting endpoint needs separate configuration. Verify enforcement in a real browser as well as checking headers. HSTS is learned from valid HTTPS responses; with includeSubDomains it also applies to descendants of the host that sets it: a policy on www.example.test does not cover the parent example.test or sibling api.example.test. Gradually increase the lifetime after checking that exact scope.

Sources

MDN: Content Security Policy guide, CSP directive names and syntax, checked 2026-07-23.
MDN: Strict-Transport-Security, HSTS directives and deployment cautions, checked 2026-07-23.
Caddy header directive, response header manipulation directives, checked 2026-07-23.
W3C Content Security Policy Level 3, response-header delivery, directive fallbacks, framing, and report-only policies; current working draft, checked 2026-10-15.
RFC 6797 — HTTP Strict Transport Security, valid HTTPS delivery and host/descendant matching in sections 8.1–8.3, checked 2026-10-15.

SSH host keys are part of the deployment record

Tue, 28 Jul 2026 00:00:00 +0000

In public-key authentication, a client proves possession of its private key; it does not tell the client which server it reached. The server’s host key and the local known_hosts database provide that second half of the identity check.

SSH server identity depends on comparing the observed host key with a separately trusted reference. Strict checking rejects unknown or changed keys. Trust on first use and a network key scan do not independently authenticate first contact.

Separate first contact from rotation

With StrictHostKeyChecking=yes, SSH refuses unknown hosts and changed keys. That is the safest default for a fixed production endpoint, provided the expected key is installed through a trusted channel. accept-new is a narrower convenience for a fleet where new hosts are expected: it accepts a never-seen key but still refuses a changed key.

Host production-site
HostName www.example.test
User deploy
IdentityFile ~/.ssh/site_ed25519
StrictHostKeyChecking yes
UserKnownHostsFile ~/.ssh/known_hosts

Do not “fix” a warning by adding StrictHostKeyChecking=no to a deployment script. It permits connections despite changed host keys, subject to client restrictions; warnings may still be printed, but the intended fail-closed identity check has been weakened. If a host is rebuilt, record the replacement fingerprint and review why the old key is no longer valid.

Make the fingerprint reviewable

Obtain the fingerprint from the host owner or console before the first connection, then compare it with what the client sees. A key change should have a ticket, maintenance note, or other explanation that another operator can inspect.

The same rule applies to automation: the known-hosts file is configuration with security consequences, not disposable cache data. Back it up with the deployment record, but do not publish private keys or copied credentials with the site artifact.

accept-new is trust on first use, not independent proof that the first server was genuine. ssh-keyscan can collect a candidate public key, but fetching it over the same untrusted network does not authenticate it. Compare its fingerprint with the separately trusted value before installing it.

Inspect the effective configuration without connecting, using a standalone copy of the example saved as deploy.conf:

ssh -G -F ./deploy.conf production-site | \
 grep -E '^(hostname|user|stricthostkeychecking|userknownhostsfile) '

Expect the configured host, user, known-hosts path, and strict checking (true or yes, depending on client output). This parses configuration only; it does not test an actual handshake. For a nonstandard port, known-hosts entries normally use [hostname]:port. Keep public-key fingerprints with the private operational release record, not the public website; hostnames can reveal internal topology even though host public keys are not secrets.

Sources

OpenBSD ssh_config, StrictHostKeyChecking and UserKnownHostsFile, checked 2026-07-28.
OpenSSH ssh-keygen manual, fingerprint inspection, checked 2026-07-28.
OpenSSH ssh-keyscan, unverified collected keys do not prevent man-in-the-middle attacks, checked 2026-10-15.
OpenSSH ssh, -G prints evaluated client configuration without opening a session, checked 2026-10-15.

Cookie scope should be narrower than the application boundary

Mon, 15 Jun 2026 00:00:00 +0000

Cookies are attached to requests according to browser rules, not according to the server component that originally set them. A broad Domain or Path can expose state to unrelated routes or subdomains, while missing transport and script restrictions enlarge the damage from other failures.

Review the dimensions together, but keep their roles separate: where cookies are sent, who can read them through JavaScript, and which stored identity a deletion targets.

When Domain is omitted, the cookie is scoped to the host that set it. Adding Domain=example.test allows it to be sent to eligible subdomains too. Use the broader form only when multiple hosts genuinely share the same application and trust boundary.

Inspect the response without printing real cookie values into logs. Header names are case-insensitive, so redaction must work for lowercase HTTP/2-style names too:

curl -sS -D - -o /dev/null https://app.example.test/login \
 | awk '
 tolower($0) ~ /^set-cookie:/ {
 sub(/^[^:]*:[^;]*/, "Set-Cookie: [value redacted]")
 print
 }
 '

Review the attributes together

Secure restricts cookie transmission to secure transport, normally HTTPS; it does not encrypt the stored value.
HttpOnly prevents JavaScript access through document.cookie; it does not stop the browser from sending the cookie.
SameSite influences cross-site requests and must match the application’s navigation or embedding needs.
Path controls when a cookie is sent, but it is not an authorization boundary between applications on the same host.

A cookie using SameSite=None also needs Secure in modern browsers. Avoid copying that pair into applications that do not require cross-site use.

Same-site is broader than same-origin: sibling HTTPS subdomains can be same-site while remaining different origins. SameSite therefore cannot replace the host boundary or the application’s CSRF defenses. Cookies are also not isolated by port, even with the __Host- prefix.

Use prefixes when their constraints fit

Cookie name prefixes such as __Secure- and __Host- let supporting browsers enforce additional requirements. A __Host- cookie must use Secure, omit Domain, and use Path=/, which makes the host-only intention explicit.

Test deletion with the same scope

Delete the same cookie name and domain/path scope using Max-Age=0 or a past Expires value; not every attribute is part of its storage identity. Meet the prefix and secure-origin requirements when sending the deletion. Preserve whether Domain was omitted: expire a host-only cookie without adding Domain, and specify its original Path. The current 6265bis draft includes the host-only flag in storage identity, so matching only the displayed domain string is insufficient as a portable deletion recipe. Verify deletion in the target browsers. A logout that clears only one scope can leave another active, and server-side sessions or tokens may also need invalidation.

A genuinely static documentation site normally has no reason to set application cookies. Check representative public responses for Set-Cookie and inspect browser storage after navigation, including any third-party scripts. A curl header check alone cannot detect JavaScript-set cookies or other browser storage; avoid adding storage the site does not need.

Sources

RFC 6265 — HTTP State Management Mechanism, cookie storage and scope, checked 2026-10-15.
MDN: Set-Cookie, attributes and cookie prefixes, checked 2026-10-15.
HTTPWG cookie specification draft, SameSite and cookie-prefix requirements, checked 2026-10-15.

CAA records should authorize the issuer you actually use

Wed, 17 Jun 2026 00:00:00 +0000

Certification Authority Authorization records let a domain holder state which certificate authorities may issue certificates for the domain. They are useful only when the record matches the real renewal path and the operator understands how policy can be inherited from parent names.

CAA authorizes issuers at issuance time. Lookup stops at the first relevant nonempty record set; wildcard tags refine the rule. Existing certificates and HTTPS trust are separate boundaries. The displayed issuer is an example.

Inspect the current policy

Query the exact hostname and its parent names:

for name in www.example.test example.test test; do
 printf '== %s\n' "$name"
 dig +noall +answer CAA "$name"
done

These are placeholder names, queried through the configured resolver. An empty answer at the leaf does not necessarily mean there is no applicable policy: lookup follows aliases and stops at the first nonempty relevant CAA RRset while walking upward. It does not merge every parent’s restrictions. Inspect DNS status and authority information too; an empty answer-only display can hide NXDOMAIN or SERVFAIL. Compare authoritative answers with recursive results when diagnosing changes.

Match the CA’s issuer identifier

A record uses tags such as issue or issuewild and an issuer-domain value:

example.test. 3600 IN CAA 0 issue "letsencrypt.org"

The value is an authorization identifier, not the display name from a certificate. Confirm it in the certificate authority’s current documentation. Without issuewild, issue also governs wildcard issuance. When issuewild is present, it takes precedence for wildcard requests; multiple records of the same tag grant alternatives rather than requiring every CA. CAA does not select a particular intermediate certificate.

Stage the DNS change before renewal

Add or tighten CAA while the current certificate is healthy. Wait through the previous TTL, query authoritative and recursive answers, and run a staging or renewal test supported by the ACME client. Keep a rollback record ready.

Do not add a restrictive record during an expiry incident unless the issuer path has already been verified. A syntactically correct but wrong policy can turn automatic renewal into a hard failure.

Observe issuance failures

CAA checks happen at issuance time, not on every HTTPS request. Changing CAA neither revokes existing certificates nor proves that a historical issuance complied with the policy at that time. Certificate monitoring must therefore cover both current expiry and renewal attempts. Log the effective DNS answer with the ACME failure instead of recording only a generic authorization error.

Sources

RFC 8659 — DNS Certification Authority Authorization, CAA lookup and property semantics, checked 2026-10-15.
Let’s Encrypt: CAA, issuer identifiers and operational guidance, checked 2026-10-15.

A certificate chain is a path you should be able to print

Mon, 08 Jun 2026 00:00:00 +0000

A TLS client must build a valid certificate path to an anchor it already trusts, and verify the requested hostname. Printing certificates is a useful diagnostic, but does not establish either result by itself.

The server supplies certificates; trust comes from the client’s anchor. Validate the path, requested hostname and validity period. Printed certificate counts cannot establish those results.

The leaf is not the whole story

The endpoint presents the leaf first. It contains the public key, validity period, and subject alternative names used for hostname checks. A public-CA deployment normally also sends the intermediates needed to build a path. Missing intermediates can break clients that do not already have them cached or cannot retrieve them.

The self-signed root normally need not be sent: trust comes from the client’s configured anchors, not from a server including a certificate. A cross-signed certificate whose subject says “Root” can instead be an intermediate in the selected path. Certificate count alone is therefore not a completeness or trust test.

Read the chain the edge actually sends

OpenSSL documents s_client -showcerts as the server’s certificate list, not a verified chain. The earlier version of this note recorded this site snapshot:

certificate 0: CN=www.xbcatm.com
 issuer : C=US, O=Let's Encrypt, CN=YE1
 notAfter : Nov 19 08:37:12 2026 GMT

certificate 1: CN=YE1 (intermediate)
 issuer : C=US, O=ISRG, CN=Root YE

certificate 2/3: Root YE / ISRG Root … (CA certificates)

The original report counted four blocks. Its raw handshake log is not retained here, and this review did not reproduce the live handshake; treat the values as a historical report, not current edge evidence. Let’s Encrypt’s chain documentation does describe YE1 and a cross-signed Root YE path, so those names alone are not evidence of an invalid chain. Which certificate terminates trust depends on the client’s trust store and path building.

Keep issuance authorization separate

Intermediates let a CA keep its root key offline and separate issuance operations. Revoking an intermediate can invalidate dependent leaf paths and may require replacement certificates; it does not preserve every leaf automatically.

CAA authorizes a CA’s documented issuer-domain identifier at issuance time. It does not pin an intermediate, change browser trust, or prove that an existing certificate complied with historical CAA. The dns-caa-records note covers that separate policy check.

Count for inventory, validate for trust

The earlier inventory command was:

$ echo | openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com -showcerts 2>/dev/null | grep 'BEGIN CERT' | wc -l
4

This is read-only network traffic, but it suppresses diagnostics and the final count can succeed even when an earlier command failed. Do not use 4, or any other fixed count, as a health threshold. A leaf-only result warrants checking the expected issuer path rather than declaring every one-certificate chain invalid.

For actual validation, configure hostname checking and failure on verification errors with OpenSSL’s -verify_hostname and -verify_return_error options, retain diagnostics, and record the trust store and client version. Also test the clients you support; one OpenSSL trust store cannot establish compatibility with all browsers.

Sources

RFC 8446 — TLS 1.3, section 4.4.2 certificate-list order and optional trust-anchor omission, checked 2026-10-15.
RFC 5280 — X.509 PKI, section 6 trust-anchor input and path validation, checked 2026-10-15.
Let’s Encrypt FAQ, certificate compatibility overview, checked 2026-10-15.
Let’s Encrypt: Chains of Trust, YE1 and cross-signed Root YE paths, checked 2026-10-15.
OpenSSL s_client, presented-list and verification options, checked 2026-10-15.
RFC 8659 — CAA, issuance authorization rather than client trust, checked 2026-10-15.

Audit the trust of a public edge

Thu, 06 Aug 2026 00:00:00 +0000

The web-security series treats settings as contracts with scope and failure modes. This walkthrough inspects a host you are authorized to query. The HTTP, TLS, and DNS requests are read-only observations, although they still generate logs and traffic. SSH checks read your own trust record; the deployment host may differ from the website hostname.

Use a disposable local working directory for captured output. No output shown here is a fresh measurement of www.xbcatm.com, and a passing command proves only the property it actually checks.

Each observation supports a bounded claim. Header presence, certificate dates and local records cannot combine into a whole-service safety badge.

1. Start with the policy the edge advertises

Fetch a GET response without silently following redirects, then inspect its status and headers:

host=www.xbcatm.com
url="https://$host/"
curl -sS --max-time 20 -D headers.txt -o body.html "$url"
cat headers.txt

The repository’s intended policy includes the following illustrative fields:

Content-Security-Policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

script-src 'none' is a strict choice for this script-free site, not a universal recipe for every static site. The browser enforces CSP; a report-only header does not block execution. Read the complete policy for more-specific script directives, and compare normal pages and error routes. nosniff constrains MIME handling, notably script/style destinations, but does not certify the body’s media type.

HSTS is learned from valid HTTPS responses and applies to the host that sent it. A policy received from www.example.com with includeSubDomains covers descendants of that name, not its sibling api.example.com or parent example.com. Inventory the actual scope before adopting a long duration. A proxy adding or stripping headers changes the browser contract, which is why artifact checks and edge checks are separate.

2. Verify TLS identity before reading certificate dates

SNI selects the intended virtual host; it does not verify the certificate name. Make verification failure fatal and explicitly request hostname validation. Use an up-to-date trust store appropriate to the clients under test.

openssl s_client -connect "$host:443" -servername "$host" \
 -verify_hostname "$host" -verify_return_error -showcerts \
 </dev/null > tls.txt 2> tls.log
# Continue only if the command succeeded; preserve tls.log on failure.
openssl x509 -in tls.txt -noout -subject -issuer -dates -ext subjectAltName

Run these as separate checked steps, or under a shell setup that stops on failure. Hiding stderr or piping into a successful x509 command can conceal an unsuccessful handshake. Inspect the DNS names in subjectAltName; the displayed subject CN is not sufficient for modern service-identity validation. Some library versions retain legacy CN fallback, so explicitly check that the expected SAN is present. A valid matching wildcard may be legitimate; an unrelated certificate is not.

notAfter gives the expiry time. It does not prove the chain is trusted, the hostname matches, or revocation was checked. Record the date and the measured safety window rather than relying on memory. OpenSSL’s result describes its configured trust store and checks, not every browser’s behavior.

3. Read the presented chain without inventing a fixed count

The -showcerts output contains certificates sent by the server, not a declaration that they form a verified chain. This command displays their count only:

grep -c 'BEGIN CERTIFICATE' tls.txt

There is no required count of four. The server normally supplies the leaf and necessary intermediate certificates; a root usually belongs in the client’s trust store and need not be sent. Chain length varies with the CA and chosen path. One certificate warrants investigating whether intermediates are needed, but a count alone is neither success nor failure.

Use the actual verification result from step 2, then investigate issuer/SAN changes, missing intermediates, expiry, and trust-store differences. An intermediate rotation can be normal CA maintenance. A numerically unchanged chain can still be wrong, and the count command does not automatically compare anything with an expected value.

4. Revalidate the captured representation

Caching is a separate contract, not evidence of TLS identity. Capture a current ETag and use it on a request selecting the same representation, as in the HTTP walkthrough. A matching conditional GET can return 304; a deployment between requests can legitimately produce 200. An old hardcoded validator is not a reusable test fixture for a changing site.

A no-script policy does not mean CSP never changes. Security headers can change independently of HTML, and a body ETag does not fingerprint every response header. Record the actual policy again after release.

5. Find the relevant CAA policy

CAA constrains issuance by compliant certificate authorities. It is not certificate pinning and does not retroactively invalidate an already issued certificate. Start by inspecting the queried name and its ancestors; retain response status so a DNS failure is not mistaken for an empty answer.

dig www.xbcatm.com CAA +noall +comments +answer
dig xbcatm.com CAA +noall +comments +answer

An empty answer at www does not mean issuance is unrestricted. RFC 8659 searches upward until the first relevant nonempty CAA set, following aliases during each lookup; continue through applicable ancestors if necessary. Inspect issue, and issuewild when wildcard issuance is involved. An iodef report address alone does not restrict issuance. If no restricting policy applies, CAA adds no issuer restriction, but normal domain validation and CA rules still apply.

Compare the CA’s documented CAA identifier with the relevant policy, not merely the leaf’s human-readable issuer CN. Today’s CAA result is evidence about today’s DNS policy, not proof of what existed when the certificate was issued.

6. Check the deployment host’s recorded SSH identity

Use the actual SSH destination, including the bracketed host/port form for a non-default port. ssh-keygen -F can find hashed known-host entries that a text grep of the hostname misses.

deploy_host=deploy.example.test
ssh-keygen -F "$deploy_host" -f "$HOME/.ssh/known_hosts" > host-record.txt
ssh-keygen -lf host-record.txt

Compare the fingerprint with an independently trusted record, such as the provider console or a verified administrator channel. This reads the local record; it does not prove which key the remote host presents now. A network key scan alone would not authenticate that key either. Investigate a changed key before updating trust; a rebuild is one possible explanation, not automatic permission to accept it.

Inspect all Set-Cookie fields in the captured response and any relevant redirect or application route. No cookie on one page does not establish that the entire site never sets cookies. A host-only cookie omits Domain; adding a parent Domain broadens the hosts receiving it. Path controls delivery but is not a security boundary against same-origin code.

Secure restricts transport, HttpOnly blocks script access to the cookie, and SameSite controls specified cross-site sending behavior. They address different risks and do not replace one another; SameSite=None requires Secure in modern browsers. For this site’s no-account content model, ask why a cookie is needed at all before broadening its scope. Redact cookie values from shared audit records.

Keep a bounded audit record

Record the UTC time, client versions, requested/final URL, status, enforcing headers, TLS verification result and dates, relevant CAA lookup, and SSH record source. Distinguish observed success, unexpected results, and checks not performed. These several observations take more than “two commands” and cannot prove the whole service secure.

Repeat the relevant checks after certificate, DNS, proxy, or deployment changes. Preserve prior results to identify drift, and test actual browser behavior separately when the claim depends on browser enforcement.

Sources

WHATWG Fetch Standard, nosniff processing and request destinations, checked 2026-10-15.
OpenSSL s_client, SNI, hostname verification, fatal verification errors, and presented chains, checked 2026-10-15.
RFC 9525: Service Identity in TLS, SAN-based service identity and wildcard matching, checked 2026-10-15.
RFC 8659: CAA, relevant record-set search and issuance policy, checked 2026-10-15.
RFC 6797: HSTS, host scope and policy processing, checked 2026-10-15.
OpenSSH ssh-keygen, known-host lookup and fingerprint display, checked 2026-10-15.
W3C: CSP Level 3, enforcing versus report-only policy and script directive fallback (working draft), checked 2026-10-15.
MDN: Set-Cookie, cookie attributes and their limits, checked 2026-10-15.

Web security · XB Field Notes

Certificate expiry is a date, not a dashboard color

Include the hostname

Alert on a threshold

Separate observation from verification

Sources

HSTS should be rolled out with a recovery plan

Verify the HTTPS path first

Start with a short max-age

Treat includeSubDomains as a separate decision

Preload is not ordinary header configuration

Verify the public response

Know what rollback can clear

Sources

Security headers should describe the actual page

Start from the resource graph

Add transport and framing protections

Check behavior, not just presence

Sources

SSH host keys are part of the deployment record

Separate first contact from rotation

Make the fingerprint reviewable

Sources

Cookie scope should be narrower than the application boundary

Prefer a host-only cookie

Review the attributes together

Use prefixes when their constraints fit

Test deletion with the same scope

Keep static sites cookie-free

Sources

CAA records should authorize the issuer you actually use

Inspect the current policy

Match the CA’s issuer identifier

Stage the DNS change before renewal

Observe issuance failures

Sources

A certificate chain is a path you should be able to print

The leaf is not the whole story

Read the chain the edge actually sends

Keep issuance authorization separate

Count for inventory, validate for trust

Sources

Audit the trust of a public edge

1. Start with the policy the edge advertises

2. Verify TLS identity before reading certificate dates

3. Read the presented chain without inventing a fixed count

4. Revalidate the captured representation

5. Find the relevant CAA policy

6. Check the deployment host’s recorded SSH identity

7. Keep cookie scope no broader than necessary

Keep a bounded audit record

Sources