HTTP Strict Transport Security tells a supporting client to use HTTPS for a remembered hostname. It can eliminate the insecure HTTP request before a redirect, but only when the client already knows the policy, through an earlier authenticated response or a supported preload mechanism. Merely adding a header cannot retroactively protect an unknown client’s first HTTP visit. ...
Security response headers ask a supporting browser to enforce specific rules. Their value comes from the behavior those rules change, not from the length of a header checklist. A static site still has document loading, scripts or styles, embedding, navigation, and transport boundaries to consider. Select policies that match the actual page and delivery path, then verify both intended restrictions and legitimate functionality. ...
A credential expires only when the system deciding access checks an applicable deadline. Writing an expiry date in an inventory does not change what a database or API accepts. A short lifetime can reduce the period during which a stolen credential starts new access, but its effect depends on the authentication mechanism and on what happens to sessions or other credentials already created with it. ...
A TLS version policy defines which handshakes an endpoint accepts. Prefer an explicit minimum over assuming that a library’s changing defaults match your requirements. A maximum is a separate constraint: freezing it unnecessarily can prevent adoption of a newer supported protocol. Neither setting replaces certificate verification, suitable algorithms, or timely security updates. ...
A credential committed to Git becomes part of a versioned object graph that collaborators and automation may copy. Removing the file from the latest tree does not remove the earlier commit containing it. The practical boundary is to keep credential values out of source history and provide them through an authorized runtime mechanism. Repository configuration can describe how to obtain a secret without containing the secret itself. ...
Cross-Origin Resource Sharing lets a server opt into exposing a response to scripts from another origin. An origin consists of scheme, host, and port; two services on different ports can therefore be cross-origin even on the same machine. The browser evaluates the CORS response headers for the requesting page. This mechanism does not authenticate that page’s user or turn the endpoint into a private network service. Same-site cookie rules use a different boundary from same-origin response access, so similar-looking hostnames are insufficient to reason about both. ...
Content Security Policy tells a supporting browser which actions a document permits. Fetch directives govern categories such as scripts, styles, and images; other directives cover different boundaries. The policy is supplied with the document, commonly through a response header. It adds constraints to browser behavior, but does not repair an injection bug, authenticate application users, or promise that every possible form of script execution has been eliminated. ...
An explicit script-src ’none’ policy is a boundary with a measurable contract.