Security

Keeping the token on the server and giving the browser only a short-lived code shrinks the surface for token theft in the URL or the log. The browser gets a code, not a token The browser is deliberately the wrong place for the access token. In the authorization-code flow the browser goes to the authorization server, sees the consent screen, and comes back at the redirect URI carrying only a short authorization code, never the token. The token stays off the browser’s URL history and out of its logs, because it is the backend that presents the code together with the client secret to the token endpoint. That split of labour — the browser carries the code, the server owns the secret — is the entire point of the flow. ...

An HTTP/1.1 request does not describe where it ends. Its boundary is computed — from Content-Length or the chunked coding — and every hop computes it independently. Request smuggling is what happens when two hops compute different answers from the same bytes. ...

Treat the payload as public, rely on the signature for authenticity, and always reject tokens whose exp is past to keep a replayed token from living too long. Encoded, not encrypted A JWT is not protected by secrecy; it is three base64url pieces, the header and claims in clear text plus the signature, joined by dots for compactness. Anyone holding the token can decode it and read every claim in plaintext. That is correct by design, and it has a sharp consequence for what you put inside: no secrets, no server credentials, no session material that belongs only to the server. If a value must be readable only by the server, do not embed it, look it up by a jti claim instead. Encoding is a transport step, not confidentiality. ...

Parameter binding gives a database value a designated position in a SQL statement. A name containing a quote or a semicolon remains a value instead of becoming another clause. Reusing a named prepared statement adds a separate optimization: the server can retain statement information across executions in one session. Safe binding does not require the application to create a named statement for every query. ...

A setuid binary runs with the identity of its owner rather than of whoever started it. The kernel swaps credentials at exec time, which is how passwd rewrites /etc/shadow without an ordinary user holding write permission on it. The bit belongs to the file, and it grants the owner’s entire identity, not one narrow ability. ...

/tmp is a shared namespace of names, not a private scratch area. Any local user can create the name your process is about to use, so a name is not a claim on a file, and hier(7) says the contents may be deleted with no notice. ...

Clickjacking deceives a user about which interface receives an action. A hostile parent can place a framed application behind a misleading visual layer so that a click reaches a real control in that application. The parent need not read the child’s DOM for the user to interact with it. Same-origin read restrictions therefore do not replace a decision about whether the application may be embedded at all. ...

XML external entity processing can read local files or reach hosts the attacker cannot, all inside a message the server parses. Configure the parser to deny it. Entities are a parser feature XML entities are a parser feature that lets a document refer to other content, and the same mechanism is what turns a small request into an expansion bomb if left unguarded. A document can define an entity that points at a local file, a network URL, or another entity, and when the parser resolves it, it reads the target and inserts its content into the document structure. That convenience is also the blast radius: a parser that is allowed to follow such references will happily read /etc/passwd over the wire, or loop forever expanding nested entities. ...