Security

You do not choose a hash for the database; you choose it for the attacker who reads the database. Dedicated password hashes trade speed for resilience to increase the cost of offline guessing after a leak. Fast is the wrong goal Speed is the enemy here. General-purpose hashes such as SHA-256 are intentionally fast, allowing offline attackers to test guesses efficiently; actual rates depend on algorithm and hardware. Purpose-built password algorithms (bcrypt, scrypt, Argon2id) add a tunable cost factor plus per-user salt, so guesses require deliberate work and independently salted accounts have different stored values even with a shared password. The added per-guess work is the feature; its benefit still depends on the selected parameters and password strength. Choose an algorithm that is memory-hard where feasible, and pick a cost that stays high yet tolerable on the hardware that has to verify every login. ...

A parameterized query sends the database instruction and its values through distinct API arguments. The database interprets the instruction as SQL and uses each parameter where a value belongs. This boundary works in embedded engines such as SQLite as well as client-server databases; it does not depend on a network exchange or on an application explicitly managing named server statements. ...

A request-body limit bounds accepted input, not merely the number written in Content-Length. Enforce it while consuming the body, before committing application effects. Compressed input needs separate limits for encoded and decoded bytes. A 413 response is useful only if the expensive allocation or irreversible write has not already happened. ...

A server’s bind address selects which local destination addresses its socket can accept. Binding an IPv4 listener to 127.0.0.1 differs from binding it to 0.0.0.0, the wildcard address. Neither setting alone describes the complete access policy. Routing, network namespaces, packet filtering, port publication, proxies, and application authentication determine how a request reaches the listener and what it may do afterward. ...

The HTTP Referer request header can tell a destination which page initiated a request. Its historical spelling differs from Referrer-Policy, the policy that controls how much source information the browser supplies. Depending on that policy and the destination, the value may include the source path and query, contain only the source origin, or be omitted. Sending the full URL to every external destination is not the modern default. ...

An SSH agent provides signing operations for public-key authentication. For ordinary software keys, loading an encrypted private key unlocks material that the agent can then use without asking for the file passphrase on every connection. Clients receive public identities and signatures, not an exported private key through the normal agent protocol. Hardware-backed identities are different: the authenticator can retain the private key and require touch or verification. ...

HTTP Basic authentication places an encoded username and password in an Authorization header. The encoding is reversible, so possession of that header can be equivalent to possession of the credential. Basic defines a challenge-response exchange, but it does not cryptographically bind a response to a fresh server nonce. A captured accepted value can be replayed while the server continues to accept that account and credential. ...

CORS preflight asks whether a browser may send a particular cross-origin request shape. It is an OPTIONS request containing the proposed method and relevant request-header names. The browser checks the server’s response before sending the actual request. This mechanism is distinct from checking whether application JavaScript may read an actual response that has already arrived. Both stages can fail, but their effects on server-side execution differ. ...