Application security & secure coding

A command string is parsed by a shell, so user bytes can become syntax. An argument list is handed to the process-creation call as an array — no parsing step exists, so a value containing ; rm -rf / is just an odd argument. You lose pipes, redirection and globbing, and must do them yourself.

A denylist enumerates the attacker's moves — an open-ended, growing set — and fails open on anything unforeseen. An allowlist enumerates the application's own domain — finite and known — and fails closed. The difference is open-world versus closed-world, not optimism versus pessimism.

The check itself does the overflowing arithmetic: if offset + length wraps, the sum becomes small and the guard passes for values that are far out of range. Rewrite it so nothing can wrap — compare by subtraction against the known limit, or use a checked-addition operation that fails on overflow.

It separates the credential from the artifact, so one build runs in many environments and the value is not in version control. It does not encrypt anything, does not narrow who on the host can read it, and it is read once at start — so rotation needs a restart.

A memory copy lives milliseconds behind a process boundary; a log line lives for years, replicated, indexed, shipped to third parties and readable by many people. Secrets arrive there through automatic serialisation, exception messages and URLs — not through deliberate logging.

An awareness document: ten broad risk categories, each rolling up many underlying weakness types, ranked mainly by how often they appear in tested applications weighted by exploitability and impact. It is shared vocabulary and a coverage prompt, not a verification standard or a sufficient requirements list.

The server becomes a confused deputy: it makes a request an attacker chose, but with the server's network position and credentials. Blocking bad addresses is an open-world deny-list — redirects, DNS re-resolution and address encodings keep producing new bypasses — while an enumerated allow-list of destinations is closed and finite.

An implementation flaw is a control that exists but is written wrong; a design flaw is a control that was never specified, so there is no correct code to write. Design flaws survive perfect code, perfect libraries and clean scans — they are fixed by changing requirements or the flow, not by patching a line.

Testing needs an oracle: a way to judge wrongness from the observation alone. Injection and vulnerable components have one. An authenticated 200 carrying someone else's record does not — ownership is a domain fact absent from the artefact under test.

Rank by your own risk: reachability of the sink, privilege of the executing principal, sensitivity of the data reached, and the cost of the durable fix. The list's ranking is an industry incidence statistic collected from other people's applications, so it says nothing about which of your findings an attacker can actually reach.

Authentication establishes who the principal is, from evidence, with some level of confidence. Authorization decides whether that principal may perform this action on this resource, in this context. Conflating them produces 'logged in, therefore allowed' - the most common access-control bug.

Frameworks give you endpoint-level checks for free, but per-record checks need domain knowledge, so they get omitted. The rule: every request re-derives permission from server-owned state - the request says which object, never whether it is allowed. Unguessable identifiers are obscurity; identifiers leak, and then there is no check at all.

A component with more authority than its caller performs an action the caller chose, using its own ambient authority instead of the caller's. The structural fix is to carry authority with the request - a scoped, audience-bound credential representing the original principal - rather than attaching it to the deputy's identity.

A credential is either a reference to the issuer's state or a self-contained assertion the verifier evaluates alone. An assertion is a frozen authorization decision from issuance time. Both are bearer credentials — possession is authority — unless bound to a key.

Roles are a closed, auditable set but explode when decisions depend on data. Attribute policies are expressive but make 'who can see this' hard to answer. Relationship models express sharing and inheritance naturally at the cost of consistency. Real systems combine: roles for coarse operations, relationships for object-level, attributes as conditions.

A linked key pair: the public key only encrypts and may be published, the private key alone decrypts. It removes the need for a pre-shared secret, so it solves key distribution, not strength. A ciphertext still proves nothing about who produced it.

ECB encrypts each block independently with no randomization, so identical plaintext blocks give identical ciphertext blocks — it leaks structure, repetition and equality, and blocks can be reordered or spliced. Any usable mode must be randomized: same plaintext, different ciphertext each time.

Signing runs the message and a private key through a signing algorithm to produce a value anyone can check with the matching public key. It gives integrity and origin authenticity. A shared-key MAC gives both too, but not non-repudiation: either key holder could have produced the tag.

Hashing is unkeyed and deterministic, so a hashed identifier is a stable pseudonym, not anonymous data: it still singles out people and joins across datasets, and small identifier spaces enumerate. Encryption is keyed and reversible; encoding is neither and protects nothing.

Passwords are low-entropy, so nobody inverts the hash — they guess candidates and hash them. A general-purpose hash is designed to be fast, so an attacker tests billions of guesses per second. A password function must be deliberately slow and hardware-hostile, with a per-user salt and a tunable cost.