A cookie is a browser storage and transport mechanism. A server-side session is one application design that uses a cookie value to locate stored state. Keeping those responsibilities separate makes login, expiry, and logout testable. This article follows an opaque session identifier, rather than repeating the host, path, or SameSite matching rules. ...
A read-only root filesystem prevents ordinary writes to the filesystem layer containing a service’s packaged code and configuration. Explicit mounts can still provide writable locations for runtime data. Its boundary is filesystem mutation. It does not by itself remove process privileges, prevent reading available data, or block communication with other services. ...
Single sign-on lets an application rely on an identity provider’s authentication result. The user does not need to hand that provider password to each application. The application still owns its authorization decisions, local sessions, and integration configuration; confidential clients may also hold client credentials. Delegating authentication does not remove the application’s security boundary or guarantee that every future login can skip user interaction. ...
HTTPS protects a connection and authenticates its peer according to the client’s trust policy. It does not certify the site’s intentions, correctness, or availability. A security indicator is therefore neither just an encryption label nor a complete health report. A useful check separately evaluates the TLS connection, the HTTP response, and the service’s expected behavior. ...
Server Name Indication gives a TLS server a hostname while it is choosing handshake parameters and a certificate. In the certificate-based, no-early-data path discussed here, this happens before ordinary HTTP bytes, not before any bytes cross the network. SNI is a selection hint; the client must still verify the selected identity. ...
A reusable bearer access token grants its holder defined access; sender-constrained tokens additionally require proof tied to the sender. Putting it in a URL exposes that capability to systems that routinely copy URLs: access logs, monitoring records, browser navigation history, bookmarks, and shared links. The exact exposure depends on the request and policy, but a secret-looking query parameter is not automatically protected by its name. Treat transport placement as part of the credential’s disclosure boundary. ...
A cookie’s host and path scope controls which destinations are eligible to receive its name and value. It is useful to minimize that set, but scope is not authorization, and cookies do not follow the browser’s full origin boundary. This article concentrates on Domain and Path; transport and request context add separate restrictions. ...
DNSSEC adds origin authentication and integrity checking for DNS data. RRSIG records sign RRsets, DNSKEY records publish verification keys, and a parent’s DS record identifies a child DNSKEY through a digest. The parent signs its DS RRset; it does not simply sign the child’s public key directly. Validation follows these relationships from a configured trust anchor to the requested data. ...