Web-Security · XB Field Notes

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.

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.

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.

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.

Content-Type should describe the bytes you actually send

Thu, 11 Jun 2026 00:00:00 +0000

A static server can return the correct bytes with the wrong Content-Type. The page may still look acceptable in one browser, while a download, stylesheet, feed reader, or security policy treats the same response differently. The public response header is the contract; the filename is only an input to server configuration.

A suffix cannot prove what arrived. Read the public response status, bytes, and media type together; an HTML error page at a CSS path is not a mapping test. Nosniff makes script and style type mismatches visible.

Inspect representative formats

Check one HTML document, stylesheet, SVG, feed, and downloadable script. Include headers but discard the body:

for path in / /assets/site.css /favicon.svg /index.xml /downloads/check-http-headers.sh; do
 curl -sS -D - -o /dev/null "https://www.example.test$path" \
 | awk -v path="$path" '
 BEGIN { print "== " path }
 /^HTTP\// || tolower($1) == "content-type:" || tolower($1) == "x-content-type-options:" { print }
 '
done

Replace the example asset paths with files that actually exist in the release; an HTML 404 response at an invented CSS path is not a MIME-mapping test. Expected media types depend on the resource, but they should be specific and stable. HTML should normally include a character set. CSS and SVG should not be served as generic binary data. A shell helper offered for download should not be advertised as HTML.

This loop displays headers; it does not assert success, inspect the discarded bytes, or exercise browser blocking. Confirm the resource against the release artifact and inspect an actual browser load as a stylesheet or script. Opening the same URL as a document tests a different request destination.

Keep nosniff consistent

X-Content-Type-Options: nosniff asks supporting browsers to respect the declared type for script and style destinations instead of guessing. For that Fetch check, a script-like destination needs a JavaScript MIME type, and a style destination needs text/css; a missing or unusable type also fails. This turns a mismatch into an observable failure rather than browser-dependent interpretation.

The header does not repair a wrong type or make arbitrary content safe. Check the inventory while deploying it, and fix any rejected script/style response rather than removing the protection:

X-Content-Type-Options: nosniff

Check the server mapping

Static servers usually derive types from extensions. If a new extension is served as application/octet-stream, decide whether that is intentional before adding a global override. A narrow mapping is easier to review than a rule that changes every response.

Repeat the checks at the public hostname. A CDN or reverse proxy can replace a correct origin header, and a friendly error page can return HTML for a path whose suffix looks like CSS or JavaScript.

Sources

RFC 9110 — HTTP Semantics, representation metadata and Content-Type, checked 2026-10-15.
MDN: Content-Type, media types and charset examples, checked 2026-10-15.
MDN: X-Content-Type-Options, nosniff behavior, checked 2026-10-15.
WHATWG Fetch Standard, script-like and style destination blocking, checked 2026-10-15.

Web-Security · XB Field Notes

Security headers should describe the actual page

Start from the resource graph

Add transport and framing protections

Check behavior, not just presence

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

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

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

Content-Type should describe the bytes you actually send

Inspect representative formats

Keep nosniff consistent

Check the server mapping

Sources