Security · XB Field Notes

Forwarding an SSH agent

Wed, 09 Feb 2028 00:00:00 +0000

Agent forwarding is not the agent itself. A local agent can answer authentication requests without sending the private key to the server. Forwarding additionally makes that service reachable through a socket on a remote host. Keeping key material local therefore does not mean keeping its authentication capability local.

That distinction matters when choosing a route through a bastion. If the task is simply to log into a private machine, use ProxyJump with forwarding disabled. Forwarding is useful when a program actually running on the remote machine needs your agent, such as a deliberately authorized second SSH connection.

The remote gets a capability

The forwarded socket is normally exposed through SSH_AUTH_SOCK. Processes with access to it, including a sufficiently privileged attacker on that host, can request operations from the originating agent. This is not permission for every unrelated account on the machine, and it is not an export of the private key.

An unconstrained loaded identity can nevertheless authorize unwanted logins while the forwarding channel remains available. Key lifetime, confirmation requirements, destination restrictions, and server authorization all affect what succeeds. Calling this unrestricted ownership of the key overstates the mechanism, but understating socket access is just as dangerous.

An earlier version cited an unexplained 88-byte signature as evidence. Signature length alone establishes neither the OpenSSH agent protocol nor a forwarded authentication exchange. The exercise below instead tests a narrow, observable property with the actual client: its effective forwarding configuration.

Forwarding follows effective configuration

Omitting -A does not turn forwarding off. A matching Host block, an included configuration file, or system configuration can already enable it. Conversely, -A explicitly enables forwarding even when a configuration file says ForwardAgent no. Use -a or an unambiguous -o ForwardAgent=no when disabling it for a connection.

ProxyJump supplies a TCP route to the destination; it does not reset the destination’s forwarding option. The target SSH connection and its authentication still originate locally, so ordinary jump access needs no forwarded agent. Inspect settings for the destination and jump hosts separately, because their configuration is not necessarily identical.

On a remote shell, a subsequent SSH client evaluates its own configuration. Count effective settings, not appearances of -A in command history. Also check connection multiplexing when diagnosing an existing session: printing configuration describes a proposed invocation, not every property of a previously established connection.

Limit the delegation

ssh-add -c requests confirmation through an askpass program; absence of a terminal alone does not explain whether approval works. ssh-add -t limits an identity’s lifetime. Destination constraints, available since OpenSSH 8.9, use known host keys and require cooperating client and server support along forwarded paths. Every cooperating hop must be allowed. A hostile hop can relay the socket again using other tools, while signing remains restricted to permitted destinations.

Server-side AllowAgentForwarding no disables OpenSSH’s built-in facility. It does not prevent a user with unrestricted shell access from arranging another forwarder. Keep that restriction, but do not mistake it for isolation from a hostile shell user.

When it breaks

A compromised bastion can misuse an accessible forwarded agent while the channel and relevant identity remain usable. Replacing the private-key file on disk does not unload the agent’s old identity. Respond by ending the forwarding connection and removing the affected loaded identity; revoke the corresponding server authorization if compromise warrants it. Already established remote sessions need separate handling.

Another failure is enabling forwarding in Host * and forgetting it. Prefer narrow host exceptions and an agent containing only the needed identities. Selecting IdentityFile for one login is not a filter over everything a forwarded agent exposes.

ProxyJump supplies a route; forwarding exposes signing capability. Effective configuration and cooperating destination restrictions need separate checks.

Check it quickly

This disposable configuration prints four settings for manual comparison; it opens no network connection or private key. It has no value assertions or failure/cleanup trap:

f=$(mktemp)
printf 'Host *\n ForwardAgent no\n' > "$f"
ssh -G -F "$f" target.invalid | grep '^forwardagent '
ssh -G -F "$f" -A target.invalid | grep '^forwardagent '
printf 'Host *\n ForwardAgent yes\n' > "$f"
ssh -G -F "$f" -J bastion.invalid target.invalid | grep '^forwardagent '
ssh -G -F "$f" -a -J bastion.invalid target.invalid | grep '^forwardagent '
rm "$f"

The retained OpenSSH 10.0p2 record reports no, yes, yes, no; this review did not rerun it. This verifies option handling, not socket permissions, signing, destination constraints, or a live multi-hop connection. For a trusted real configuration, inspect ssh -G destination and jump-host aliases; evaluating Match exec can run local commands and hostname canonicalization can invoke DNS. A forwarding value of yes should have a specific reason and a trusted recipient.

Sources

OpenBSD: ssh, command-line forwarding controls, jump connections, and configuration inspection, checked 2026-10-15.
OpenBSD: ssh_config, ForwardAgent, ProxyJump, and configuration precedence, checked 2026-10-15.
OpenBSD: ssh-agent, agent sockets and authentication without transferring private keys, checked 2026-10-15.
OpenBSD: ssh-add, askpass confirmation, lifetimes, and destination-constraint requirements, checked 2026-10-15.
OpenBSD: sshd_config, AllowAgentForwarding and the shell-access limitation, checked 2026-10-15.

OCSP stapling delivers status evidence under a client policy

Mon, 06 Dec 2027 00:00:00 +0000

OCSP stapling lets a TLS server deliver a signed certificate-status response during a handshake. A client that would otherwise make an online OCSP request may avoid that request. The saving depends on the client’s revocation policy: not every browser performs an OCSP lookup for every connection, and not every certificate issuer still operates an OCSP service. Stapling is one transport for status evidence, not a replacement for certificate validation.

Deliver evidence without transferring trust

The server obtains a response from the issuer or an authorized responder and caches it for eligible handshakes. The client still needs to check the response signature, signer authority, certificate identifier, status, and acceptable time bounds. A server cannot make a response trustworthy merely by attaching it. A good OCSP status also does not prove hostname coverage, certificate validity, or the complete trust chain.

The wire representation depends on the TLS version. TLS 1.2 uses the status-request extension and a CertificateStatus handshake message. TLS 1.3 places the status response in an extension of the corresponding Certificate entry. Calling either mechanism a generic certificate_status extension obscures that distinction. Ordinary network attackers cannot simply strip authenticated handshake messages while leaving the Finished checks valid; availability and revocation failures require a more precise threat model.

Check support before enabling anything

An operator must first confirm that the issuer supplies usable status responses and that the deployed TLS server and clients support the desired policy. Let’s Encrypt ended its OCSP service on August 6, 2025 and moved to CRLs. A missing staple on a certificate without OCSP support is therefore not automatically a broken refresh job. Check current issuer documentation instead of copying an unconditional “enable stapling everywhere” checklist.

For an issuer that supports it, refresh before expiry and after certificate rotation. Inspect the certificate association, freshness and actual edge response, not just cache presence. Different processes can hold different caches. A cached good response can remain acceptable while newer revocation information exists; stapling does not provide instantaneous revocation knowledge.

When it breaks

Missing, expired, invalid, and revoked responses are different conditions. Clients may reject, consult another mechanism, or apply a documented soft-fail policy. A missing response does not universally trigger a direct CA request, and an invalid supplied response does not universally become a harmless delay. Describe the behavior of the specific validator rather than promising that every handshake continues.

The TLS Feature extension, often called Must-Staple, can require status evidence when enforced by a supporting client. It does not force clients without that support to enforce the policy. The server must be prepared for cold starts, renewal, and responder outages before relying on such a requirement. An outage does not instantly invalidate a still-acceptable cached response, but the remaining freshness window bounds that protection.

Clock problems can change acceptance decisions. thisUpdate and nextUpdate describe status timing, while producedAt describes response production. Actual validators have age and skew rules; some valid protocol responses omit nextUpdate. Keep those implementation details explicit. Do not conclude that a Boolean labeled “signature valid” demonstrates real cryptographic verification.

OCSP evidence delivery: mechanism and evidence boundaries.

Check it quickly

Save this as stapling_policy.py and run python3 stapling_policy.py with Python 3.9 or newer. The standalone model uses synthetic post-verification inputs, requires both time bounds, and deliberately applies strict rejection to supplied invalid evidence. It has no network, certificate parser, signature implementation, TLS server, or browser.

"""Post-verification policy model. Booleans are fixtures, not cryptography."""
from dataclasses import dataclass, replace
from datetime import datetime, timedelta, timezone

@dataclass(frozen=True)
class Response:
 cert_id: str
 status: str
 signature_ok: bool
 signer_authorized: bool
 this_update: datetime
 next_update: datetime

def decide(response, now, cert_id, require_staple):
 if response is None:
 return "reject-missing" if require_staple else "consult-other-policy"
 if response.cert_id != cert_id:
 return "reject-wrong-certificate"
 if not (response.signature_ok and response.signer_authorized):
 return "reject-untrusted"
 if not response.this_update <= now < response.next_update:
 return "reject-time"
 if response.status == "revoked":
 return "reject-revoked"
 if response.status != "good":
 return "reject-unknown"
 return "status-good-only"

now = datetime(2026, 10, 15, 12, tzinfo=timezone.utc)
good = Response("synthetic-cert", "good", True, True,
 now - timedelta(hours=1), now + timedelta(hours=1))
cases = [
 (good, False, "status-good-only"),
 (None, False, "consult-other-policy"),
 (None, True, "reject-missing"),
 (replace(good, status="revoked"), False, "reject-revoked"),
 (replace(good, status="unknown"), False, "reject-unknown"),
 (replace(good, signature_ok=False), False, "reject-untrusted"),
 (replace(good, signer_authorized=False), False, "reject-untrusted"),
 (replace(good, cert_id="another-cert"), False, "reject-wrong-certificate"),
 (replace(good, next_update=now), False, "reject-time"),
 (replace(good, this_update=now + timedelta(minutes=1)), False, "reject-time"),
]
for response, required, expected in cases:
 actual = decide(response, now, "synthetic-cert", required)
 assert actual == expected, (actual, expected)
 print(actual)
assert decide(good, now + timedelta(hours=2), "synthetic-cert", False) == "reject-time"
print("PASS: 11 explicit policy cases; no certificate or TLS validation performed")

Eleven checks distinguish an acceptable status from missing, revoked, unknown, wrong-certificate, unauthorized-signer, bad-signature, expired, and future-dated inputs. The final time shift demonstrates expiration under this model’s strict interval. An optional missing response returns consult-other-policy, which is not an acceptance result and does not claim that a fetch occurred.

The success result is deliberately status-good-only: the rest of certificate validation remains outside this function. Retained Python 3.12.14 records report successful runs of these exact fences; this source review did not rerun them. Assertions must stay enabled, without -O or PYTHONOPTIMIZE. Live validation still needs the actual issuer, signed response, TLS delivery, client policy, renewal, and refresh failure.

Sources

RFC 6960, OCSP response authority, certificate binding, status and time semantics, checked 2026-10-15.
RFC 6066, TLS 1.2 status-request and CertificateStatus messages, checked 2026-10-15.
RFC 8446, TLS 1.3 certificate-entry status extension and authenticated transcript, checked 2026-10-15.
RFC 7633, TLS Feature requirements and client support, checked 2026-10-15.
Let’s Encrypt OCSP retirement, issuer ended OCSP on August 6 2025, checked 2026-10-15.
Python assert statement, optimization removes assertions and their expressions, checked 2026-10-18.

Security context defines constraints that need runtime evidence

Sat, 20 Nov 2027 00:00:00 +0000

A Kubernetes securityContext configures process identity and selected operating-system constraints. It can reduce what a compromised application is permitted to do, but it does not establish a complete security boundary by itself. Start with the operations the application actually needs, configure the appropriate fields, and test both a permitted operation and a forbidden one in the resulting container.

Source-described Kubernetes 1.34.11 fixture, not rerun. Results reflect the combined settings; RuntimeDefault is runtime-dependent. No container escape resistance, exhaustive seccomp coverage, hostile multi-tenant isolation or application authorization was tested. Execution remains blocked.

Put each setting at the right scope

Pod-level settings can supply user and group identity, shared-volume group ownership behavior and a seccomp profile. Container-level settings can override applicable defaults and configure capabilities, privilege escalation and a read-only root filesystem. Check the field’s actual API scope; placing a familiar name under the wrong securityContext does not create an equivalent constraint.

runAsUser selects a numeric user, while runAsNonRoot requires the container to satisfy a non-root policy. These settings complement image metadata rather than trusting a username’s appearance. Volume permissions must also permit the selected identity to perform required work. For an emptyDir used below, fsGroup supplies group access so the application can write its designated working directory.

Linux capabilities divide privileges that would otherwise be associated broadly with root. Dropping ALL removes those capabilities from the container’s configured set. Standard containers do not inherit every Linux capability by default, and a container running as root is not automatically proof of a successful host escape. Review the actual effective privileges rather than using either shortcut.

When it breaks

allowPrivilegeEscalation false sets the no_new_privs constraint for the process. It restricts gaining privileges through executing programs, such as set-user-ID or file-capability transitions. It does not revoke every privilege the process already has or replace application authorization. Inspect the process flag and effective capabilities; do not attribute every denied operation to this one field.

readOnlyRootFilesystem makes the container’s root filesystem read-only. Other mounts can remain writable, including explicitly supplied working volumes. This does not imply a blanket no-execution policy: an interpreter can read and run code stored in a writable volume. It also does not stop network requests or remove access to already mounted data. Read-only storage is one constrained operation, not proof that a compromise cannot progress.

Seccomp filters system calls, but RuntimeDefault depends on the runtime’s supplied profile. A process reporting seccomp filter mode confirms an active filtering mechanism, not that every undesirable syscall or attack path is blocked. Ordinary Linux runtimes can enforce these fields; a special sandbox is not required merely for the settings to have an effect, though stronger isolation has separate design considerations.

Conflicting identity settings can pass API admission but prevent container startup. An image may also expect to write caches or temporary files under its root filesystem. Diagnose startup state and denied paths, then provide only the working storage the application requires. Avoid solving every permission failure by restoring root, privilege escalation or a writable root filesystem.

Check it quickly

The fixture and observations below are retained from the original article. This review did not rerun the Kubernetes integration; reported success is historical, not a new execution result.

Use a disposable Linux Kubernetes cluster, kubectl and python:3.11-slim-bookworm available on its nodes. Save the script as security-context.py and run python3 security-context.py KUBECONFIG_PATH CONTEXT with explicit test-cluster arguments. The account needs namespace creation and deletion permissions. The recorded server was Kubernetes 1.34.11 using kind’s standard runtime configuration.

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

namespace = 'notes-security-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 probe = '''from pathlib import Path
import errno,json,os,subprocess,time
status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
try:
 Path('/tmp/forbidden-write').write_text('x')
 raise AssertionError('root filesystem unexpectedly writable')
except OSError as error:
 assert error.errno==errno.EROFS
try:
 os.setuid(0)
 raise AssertionError('unexpected UID escalation')
except OSError as error:
 assert error.errno==errno.EPERM
work=Path('/work'); (work/'data').write_text('writable')
(work/'example.py').write_text("print('interpreted from the writable volume')")
ran=subprocess.check_output(['python3',str(work/'example.py')],text=True).strip()
result={'uid':os.getuid(),'gid':os.getgid(),'cap_eff':int(status['CapEff'].strip(),16),
 'no_new_privs':int(status['NoNewPrivs']),'seccomp':int(status['Seccomp']),
 'root_write_errno':errno.EROFS,'uid_zero_denied':True,
 'volume_value':(work/'data').read_text(),'writable_volume_code':ran}
assert result['uid']==result['gid']==10001
assert result['cap_eff']==0 and result['no_new_privs']==1 and result['seccomp']==2
print(json.dumps(result),flush=True); time.sleep(600)
'''
 podspec = spec(probe)
 podspec['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 10001,
 'runAsGroup': 10001, 'fsGroup': 10001, 'seccompProfile': {'type': 'RuntimeDefault'}}
 podspec['volumes'] = [{'name': 'work', 'emptyDir': {}}]
 c = podspec['containers'][0]
 c['securityContext'] = {'allowPrivilegeEscalation': False, 'readOnlyRootFilesystem': True,
 'capabilities': {'drop': ['ALL']}}
 c['volumeMounts'] = [{'name': 'work', 'mountPath': '/work'}]
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'restricted'}, 'spec': podspec})
 wait_for(lambda: obj(namespace, 'pod', 'restricted'), pod_ready)
 observed = json.loads(wait_for(lambda: k('logs', '-n', namespace, 'restricted').stdout.strip(), bool))
 conflicting = spec()
 conflicting['securityContext'] = {'runAsNonRoot': True, 'runAsUser': 0}
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'conflict'}, 'spec': conflicting})
 refused = wait_for(lambda: obj(namespace, 'pod', 'conflict'), lambda p:
 any(c.get('state', {}).get('waiting', {}).get('reason') == 'CreateContainerConfigError'
 for c in p.get('status', {}).get('containerStatuses', [])))
 waiting = refused['status']['containerStatuses'][0]
 assert 'runAsUser breaks non-root policy' in waiting['state']['waiting']['message']
 assert waiting['restartCount'] == 0
 print(json.dumps({'runtime_observation': observed,
 'conflicting_uid_accepted_by_api_but_container_start_refused': True,
 'container_escape_resistance_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

The restricted Pod reports UID and GID 10001, effective capabilities zero, NoNewPrivs one and seccomp mode two. Writing under the root filesystem’s /tmp fails with EROFS, and changing to UID zero fails with EPERM. Those results reflect the combined identity and privilege settings, not an isolated test of each field’s individual effect.

The process successfully writes a value under /work and invokes Python on a file it wrote there. This deliberately demonstrates the allowed working-volume behavior and the limit of the read-only-root claim. A second Pod combines runAsNonRoot with runAsUser zero: the API accepts it, but kubelet reports CreateContainerConfigError before the container starts.

The original article reports that all assertions passed, and the namespace was removed. The fixture verifies these concrete runtime constraints and startup failure. It does not test container escape resistance, every seccomp rule, hostile multi-tenancy or the application’s authorization model.

Sources

Kubernetes: Security Context, Pod and container security fields and runtime effects, checked 2026-10-15.
Linux: No New Privileges Flag, restrictions on privilege gains through exec, checked 2026-10-15.
Linux: capabilities(7), separate capability privileges and process capability sets, checked 2026-10-15.

Certificate transparency makes issuance observable

Wed, 03 Nov 2027 00:00:00 +0000

Certificate Transparency makes public TLS certificate issuance observable. It does not determine whether a domain owner authorized an issuance, replace certificate-chain validation, or guarantee that every certificate everywhere is logged. A misissued certificate can have valid transparency evidence. The benefit is a public trail that monitors and affected owners can investigate.

A promise is not an inclusion proof

An SCT, or Signed Certificate Timestamp, is a log’s signed promise to incorporate a submitted certificate or precertificate within its Maximum Merge Delay. It is not another certificate and is not itself proof that the entry already exists in the tree. Its timestamp records the log’s statement, not necessarily the exact issuance instant.

A Merkle inclusion proof connects a particular serialized leaf to a particular tree root and size. The verifier must authenticate that root through the relevant signed log statement and trusted log key. Accepting whatever root accompanies an untrusted proof establishes no useful external fact: an attacker can construct an entirely different tree.

Consistency proofs answer another question: whether a later tree extends an earlier tree without changing its existing prefix. One inclusion proof cannot establish that history. Signed checkpoints, consistency verification, and comparisons between independently observed views help expose a log that equivocates. Hashes make alterations detectable under these checks; they do not physically prevent a malicious operator from changing data.

Chrome applies its own CT policy to publicly trusted TLS certificates, considering SCT delivery, accepted log states, counts, and operator diversity. That is not equivalent to searching a public log during every page load, nor to deciding whether the owner requested the certificate. RFC 9162 specifies version 2 and obsoletes RFC 6962; publication alone does not establish which protocol a particular deployed log supports.

When it breaks

A valid SCT from an unacceptable log, an insufficient set of SCTs, or an incorrect delivery mechanism may fail the target client’s policy. Conversely, satisfying CT does not fix an expired, untrusted, or wrongly named certificate. Keep normal TLS validation, CT compliance, and issuance authorization as separate decisions.

Domain monitoring also needs interpretation. A newly observed name may belong to an authorized CDN, wildcard, or renewal. Compare issuer, names, fingerprints, and your issuance inventory before escalating; unexplained issuance needs investigation and corrective action, not an assumption that logging already blocked it.

Public logging can reveal certificate names. Do not submit private certificates or sensitive internal naming solely to try an experiment. A monitor’s incomplete coverage or stale data also cannot prove absence. Operational monitoring needs a declared scope and freshness, rather than treating an empty search result as a universal guarantee.

Check it quickly

Save this as ct_probe.go and run go run ct_probe.go with Go 1.23 or newer. This offline exercise uses RFC 6962’s SHA-256 Merkle construction with three synthetic strings, not real certificates or serialized CT leaves. It verifies only the middle leaf at index one in this fixed tree.

package main

import (
 "crypto/sha256"
 "fmt"
 "runtime"
)

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func leaf(data string) [32]byte {
 return sha256.Sum256(append([]byte{0}, []byte(data)...))
}

func branch(left, right [32]byte) [32]byte {
 var data [65]byte
 data[0] = 1
 copy(data[1:33], left[:])
 copy(data[33:], right[:])
 return sha256.Sum256(data[:])
}

// Only verifies index 1 of a three-leaf fixture; not a general CT verifier.
func middleOfThree(data string, proof [][32]byte, root [32]byte) bool {
 return len(proof) == 2 && branch(branch(proof[0], leaf(data)), proof[1]) == root
}

func main() {
 a, b, c := leaf("fixture-A"), leaf("fixture-B"), leaf("fixture-C")
 root := branch(branch(a, b), c)
 check(fmt.Sprintf("%x", root) == "111b905d16e9388f6e9079aaec820ab176d649b9daecabcdb3aca45fe4b6b646", "root differs from independent fixture vector")
 check(fmt.Sprintf("%x", leaf("")) == "6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d", "empty leaf vector differs")
 check(leaf("") != sha256.Sum256(nil), "an empty tree and an empty leaf are different")
 proof := [][32]byte{a, c}
 check(middleOfThree("fixture-B", proof, root), "correct inclusion proof must pass")
 check(!middleOfThree("fixture-X", proof, root), "altered entry must fail")
 badProof := append([][32]byte(nil), proof...)
 badProof[0][0] ^= 1
 check(!middleOfThree("fixture-B", badProof, root), "altered sibling must fail")
 check(!middleOfThree("fixture-B", [][32]byte{c, a}, root), "sibling order matters")
 check(!middleOfThree("fixture-B", proof[:1], root), "short proof must fail")
 check(!middleOfThree("fixture-B", append(proof, b), root), "extra proof element must fail")
 badRoot := root
 badRoot[0] ^= 1
 check(!middleOfThree("fixture-B", proof, badRoot), "wrong trusted root must fail")
 nextRoot := branch(branch(a, b), branch(c, leaf("fixture-D")))
 check(nextRoot != root, "appending an entry changes this fixture root")
 check(!middleOfThree("fixture-B", proof, nextRoot), "old proof must not verify against the new root")
 fmt.Println("correct proof accepted; altered entry, sibling, order, length, and root rejected")
 fmt.Println("empty tree differs from empty leaf; fourth entry changes root; old proof fails")
 fmt.Printf("three-leaf fixture root: %x\n", root)
 fmt.Println(runtime.Version())
}

A leaf hashes a 0x00 byte followed by its data; an internal node hashes a 0x01 byte followed by its two child hashes. These prefixes provide domain separation. For three leaves, the left subtree contains A and B, while C stands alone on the right. An empty tree and a single empty leaf also have different hashes.

The correct proof contains A’s hash and C’s hash. Recombining them with B reproduces the expected root, which was independently cross-checked with Python’s hashlib. Changing B, a sibling, their order, proof length, or the expected root fails. Appending D changes this fixture’s root, and the old three-leaf proof no longer verifies against it.

The article uses three synthetic strings and RFC 6962 hash prefixes. The fixed proof for B consists of A and C hashes, rebuilding branch(branch(A, B), C). Its hardcoded root is trusted only within the exercise. No SCT signature, live log key, consistency proof, browser policy, or issuance authorization is established.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. The hardcoded test root represents an already trusted three-leaf checkpoint only within this exercise. No SCT signature, real log key, certificate encoding, network endpoint, generic inclusion verifier, or consistency proof is implemented. In particular, observing a changed root does not prove append-only growth. Browser policy enforcement and live misissuance monitoring remain separate, untested operations.

Sources

RFC 6962: Certificate Transparency, version-1 Merkle hashing, SCT promises, and proof distinctions, checked 2026-09-09.
RFC 9162: Certificate Transparency version 2, protocol scope, misissuance limits, and version history, checked 2026-09-09.
Chrome Certificate Transparency policy, client-specific SCT and log acceptance requirements, checked 2026-09-09.

SYN cookies answer when the queue overflows

Sat, 30 Oct 2027 00:00:00 +0000

A Linux TCP listener distinguishes pending handshake requests from established connections waiting for accept(). These are commonly called the SYN queue and accept queue. Their capacity limits and overflow paths differ, so diagnosing a connection failure requires identifying which stage is under pressure.

SYN cookies reduce retained per-request state while a handshake is incomplete. The server encodes recoverable information in its SYN-ACK and reconstructs connection state after a valid reply. This saves pending-request memory; it does not make processing free, remove established-connection state, or guarantee admission and normal application performance.

SYN cookies concern the handshake. Verification does not bypass the accept queue or increase application acceptance capacity.

Two queues, two different symptoms

On the ordinary stateful path, the listener remembers a request while awaiting the final ACK. Linux documents tcp_max_syn_backlog as a per-listener limit on remembered requests; the documented memory-dependent default and request-size estimate are not universal allocation measurements. The application’s listen() backlog, capped by somaxconn, bounds established connections waiting for acceptance. Linux has defaulted somaxconn to 4096 since 5.4; actual settings can differ.

Cookies can help when pending-handshake state is exhausted, but do not guarantee connection completion. A full accept queue can prevent creation or admission of the established child. With tcp_abort_on_overflow=0, some stateful paths ignore the ACK and retain the pending request, allowing later recovery. A client may already report connect success; other attempts may time out. The earlier 400-client account is not reproduced or bound to retained raw results in this review, so it cannot establish an exact loss count.

Linux mode 1 uses cookies as an overflow fallback when CONFIG_SYN_COOKIES is enabled; mode 2 generates them unconditionally for testing. In the pinned Linux 6.12 IPv4 implementation, the sequence number combines keyed hashes, the client initial sequence number, a time counter and an MSS-table index. The raw high bits of the returned acknowledgment are not simply a readable counter.

That implementation advances its counter every sixty seconds and accepts only the current or preceding counter slot before further validation. A seventy-second-old cookie can cross two boundaries and fail; elapsed time alone does not fix the outcome. Validation also binds connection fields and checks the recovered index. These checks resist blind spoofing but provide neither application authentication nor a universal one-in-2²⁴ security guarantee.

Option support depends on the implementation and handshake. Linux 6.12 can encode window-scale, SACK and ECN information in timestamp bits and recover it from the timestamp echo. Without that timestamp path, options can be lost. The documentation warns about extension and performance limitations, but does not justify saying every cookie SYN-ACK has no options or every admitted connection is slower.

The pinned IPv4 implementation chooses among four MSS-table entries, rather than preserving an arbitrary advertisement exactly. If scaling is absent, a 65535-byte receive window can constrain a long-RTT transfer; that is a conditional window limit, not measured cookie-mode throughput. Missing SACK changes recovery information without forcing retransmission of every later segment. Capture the actual options before attributing a slowdown to cookies.

When it breaks

Cookies can reduce visible pending-request depth while pressure continues. Monitor changes in SyncookiesSent alongside queue occupancy, connection attempts, CPU load, warnings and application outcomes. A rising counter is not proof of an attack: legitimate overload or unconditional test mode can also produce cookies. Application failures remain possible and useful evidence; cookies do not make all flooding invisible.

Cookies do not add accept-queue or application-processing capacity. Investigate ListenOverflows, acceptance rate and resource limits together before choosing a remedy. A larger backlog absorbs some bursts but does not increase sustained processing capacity. Faster acceptance or additional workers helps only when that stage is the bottleneck; changing cookie mode does not repair a stalled application.

Check it quickly

These read-only Linux commands inspect configuration, cumulative counters and listening queues; they do not reproduce a flood, validate cookies or measure packet delivery:

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn
nstat -az | grep -E 'Syncookies|ListenOverflow|ListenDrops'
ss -lnt

Take comparable snapshots in the relevant network namespace and examine deltas. A healthy current service can have nonzero historical counters, and a brief nonempty accept queue is normal. For a listening TCP socket, Recv-Q shows established connections waiting for accept() and Send-Q the backlog limit. Sustained occupancy near that limit, new overflows and request failures together are stronger evidence of acceptance pressure than any single total.

Sources

RFC 4987 TCP SYN flood mitigation, the cookie construction and its trade-offs, checked 2026-09-16.
RFC 9293 TCP, the three-way handshake and the notion of a backlog, checked 2026-09-16.
Linux kernel ip-sysctl, tcp_syncookies, tcp_max_syn_backlog, somaxconn and tcp_abort_on_overflow, checked 2026-09-16.
Linux 6.12 IPv4 SYN cookies, keyed cookie construction, MSS table and timestamp-carried options, checked 2026-10-19.
Linux 6.12 TCP cookie timing, sixty-second counter and two-slot age test, checked 2026-10-19.
Linux 6.12 pending request handling, conditional overflow handling and retained requests, checked 2026-10-19.

The forward-secrecy boundary of TLS ECDHE

Wed, 27 Oct 2027 00:00:00 +0000

Forward secrecy limits the damage from later compromise of a long-term authentication key. For a correctly authenticated ephemeral Diffie-Hellman exchange, that key alone does not reveal earlier session secrets. The claim assumes those ephemeral secrets were not also captured. It does not make a compromised endpoint, key log, or recorded plaintext safe.

Fresh agreement, authentication and key derivation are separate jobs. Forward secrecy limits a specific later-signing-key compromise scenario; it does not protect exposed session secrets or compromised endpoints.

Two kinds of keys do different jobs

In ECDHE, each side generates an ephemeral private key and sends its public share. Combining a local private key with the peer’s public share produces the same shared secret at both ends. An observer sees public shares, not the private values needed to reproduce that computation under the algorithm’s security assumptions.

TLS does not simply use the raw ECDH output as an application encryption key. Its key schedule derives distinct handshake and application traffic secrets, binds them to the handshake context, and separates directions and purposes. Fresh exchange material is one ingredient in that larger protocol, not a substitute for the protocol.

A certificate binds an identity to a public key under a trust policy. The corresponding private key signs handshake material; the certificate object does not itself sign anything. In TLS 1.3, CertificateVerify authenticates the handshake transcript in certificate-based handshakes. Without authentication, an active intermediary could replace public shares and establish separate secrets with each side.

An RSA or Ed25519 authentication key can coexist with an ephemeral exchange; the signature algorithm and key-exchange group are separate choices. TLS 1.3 also defines PSK-only resumption, which lacks DHE’s forward-secrecy property, while PSK-with-DHE adds fresh exchange material. Optional early data has weaker guarantees still. Do not infer forward secrecy for every traffic epoch solely from a TLS version or certificate label.

When it breaks

Reusing an exchange private key over long periods weakens the intended compromise boundary. Poor randomness, exposed ephemeral values, crash dumps, or TLS key logging can expose the very secrets that the guarantee assumes remain unavailable. Later disclosure of a traffic secret is a different threat from later disclosure of the certificate’s signing key.

Endpoint compromise during a session can reveal plaintext directly. A stolen authentication key can also support impersonation of future connections when an attacker can intercept them. Forward secrecy protects a particular past-traffic scenario; it does not revoke credentials or repair ongoing compromise.

Erasure is an implementation concern, not a line of reassuring prose. Setting a Go variable to nil is not proof that all copies disappeared from memory, swap, or diagnostics. Keep secrets out of logs and manage credential compromise separately from claims about recorded traffic.

Check it quickly

Save this as ecdhe_probe.go and run go run ecdhe_probe.go with Go 1.23 or newer. It uses standard-library X25519 and Ed25519 operations entirely in memory. The signing public key represents an already trusted identity for this exercise. The signed message is explicitly not a TLS transcript; this is a primitive-level experiment, not a new TLS implementation.

package main

import (
 "bytes"
 "crypto/ecdh"
 "crypto/ed25519"
 "crypto/rand"
 "fmt"
 "runtime"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 identity, signingKey, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 curve := ecdh.X25519()
 var previous []byte
 for round := 1; round <= 2; round++ {
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 server, err := curve.GenerateKey(rand.Reader)
 must(err)
 message := []byte("ECDH learning probe; not a TLS transcript\x00")
 message = append(message, client.PublicKey().Bytes()...)
 message = append(message, server.PublicKey().Bytes()...)
 signature := ed25519.Sign(signingKey, message)
 check(ed25519.Verify(identity, message, signature), "trusted signature must verify")
 altered := append([]byte(nil), message...)
 altered[len(altered)-1] ^= 1
 check(!ed25519.Verify(identity, altered, signature), "altered share must fail authentication")

 clientSecret, err := client.ECDH(server.PublicKey())
 must(err)
 serverSecret, err := server.ECDH(client.PublicKey())
 must(err)
 check(bytes.Equal(clientSecret, serverSecret), "peers must agree")
 if previous != nil {
 check(!bytes.Equal(previous, clientSecret), "fresh exchange must produce a different observed secret")
 }
 previous = clientSecret
 fmt.Println("round", round, "agrees; altered share fails signature verification")
 }
 _, err = curve.NewPublicKey(make([]byte, 31))
 check(err != nil, "wrong-length X25519 key must fail parsing")
 zero, err := curve.NewPublicKey(make([]byte, 32))
 must(err)
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 _, err = client.ECDH(zero)
 check(err != nil, "all-zero shared result must be rejected")
 fmt.Println("two fresh exchanges differ with one signing identity; malformed and low-order inputs rejected")
 fmt.Println(runtime.Version())
}

Each round produces matching secrets at both participants, and the two fresh rounds produce different observed secrets while retaining one signing identity. Changing a byte of the signed public-share message fails signature verification. A thirty-one-byte X25519 public key fails parsing; a length-correct all-zero input parses but fails ECDH’s all-zero-result check.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. Only result labels are printed. The example deliberately retains the previous shared secret for comparison, so it demonstrates no secure-erasure property. It also does not prove cryptographic hardness by exhausting possible keys.

The experiment isolates agreement, freshness, authentication, and invalid-input handling. It does not exercise a real TLS transcript, certificate chain, traffic-key derivation, packet encryption, resumption, or production key disposal. Use a maintained TLS implementation for those duties and verify the actual negotiated mode; assembling these primitives is not sufficient to build a secure transport.

Sources

RFC 8446: TLS 1.3, CertificateVerify, the key schedule, PSK modes, and forward-secrecy boundaries, checked 2026-09-09.
Go crypto/ecdh, X25519 agreement and invalid public-key behavior, checked 2026-09-09.
Go crypto/ed25519, signing and verification operations, checked 2026-09-09.

Kernel entropy turns device noise into keys

Fri, 22 Oct 2027 00:00:00 +0000

Linux applications normally obtain cryptographic randomness from a kernel generator, rather than consuming one newly collected physical bit for every output bit. Initialization and state reuse still matter. A busy machine is not automatically safe, and a quiet machine is not automatically broken. Diagnose the interface, kernel version, and boot or cloning process before deciding that a counter proves a security failure.

Separate collection from output

The Linux 6.12 implementation mixes inputs into a BLAKE2s-based pool and uses ChaCha20 for output. These are implementation details of that version, not an eternal interface contract. Hardware sources, interrupt timing, and bootloader input contribute under platform-specific trust rules. Supplying bytes and crediting them toward initialization are separate operations; the kernel cannot assume arbitrary user-supplied bytes contain fresh unpredictability.

In that implementation, both poolsize and the initialized entropy counter reach 256 bits. Reads do not spend that counter like fuel. A historical manual’s 4096-bit description therefore should not become a universal alert threshold. Record the running kernel and inspect its behavior instead of claiming that every Linux version exposes identical counters or that a small number proves weak output.

Choose an initialization-aware interface

Default getrandom waits until initialization. GRND_NONBLOCK instead reports EAGAIN while initialization is incomplete, allowing an application to report the condition without hanging. Once initialized, a default-source request of at most 256 bytes has the documented full-read and signal guarantees; callers should still check errors and returned length. Larger requests need normal handling of partial results and interruptions.

The random device’s behavior changed in Linux 5.6: it no longer blocks for entropy depletion after initialization. In the inspected Linux 6.12 code, GRND_RANDOM does not select a separately depleting output pool. Some manual descriptions retain older behavior, so avoid combining their historical limits with current-kernel claims. Direct urandom reads can precede initialization; prefer the supported initialization-aware interface for early-boot key generation.

When it breaks

Early boot can still lack sufficient credited input. Missing device nodes in a container are a separate interface problem: getrandom does not require a device pathname, and ordinary containers share their host’s kernel. A blocked operation deserves an explicit startup failure or waiting policy, rather than replacing cryptographic randomness with timestamps, predictable seeds, or insecure fallback output.

A saved seed can improve the next boot, but writing a file back to urandom does not itself credit entropy. Neither a 32-byte file nor the mere presence of a hardware device proves immediate readiness. Use the distribution’s seed-management mechanism and its documented trust policy. Protect seed files, avoid shipping a common saved seed in cloned images, and keep any bootloader-specific seed handling aligned with the operating system.

Disk-image cloning and restoring a running virtual machine are different hazards. The first can copy seed files or already-generated host keys; the second can duplicate live generator state. Fresh inputs and VM-generation-ID handling can separate subsequent state. Identical future output is a risk to investigate, not an inevitable consequence of every clone. A seed shared by two machines alone does not establish that their entire generator states match.

Input crediting, initialization and output are separate. Only the labeled Linux 6.18.44 results are retained historical observations; no new random request was made.

Check it quickly

Run this Python 3 script on Linux. It reads counters and makes one nonblocking 32-byte request without printing random material, reading private keys, changing seed files, or requiring administrator access:

from pathlib import Path
import json
import os
import platform

def counters():
 result = {}
 for name in ("entropy_avail", "poolsize"):
 try:
 result[name] = int(Path("/proc/sys/kernel/random", name).read_text())
 except OSError as error:
 result[name] = type(error).__name__
 return result

before = counters()
try:
 sample = os.getrandom(32, os.GRND_NONBLOCK)
except BlockingIOError:
 print(json.dumps({"kernel": platform.release(), "ready": False,
 "counters": before}))
else:
 assert len(sample) == 32
 print(json.dumps({"kernel": platform.release(), "ready": True,
 "bytes_returned": len(sample), "before": before,
 "after": counters()}))

Retained audit output from Linux 6.18.44 with Python 3.12.14 reported ready=true, bytes_returned=32, and 256 for both counters before and after. These are observations from an already-initialized host, not a test of early boot, hardware quality, or restored virtual machines. For EAGAIN the program reports ready=false; that branch was not reproduced. This source-only review made no random request. Other syscall errors propagate rather than becoming an initialization verdict.

A successful call establishes that this interface supplied the requested bytes at this moment. It is not a statistical or cryptographic proof of unpredictability, and comparing two samples cannot provide that proof either. Restricted proc access may leave counter error names while the syscall still succeeds. Treat those outcomes separately instead of turning unavailable diagnostics into a claim of entropy failure.

Investigate identity reuse with direct evidence

A key’s modification time cannot prove which random source generated it. Files survive reboots, copying preserves timestamps, and clocks can move. Likewise, an inaccessible or missing initialization log is not proof of failed initialization. Inspect image preparation, key-generation code, boot policy, and duplicate public-key fingerprints. Rotate identities when actual duplication or exposure is established; do not infer compromised keys solely from a timestamp comparison.

Sources

Linux 6.12 random implementation, initialization accounting, getrandom, sysctls, and VM-fork reseeding, checked 2026-10-15.
Linux getrandom(2), initialization-aware calls, small reads, and errors; historical GRND_RANDOM details require version context, checked 2026-10-15.
Linux random(4), uncredited writes and the Linux 5.6 blocking change; historical pool-size text is not current-kernel evidence, checked 2026-10-15.
systemd 256 random-seed service, seed lifecycle, entropy-credit policy, and image preparation, checked 2026-10-15.

Image signatures bind a digest to a trusted signer

Thu, 21 Oct 2027 00:00:00 +0000

A container image tag is a mutable pointer; a digest identifies content. A valid signature binds a signed statement about that digest to a signing key. Whether that key represents an authorized person or workload is a trust-policy decision. Signing alone does not prove who built the image, that the build followed a claimed process, or that the resulting software is safe.

The useful boundary is the verifier’s decision before deployment. It must check the content binding and the intended trust root, then apply the required identity and provenance policy. A registry location, a familiar tag, or the existence of a signature is insufficient.

Digests are the identity, tags are pointers

An OCI manifest digest hashes the manifest bytes. Descriptors in that manifest identify configuration and layers by their own digests; clients must check those bindings too. A changed manifest has a different digest under the collision-resistance assumption. Mutating a stored blob without updating its descriptor should cause a content-integrity failure, not silently redefine the image.

Cosign’s normal image-signature payload contains the image digest, which verification checks against the requested image. Different tags can resolve to the same signed digest. If a tag moves, the previously verified digest says nothing about the newly resolved object. Resolve and verify the intended digest, then deploy that same digest; a later tag lookup leaves a race between checking and use.

A tag string does not bind image content

A signature over the literal string app:v2 authenticates that statement, not the changing object behind it. A signature can include other contextual claims, so inspect its actual format and verifier behavior. Do not disable digest-claim checks merely to make an unrelated payload pass.

For key-based verification, policy must establish why the supplied public key is trusted. For keyless verification, check the expected certificate identity and OIDC issuer as well as the certificate chain and required transparency evidence. Fulcio certificates associate an identity with a key; they do not inspect a build or certify its output. A build claim requires suitable provenance, a trusted builder, and checks that the attested subject matches the artifact.

Verification is the control, not the signature

Enforcement can happen at admission or before deployment, but only within the configured scope. Confirm which workloads and registries are covered and how verification failures are handled. Merely recording a digest does not establish authorization, and even a correctly verified signature does not detect every vulnerability or malicious behavior in signed software.

Cryptographic signature validity and current policy acceptance are separate. Retiring a key requires changing the accepted trust policy; generating a replacement key alone does not update every verifier. Short-lived certificates and trusted signing-time evidence can support verification of historical signatures after certificate expiry. Transparency makes signing activity inspectable, but does not automatically revoke compromised identities or block malicious releases. Incident response must decide which identities, time windows, digests, and attestations remain acceptable.

When it breaks

A deploy step verifies one digest and later pulls a mutable tag. Another push can change the deployed bytes after verification. Pin the verified digest through the handoff, including the intended manifest or multi-platform index, and check how the runtime selects the platform-specific image.

Another failure accepts any cryptographically valid signer. Restrict trust to authorized keys or expected identity-and-issuer pairs, and test rejection of a wrong signer and an unapproved digest. A compromise requires investigation and an explicit policy change; it does not retroactively prove that every older artifact was malicious.

Image signature trust: mechanism and evidence boundaries.

Check it quickly

The following commands are a template, not a runnable fixture: the registry is an example and the digest is abbreviated. Before any authorized registry check, supply an existing test image’s complete digest, its trusted public key, and installed Cosign and Skopeo versions. No signing, registry operation, or deployment was run for this source review.

cosign verify --key cosign.pub registry.example.com/app@sha256:9ab5a134...
cosign tree registry.example.com/app@sha256:9ab5a134...
skopeo inspect --format '{{.Digest}}' docker://registry.example.com/app:latest

Expect successful verification of the specified digest under the selected key, not necessarily a printed human identity. cosign tree discovers associated objects; listing them does not verify their claims. The Skopeo result can check the tag’s current resolution, but a mismatch only means it differs from the digest just checked; the other digest might have its own signatures. Even equality is a snapshot, not protection against the tag moving afterward.

Sources

Sigstore: verifying signatures with cosign, key-based and keyless verification over a digest, checked 2026-09-16.
SLSA v1.0 specification, provenance, digests and what a signature is claimed to attest, checked 2026-09-16.
Sigstore policy-controller, enforcing signature and identity policy at admission, checked 2026-09-16.
OCI image descriptor specification, digest binding to referenced content, checked 2026-10-18.
SLSA v1.0: verifying artifacts, trusted builder and provenance policy distinct from signature validity, checked 2026-10-18.
Sigstore overview, identity certificates and transparency boundaries, checked 2026-10-18.
Sigstore timestamps, trusted signing time and certificate validity, checked 2026-10-18.
Sigstore: signing containers, tree discovers associated signatures, checked 2026-10-18.
Skopeo inspect manual, top-level manifest digest and platform-specific fields, checked 2026-10-18.

OAuth code flow trades a code for a token

Wed, 20 Oct 2027 00:00:00 +0000

Authorization-code flow moves access-token delivery to the token endpoint rather than returning an access token in the browser-facing authorization redirect. That distinction reduces exposure in URLs, but does not mean a browser can never hold a token. The client architecture determines who exchanges the code and where the resulting credentials live.

The authorization redirect carries a code; the token endpoint delivers tokens. PKCE, client and callback binding, expiry, and single use protect different boundaries. Storage follows the client architecture, and the offline model does not validate a complete login.

Public clients can use code flow

A confidential web backend can authenticate to the token endpoint and retain tokens server-side. A browser then uses an application session whose security still needs attention. Public clients, including native applications and browser applications, cannot reliably keep a distributed client secret confidential. They can nevertheless use authorization-code flow with PKCE; it is not reserved for backends.

For a browser application performing its own exchange, JavaScript receives the token response. Code flow avoids access-token delivery in the authorization URL, but does not remove script compromise or token-storage risks. A backend-based design changes those boundaries rather than eliminating all browser-side risk. OAuth delegates access; an application needing user authentication should use an appropriate identity protocol such as OpenID Connect and validate its separate artifacts.

Bind the exchange to the original request

PKCE begins with a high-entropy verifier generated for the transaction. The authorization request carries its S256 challenge; the token request supplies the verifier. The authorization server checks that they correspond. The verifier is not a static client password and must remain associated with the initiating transaction. An intercepted code alone should not be sufficient to redeem it.

RFC 9700 requires PKCE for public clients and recommends it for confidential clients. Use S256 rather than a downgrade to plain. Confidential clients still perform their configured client authentication; PKCE does not replace that responsibility. Client authentication also need not mean transmitting a shared client secret: deployments can use asymmetric mechanisms.

Bind each code to its client and redirect URI, keep its lifetime short, and enforce single use. Compare registered redirect URIs exactly, with the standardized native-loopback port exception where applicable. When redirect_uri appeared in the authorization request, its token-request value must match. Reject unknown callbacks at authorization time rather than waiting until a stolen code reaches the token endpoint.

When it breaks

Single use does not prevent an attacker from redeeming an unprotected code first. Expiry bounds the opportunity without making interception harmless. Logs, browser history, referrers, and crash reports can still expose callback codes. Avoid recording them, use appropriate HTTPS redirect endpoints, and apply the specific native-loopback rules when building native clients.

Clients must prevent callback CSRF and code injection. Securely bind transaction state to the initiating browser session, and use the relevant state, PKCE, or OpenID Connect protections according to the protocol and provider guarantees. A random state value checked without session binding is not enough. Multiple authorization servers also require protection against issuer mix-up; a successful exchange alone does not establish the expected identity provider.

Refresh-token protection is a separate lifecycle. For public clients, the security best practice requires sender-constrained refresh tokens or rotation. Rotation with reuse detection is one solution, not a universal claim that every unchanged refresh token is infinitely valid. Expiry, revocation, inactivity limits, and client binding determine the actual exposure window.

Check it quickly

Save as oauth_code_demo.py and run python3 oauth_code_demo.py. This offline, single-threaded model uses synthetic client identifiers, an explicitly registered callback, fresh random codes, and an injected clock. The helper receives the verifier to compute the challenge locally; a real authorization request sends only the challenge, never the verifier.

import base64
import hashlib
import hmac
import re
import secrets

REGISTERED = {'demo-client': 'https://app.example.test/callback'}
CODES = {}
NOW = 1_800_000_000


def challenge(verifier):
 if not re.fullmatch(r'[A-Za-z0-9._~-]{43,128}', verifier):
 raise ValueError('invalid verifier syntax')
 return base64.urlsafe_b64encode(hashlib.sha256(verifier.encode('ascii')).digest()).rstrip(b'=').decode()


def authorize(client, redirect, verifier, now):
 if REGISTERED.get(client) != redirect:
 raise ValueError('unregistered redirect')
 code = secrets.token_urlsafe(32)
 CODES[code] = {'client': client, 'redirect': redirect, 'challenge': challenge(verifier),
 'expires': now + 60, 'used': False}
 return code


def exchange(code, client, redirect, verifier, now):
 entry = CODES.get(code)
 if entry is None:
 raise ValueError('unknown code')
 if entry['used']:
 raise ValueError('code already used')
 if now >= entry['expires']:
 raise ValueError('code expired')
 if client != entry['client'] or redirect != entry['redirect']:
 raise ValueError('client or redirect mismatch')
 if not hmac.compare_digest(challenge(verifier), entry['challenge']):
 raise ValueError('PKCE verifier mismatch')
 # Atomic only because this demonstration runs sequentially in one thread.
 entry['used'] = True
 return 'DEMO-' + secrets.token_urlsafe(32)


def rejected(label, operation):
 try:
 operation()
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


client = 'demo-client'
redirect = REGISTERED[client]
verifier = secrets.token_urlsafe(32)
code = authorize(client, redirect, verifier, NOW)
rejected('wrong client', lambda: exchange(code, 'other-client', redirect, verifier, NOW))
rejected('wrong redirect', lambda: exchange(code, client, redirect + '/extra', verifier, NOW))
rejected('wrong verifier', lambda: exchange(code, client, redirect, 'x' * 43, NOW))
if not exchange(code, client, redirect, verifier, NOW).startswith('DEMO-'):
 raise RuntimeError('valid exchange failed')
rejected('replay', lambda: exchange(code, client, redirect, verifier, NOW))
stale = authorize(client, redirect, verifier, NOW)
rejected('exact expiry', lambda: exchange(stale, client, redirect, verifier, NOW + 60))
rejected('unregistered callback', lambda: authorize(client, 'https://other.example.test/', verifier, NOW))
print('PASS: bound code accepted once; six negative cases rejected')

Expect six rejection lines and PASS. A correct exchange succeeds once. Wrong client, altered redirect, and incorrect verifier fail before consuming that code; replay fails afterward. A second code fails exactly at its expiry, and an unregistered callback is rejected before issuance. No code or token is printed or transmitted, and no real identity provider is involved.

The model is deliberately narrower than a deployed authorization server. Its sequential check-and-mark operation does not test concurrency: production storage must consume codes atomically. It omits HTTP processing, consent, client authentication, browser-session binding, issuer validation, and refresh-token handling. Use these cases as requirements for integration tests against an isolated provider configuration; passing the in-memory exercise does not demonstrate the full login journey.

Sources

RFC 6749: OAuth 2.0, authorization code binding and token exchange, checked 2026-10-15.
RFC 7636: PKCE, verifier syntax and S256 challenges, checked 2026-10-15.
RFC 9700: OAuth 2.0 Security Best Current Practice, public clients, redirects, CSRF, and refresh-token protections, checked 2026-10-15.
RFC 8252: OAuth 2.0 for Native Apps, public native clients and loopback redirects, checked 2026-10-15.

Request smuggling desyncs the proxy chain

Tue, 19 Oct 2027 00:00:00 +0000

Request smuggling occurs when components disagree about HTTP message boundaries and an attacker exploits the disagreement. In a proxy chain, bytes treated as one request’s body by the front end may become another request at the back end. The important evidence is inconsistent parsing and forwarding, not simply finding two HTTP status lines in a response capture.

One stream, incompatible boundaries

HTTP/1.1 framing follows explicit rules. A valid Content-Length can define the body length; chunked transfer coding ends with its terminating chunk and trailer section. A request with neither framing mechanism has no body. Transfer-Encoding takes precedence when both fields appear, but that combination is suspicious and requires special handling rather than casual acceptance.

RFC 9112 permits a server to reject a request containing both fields or process it according to Transfer-Encoding alone. Either way, it must close the connection after responding. An intermediary choosing to forward such a message must first remove the received Content-Length and process Transfer-Encoding before forwarding. Rejecting dual framing at an entry boundary is a useful strict policy, but it is not the only behavior described by the standard.

CL.TE names a front end using Content-Length and a back end using Transfer-Encoding; TE.CL reverses those choices. Other discrepancies involve conflicting lengths or inconsistent handling of transfer-coding syntax. These labels describe parser behavior, not two equally valid interpretations. Invalid input must not become a reason for different hops to guess independently.

Desynchronization has more than one impact

A complete hidden request may be processed immediately; it need not wait for a victim’s next request. Other attacks leave an incomplete prefix that combines with later traffic. Response-queue poisoning is one possible consequence, but route-filter bypass, cache poisoning, and unauthorized backend requests can matter without that exact sequence. Impact depends on connection reuse, routing, authentication, and the application’s behavior.

An extra backend request should therefore be traced to the actual bytes and connection. Counts alone are insufficient: retries, health checks, caching, and asynchronous logging can legitimately make layers disagree. A backend log entry lacking its expected edge counterpart is an investigation lead, not automatic proof. Use correlation data and a controlled fixture with identifiable synthetic requests.

When it breaks

A superficial header filter can miss ambiguity created during protocol conversion. HTTP/2 uses frames rather than HTTP/1.1 chunked delimiting, but downgrading to HTTP/1.1 creates a new serialization boundary that must be correct. For HTTP/2 requests, any Content-Length must agree with the content size; no-content responses have separate rules. It is incorrect to treat HTTP/2 as having no relevant length checks.

End-to-end HTTP/2 avoids some downgrade-specific problems, but is not a universal immunity claim. Validate protocol transitions, reject malformed messages consistently, and avoid reusing a connection after unrecoverable framing errors. A strict edge can block a specific attack even if another component is tolerant; assess each reachable path rather than asserting that hardening one hop can never help.

Client-side curl output showing HTTP/2 only establishes the protocol on that client connection. It cannot reveal the protocol used behind a CDN or reverse proxy. Similarly, two responses may simply answer two ordinary pipelined requests. A safe assessment must demonstrate which bytes each component classified and whether the result crossed an intended request boundary.

The same synthetic bytes expose incompatible boundary arithmetic. A two-request pipeline alone is not smuggling; live parser and connection behavior remain untested.

Check it quickly

Save as framing_demo.py and run python3 framing_demo.py. This offline model constructs a byte string in memory, computes the two deliberately incompatible boundaries, and checks a strict rejection policy. Nothing is sent to a server, no socket is opened, and the synthetic path identifies no real administrative endpoint. The declared length is calculated from the actual body rather than copied as a magic constant.

# An in-memory boundary model, not an HTTP parser or network probe.
followup = b'GET /synthetic-next HTTP/1.1\r\nHost: example.test\r\n\r\n'
body = b'0\r\n\r\n' + followup
head = (b'POST /upload HTTP/1.1\r\nHost: example.test\r\nContent-Length: '
 + str(len(body)).encode() + b'\r\nTransfer-Encoding: chunked\r\n\r\n')
wire = head + body
header_end = wire.index(b'\r\n\r\n') + 4
cl_boundary = header_end + len(body)
# This fixture has precisely one zero chunk and an empty trailer section.
te_boundary = header_end + len(b'0\r\n\r\n')
if wire[cl_boundary:] != b'' or wire[te_boundary:] != followup:
 raise RuntimeError('boundary expectations failed')
if cl_boundary == te_boundary:
 raise RuntimeError('the two interpretations must differ')


def reject_dual_framing(header):
 names = {line.split(b':', 1)[0].lower() for line in header.split(b'\r\n')[1:] if b':' in line}
 if {b'content-length', b'transfer-encoding'} <= names:
 raise ValueError('dual framing rejected')


try:
 reject_dual_framing(head)
except ValueError as error:
 print(error)
else:
 raise RuntimeError('ambiguous message accepted')

ordinary_first = b'GET /first HTTP/1.1\r\nHost: example.test\r\n\r\n'
ordinary_pipeline = ordinary_first + followup
first_boundary = ordinary_pipeline.index(b'\r\n\r\n') + 4
if ordinary_pipeline[first_boundary:] != followup:
 raise RuntimeError('ordinary pipeline example failed')
print('CL remaining bytes:', len(wire[cl_boundary:]))
print('TE remaining bytes:', len(wire[te_boundary:]))
print('ordinary pipeline: two intentionally separate requests')
print('PASS: different framing boundaries; dual framing rejected; pipelining distinguished')

The Content-Length interpretation leaves zero remaining bytes; the chunked interpretation leaves the complete fifty-two-byte synthetic request. The strict policy rejects the combination. A separate ordinary pipeline intentionally contains two requests and is not labeled smuggling merely because both are present. PASS confirms these limited relationships when run successfully. This source review checked the unchanged bytes and retained records without executing the model or contacting a proxy.

This is not a general HTTP parser. The chunked case contains only a zero chunk and an empty trailer section; the header check does not implement all field grammar, duplicate-header rules, or protocol conversion. It demonstrates why a boundary disagreement matters without claiming a live proxy is vulnerable. Integration testing needs an isolated, authorized chain, its actual parser versions, connection lifecycle observations, and negative cases proving ambiguous input cannot reach an unintended backend operation.

Sources

RFC 9112: HTTP/1.1, framing precedence, intermediary handling, errors, and persistent connections, checked 2026-10-15.
PortSwigger: HTTP request smuggling, parser disagreement classes and consequences, checked 2026-10-15.
RFC 9113: HTTP/2, framed content, malformed messages, and Content-Length consistency, checked 2026-10-15.

JWTs carry a signature and a lifetime

Mon, 18 Oct 2027 00:00:00 +0000

A signed JWT carries claims whose integrity can be checked without looking up the entire token in a session table. That convenience does not make its contents confidential, establish authorization, or prevent replay. Start with the token format and the application’s validation contract, then test each boundary independently. A successful cryptographic check is one input to an access decision, not the decision itself.

A signature protects integrity, not secrecy. This compact JWS model separates cryptographic checks, application policy, and the final access decision. Its time window excludes exact expiry; a valid signature alone does not make a token usable.

Signed tokens are one JWT form

This article concerns compact, signed or MAC-protected JWTs represented as JWS: three dot-separated segments containing a protected header, payload, and signature or MAC. Base64url is reversible encoding. JWT also supports encrypted JWE representations, so “every JWT is readable and has three segments” is incorrect. Even with encryption, minimize personal information and avoid embedding unrelated credentials.

HS256 uses a shared secret for HMAC. Every verifier holding that secret can also mint tokens, so it cannot prove which particular holder issued one. Asymmetric signatures separate signing and verification capabilities. Neither design permits accepting an arbitrary key supplied by an untrusted token. Configure trusted issuers, key sources, algorithms, and acceptable token types together.

Validation is an application contract

Parse enough untrusted data to locate a configured key, but do not act on claims until cryptographic verification and all policy checks succeed. Treat kid as an identifier within a trusted key set, never an unrestricted filename or fetching instruction. Bind each key to its intended algorithm. A token declaring HS256 must not cause an RSA public key to become an HMAC secret.

Check the intended issuer and audience as well as the subject and permissions needed for the operation. A genuine token for another API is still wrong here. Different token kinds may need mutually exclusive validation rules to prevent substitution. Use a maintained JWT library with explicit validation options in production; the small model below intentionally supports only one fixture profile.

Registered claims are not universally mandatory in the base JWT specification. An application profile decides what it requires. For a short-lived access token, require and enforce exp; nbf, when present, limits early use. The current time must be earlier than exp, with any explicitly configured, bounded clock allowance. iat records issuance time; it does not automatically expire a token or replace nbf. Requiring integer times is this exercise’s narrower policy, not the full NumericDate definition.

When it breaks

An expired token can have a perfectly valid signature. Conversely, a recent timestamp proves nothing if the signature is invalid. Test those failures separately, including the exact expiry instant. A blanket “token invalid” response may be suitable for callers, while internal diagnostics should distinguish causes without recording the token itself.

Expiration limits replay duration but is not the only possible revocation mechanism. A service can consult session state, a token identifier denylist, an account policy, or an introspection endpoint. Those choices introduce consistency and availability requirements. Rotating a signing key can affect many tokens and is not a convenient substitute for individual logout. A jti value alone neither stores server-side data nor implements revocation.

Do not use Python assert statements for authentication enforcement: optimization can remove them. Also reject invalid claim types rather than coercing a string or boolean into a timestamp. A readable demonstration secret must never become a deployed signing key. HS256 needs a sufficiently strong secret; this fixture generates thirty-two random bytes per run and discards them afterward.

Check it quickly

Save as jwt_check.py and run both python3 jwt_check.py and python3 -O jwt_check.py. The fixed synthetic time makes boundary tests deterministic without altering the system clock. Everything stays in memory; no issued token or key is printed, persisted, or sent anywhere.

import base64
import hashlib
import hmac
import json
import re
import secrets

# Ephemeral fixture key, never a production credential.
KEY = secrets.token_bytes(32)
NOW = 1_800_000_000


def encode(raw):
 return base64.urlsafe_b64encode(raw).rstrip(b'=').decode('ascii')


def decode(value):
 if not re.fullmatch(r'[A-Za-z0-9_-]+', value):
 raise ValueError('invalid base64url')
 return base64.b64decode(value + '=' * (-len(value) % 4), altchars=b'-_', validate=True)


def issue(claims, algorithm='HS256'):
 head = encode(json.dumps({'alg': algorithm, 'typ': 'JWT'}).encode())
 body = encode(json.dumps(claims).encode())
 signed = f'{head}.{body}'
 signature = encode(hmac.new(KEY, signed.encode(), hashlib.sha256).digest())
 return f'{signed}.{signature}'


def verify(token, now):
 head, body, signature = token.split('.')
 header = json.loads(decode(head))
 if not isinstance(header, dict) or header != {'alg': 'HS256', 'typ': 'JWT'}:
 raise ValueError('unsupported header')
 expected = hmac.new(KEY, f'{head}.{body}'.encode(), hashlib.sha256).digest()
 if not hmac.compare_digest(expected, decode(signature)):
 raise ValueError('bad signature')
 claims = json.loads(decode(body))
 if not isinstance(claims, dict):
 raise ValueError('claims must be an object')
 if claims.get('iss') != 'fixture-issuer' or claims.get('aud') != 'fixture-api':
 raise ValueError('issuer or audience mismatch')
 if any(type(claims.get(k)) is not int for k in ('iat', 'nbf', 'exp')):
 raise ValueError('integer times required by fixture')
 if not claims['iat'] <= now or not claims['nbf'] <= now < claims['exp']:
 raise ValueError('outside time policy')
 if not isinstance(claims.get('sub'), str) or not claims['sub']:
 raise ValueError('subject required')
 return claims


def rejected(label, token, now=NOW):
 try:
 verify(token, now)
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


claims = {'iss': 'fixture-issuer', 'aud': 'fixture-api', 'sub': 'demo',
 'iat': NOW, 'nbf': NOW, 'exp': NOW + 60}
token = issue(claims)
if verify(token, NOW)['sub'] != 'demo':
 raise RuntimeError('valid token failed')
rejected('exact expiry', token, NOW + 60)
rejected('not yet valid', issue({**claims, 'nbf': NOW + 1}))
rejected('future issued-at', issue({**claims, 'iat': NOW + 1}))
rejected('wrong audience', issue({**claims, 'aud': 'other-api'}))
rejected('wrong issuer', issue({**claims, 'iss': 'other-issuer'}))
rejected('missing expiry', issue({k: v for k, v in claims.items() if k != 'exp'}))
rejected('boolean time', issue({**claims, 'exp': True}))
rejected('algorithm mismatch', issue(claims, 'none'))
head, body, signature = token.split('.')
forged_body = encode(json.dumps({**claims, 'sub': 'admin'}).encode())
rejected('tampered subject', f'{head}.{forged_body}.{signature}')
print('PASS: valid accepted; nine negative cases rejected')

Both invocations must print nine rejection lines and PASS. The successful token establishes the positive path. Negative cases cover the exact expiry, early use, future issuance, issuer, audience, absent expiry, a boolean time, algorithm mismatch, and a changed subject with the original signature. Enforcement and test failures use explicit exceptions, so optimized execution retains them.

This is an executable explanation, not a complete JWT implementation. It omits audience arrays, duplicate-member handling, key discovery and rotation, nested tokens, clock leeway, size limits, revocation, and authorization rules. Those are deliberate boundaries to review in the production library and application; passing these cases does not certify an authentication system.

Sources

RFC 7519: JSON Web Token, JWT representations and registered claim semantics, checked 2026-10-15.
RFC 8725: JWT Best Current Practices, trusted algorithms, keys, issuers, audiences, and token substitution, checked 2026-10-15.
RFC 7518: JSON Web Algorithms, HMAC key strength requirements, checked 2026-10-15.
Python: assert statement, optimization removes assertions, checked 2026-10-15.

Prepared statements separate values from SQL structure

Sat, 16 Oct 2027 00:00:00 +0000

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.

Binding protects the SQL grammar boundary, not every language interpreted inside a value. A bound LIKE pattern still treats percent and underscore as wildcards. Decide whether an endpoint accepts a pattern or a literal substring and escape for that operator when needed. Regex, full-text search, and authorization each have their own semantics after safe binding.

When it breaks

In Psycopg, %s is a driver placeholder, not an invitation to use Python string formatting. Pass the values as the second argument to execute, leave the placeholder unquoted, and use a one-element tuple for one positional value. Interpolating a value first and then calling a parameter-capable API has already crossed the boundary the API was supposed to preserve.

A placeholder represents a value, not a table, column, or keyword. Dynamic identifiers require a deliberate structural choice. Use an allow-list to restrict the supported columns, then the driver’s identifier composition facility to quote that identifier correctly. Keep direction keywords under application control. Numeric LIMIT and OFFSET values can be bound, while still requiring product-specific range validation.

Preparation does not freeze the first execution plan forever. PostgreSQL distinguishes custom plans, built using current parameter values, from generic plans reused across values. Automatic selection considers planning overhead and estimated execution costs. Schema or statistics changes can also trigger replanning. A statement can remain parameterized while its access path changes; plan reuse and injection resistance are different properties.

Binding works with zero named statements. Named reuse and custom/generic planning are separate properties. The source fixture was not rerun; forced plan modes make no latency claim.

Check it quickly

Use Python with Psycopg 3 installed and set PG_DSN to a disposable PostgreSQL database. Supply connection configuration through your existing secure mechanism. The recorded run used Psycopg 3.3.5 and PostgreSQL 18.6. Save the following as a Python file and execute it with that environment variable set. The table is temporary and disappears when the connection closes:

import os
import psycopg
from psycopg import sql

with psycopg.connect(os.environ['PG_DSN'], autocommit=True,
 prepare_threshold=5) as conn:
 conn.execute('CREATE TEMP TABLE people (id integer PRIMARY KEY, label text NOT NULL)')
 conn.execute("INSERT INTO people VALUES (1,'alice'),(2,'bob')")
 query = 'SELECT id FROM people WHERE label=%s ORDER BY id LIMIT %s'
 hostile = "' OR true --"
 assert conn.execute(query, (hostile, 10), prepare=False).fetchall() == []
 count = conn.execute('SELECT count(*) FROM pg_prepared_statements').fetchone()[0]
 assert count == 0
 print('bound without named preparation:', count, 'named statements; no match')
 for value in ("O'Reilly", r'a\b', 'x; DROP TABLE people; --'):
 assert conn.execute('SELECT %s::text', (value,), prepare=False).fetchone() == (value,)
 for label, expected in (('alice', [(1,)]), ('bob', [(2,)])):
 assert conn.execute(query, (label, 10), prepare=True).fetchall() == expected
 assert conn.execute('SELECT count(*) FROM pg_prepared_statements').fetchone() == (1,)
 print('named preparation reused: alice=1, bob=2')

 def ordered(column, limit):
 if column not in {'id', 'label'}:
 raise ValueError('unsupported sort column')
 if type(limit) is not int or not 1 <= limit <= 100:
 raise ValueError('limit must be an integer from 1 through 100')
 statement = sql.SQL('SELECT id FROM people ORDER BY {} LIMIT %s').format(
 sql.Identifier(column))
 return conn.execute(statement, (limit,), prepare=False).fetchall()

 assert ordered('label', 1) == [(1,)]
 for column, limit in [('label; DROP TABLE people', 1), ('id', 0), ('id', 101)]:
 try:
 ordered(column, limit)
 except ValueError:
 pass
 else:
 raise AssertionError('invalid request accepted')
 print('identifier allow-list and bound LIMIT checked')

 conn.execute('PREPARE plan_lab(text) AS SELECT id FROM people WHERE label=$1')
 conn.execute('SET plan_cache_mode=force_custom_plan')
 assert conn.execute("EXECUTE plan_lab('alice')").fetchall() == [(1,)]
 counters = "SELECT generic_plans,custom_plans FROM pg_prepared_statements WHERE name='plan_lab'"
 assert conn.execute(counters).fetchone() == (0, 1)
 conn.execute('SET plan_cache_mode=force_generic_plan')
 assert conn.execute("EXECUTE plan_lab('bob')").fetchall() == [(2,)]
 assert conn.execute(counters).fetchone() == (1, 1)
 print('same prepared statement: custom=1, generic=1')
 conn.execute('RESET plan_cache_mode')
 conn.execute('DEALLOCATE plan_lab')

The first result reports zero named statements and no match for the hostile value. That call explicitly disables named preparation while retaining binding, so it demonstrates that the safety boundary exists before statement reuse. Quotes, backslashes, and semicolons then round-trip unchanged; the table remains available for subsequent queries.

Two calls with prepare=True reuse one named statement and return Alice’s identifier one and Bob’s identifier two. The configured threshold permits explicit preparation. Setting prepare_threshold=None instead disables named preparation altogether in the tested driver, including explicit requests. Do not confuse that switch with disabling value binding.

The ordering function returns one row for a supported column and bound limit. It rejects an unsupported column and limits outside one through one hundred before issuing SQL. Identifier quoting protects syntax; the allow-list defines which valid syntax the endpoint actually supports. Neither decision should be delegated to arbitrary request text.

Finally, the same SQL prepared statement executes once under forced custom planning and once under forced generic planning. Its counters change from zero generic and one custom plan to one of each. Both return the expected row. These forced settings make the distinction observable; they do not measure what automatic planning would choose for a realistic skewed workload or recommend forcing either mode globally.

Inspect reuse in the real deployment

PostgreSQL’s default automatic policy starts parameterized prepared statements with custom plans and later compares a generic alternative. Look at representative parameter distributions and actual execution plans before deciding whether reuse helps. This two-row exercise makes no latency or network-round-trip claim. Driver protocol batching, connection setup, and query cost affect those measurements independently.

Named statements belong to server sessions. Connection pools and transaction-pooling proxies must manage that lifetime correctly, using explicitly supported prepared-statement behavior or disabling named reuse where necessary. Binding remains the default even for a query executed only once. Continue to enforce tenant predicates, object permissions, and result-size limits: a safely parameterized query can still return data the caller was never meant to see.

The operational fixture is unchanged here and was not rerun in this review. Its expected outputs and earlier observations remain distinct from current execution evidence.

Sources

Psycopg parameter API, binding syntax and identifier composition, checked 2026-10-15.
Psycopg prepared statements, thresholds, explicit preparation, and session lifetime, checked 2026-10-15.
PostgreSQL 18 PREPARE, custom and generic plans and automatic selection, checked 2026-10-15.
PostgreSQL 18 pattern matching, LIKE wildcard and escape semantics, checked 2026-10-15.

Setuid changes effective identity at exec

Sat, 02 Oct 2027 00:00:00 +0000

Setuid on a Linux executable can change the process’s effective user ID to the file owner’s ID when exec succeeds. It does not replace every credential with the owner’s login identity. A privileged helper can therefore perform a controlled operation on another account’s behalf, but its input handling and privilege lifetime become part of the security boundary. The mode bit alone proves neither that a transition occurred nor that the helper is safe.

Distinguish the file bit from process credentials

The usual set-user-ID transition changes the effective UID, then copies it into the saved set-user-ID. The real UID remains unchanged. Group credentials are separate: setuid does not automatically install the file owner’s supplementary groups. Linux also has filesystem IDs and capability sets, so real, effective and saved UIDs are useful observations rather than a complete description of authority.

Inspect the deployed file instead of assuming a distribution-wide mode. A privileged password-changing program might be installed differently in a container or customized image. A lowercase s in the owner-execute position indicates both setuid and owner execute; uppercase S indicates setuid without that execute bit. Neither display substitutes for checking ownership, the actual executable, and the process context in which it will run.

Execution can suppress the transition

Linux documents no_new_privs, nosuid mounts and tracing as conditions that suppress the privilege transition; some documented combinations can fail execution instead. File capabilities also have execution constraints. Do not disable one of these protections merely to make a demonstration work. Establish which policy applies to the target path and process, and report the resulting limitation.

Linux ignores set-user-ID and set-group-ID bits on interpreter scripts. Moving a helper from a native executable to a script while preserving its mode therefore does not preserve elevation behavior. Making a general-purpose interpreter privileged is not a safe substitute. Another executable launched by a privileged program may deliberately drop credentials, so running a separate id command is not necessarily a faithful observation of the original helper’s credentials.

Privilege dropping needs a complete design

The setuid system call is distinct from the executable’s mode bit. A sufficiently privileged caller can change real, effective and saved UIDs; an unprivileged caller has a narrower set of permitted transitions. Seteuid can support a reversible effective-UID change when a permitted saved identity remains available. Always check the syscall’s return value before assuming the intended state was reached.

Removing a saved UID is only part of permanent privilege removal. Supplementary groups, retained capabilities, open privileged descriptors, namespaces and later execution paths also matter. A single setuid call is not a universal privilege-drop recipe. The required sequence depends on the program’s existing credentials and resources; security-sensitive helpers need design review rather than a copied one-line pattern.

When it breaks

A mode listing with an s can mask a suppressed transition, while an overly broad helper can expose real authority through unsafe path lookup or user-selected configuration. Loader protections restrict dangerous environment variables in secure-execution mode, but they do not validate the application’s inputs. Avoid shell-based command construction and define exactly which files, arguments and operations the helper may use.

Capabilities can narrow a particular grant, such as permission to bind privileged ports, without making every other permission disappear. Existing user access and other capabilities still apply, and capability bounding and securebits rules qualify root behavior. Likewise, namespace-local root is not host root, but mapped ordinary-user permissions remain meaningful. Socket activation can supply an already-open listener; it does not remove the need to secure the service handling it.

Setuid affects selected exec-time credentials under documented guards. The retained inspection does not execute the target or prove elevation; current runtime remains held.

Check it quickly

On Linux with Bash, GNU stat, util-linux findmnt, libcap getcap and Python 3, run the complete block below. It reads one installed file and the new Python process’s own credential status. It never executes passwd, changes permissions, changes credentials, mounts anything or creates a namespace. The explicit pathname avoids a helper search, but separate metadata reads do not atomically bind a later execution to the same file. This review did not run the inspection; assertions require a trusted test environment.

BASH_ENV= bash --noprofile --norc <<'BASH'
set -eu
target=/usr/bin/passwd
test -f "$target"
stat -c 'mode=%A numeric=%a owner=%u group=%g path=%n' "$target"
findmnt --noheadings --output TARGET,VFS-OPTIONS --target "$target"
getcap -v "$target"
python3 - <<'PYTHON'
import os
from pathlib import Path

status = dict(line.split(':', 1) for line in
 Path('/proc/self/status').read_text().splitlines() if ':' in line)
uids = tuple(map(int, status['Uid'].split()))
gids = tuple(map(int, status['Gid'].split()))
assert uids[:3] == os.getresuid()
assert gids[:3] == os.getresgid()
assert len(uids) == len(gids) == 4
for key in ['Uid', 'Gid', 'Groups', 'NoNewPrivs', 'CapEff', 'CapBnd']:
 print(f'{key}:{status[key]}')
print('PASS: inspected metadata and current credentials; target not executed')
PYTHON
BASH

Expect the actual mode and numeric ownership, the filesystem’s mount options, and the target’s capability listing. An empty capability set does not prove absence of the setuid bit, and a setuid bit does not imply a file capability. The Python assertions compare the first three UID and GID fields with the corresponding system-call results; the fourth fields are filesystem IDs.

The PASS line establishes this read-only inspection only. Values vary by host, and no expected root identity is hardcoded. This exercise does not demonstrate elevation, irreversible dropping, or exploit resistance. Those require a separately authorized disposable security test and observations inside the actual helper, without weakening the host’s protections.

Sources

Linux execve, effective-ID changes, unchanged credentials and suppression conditions, checked 2026-10-15.
Linux credentials, supplementary groups and filesystem IDs, checked 2026-10-15.
Linux setuid, privileged and unprivileged transitions and required error checking, checked 2026-10-15.
Linux seteuid, permitted effective-ID transitions, checked 2026-10-15.
Linux capabilities, capability limits and credential interactions, checked 2026-10-15.
Linux dynamic linker, secure-execution environment restrictions, checked 2026-10-15.
Linux proc_pid_status, credential and capability status fields, checked 2026-10-15.

Create temporary files atomically in a trusted location

Sun, 26 Sep 2027 00:00:00 +0000

A shared temporary directory is a namespace other users may also write to, not a guarantee that every file inside is public. File permissions still control content access. The dangerous assumption is that choosing a pathname gives your process ownership of whatever already occupies it. Create a new object atomically and keep using the returned handle instead of trusting a predictable name.

Name ownership and content access are different

Linux commonly gives /tmp mode 1777: broad directory write/search permissions plus the sticky bit. Sticky restricts removal and renaming by other users; it does not make existing files confidential or reserve names before creation. File ownership, directory ownership, capabilities and other access controls still matter. Inspect the actual environment rather than assuming every operating system uses the same path, mount or permissions.

An ordinary write-open can follow a pre-existing symbolic link. O_CREAT|O_EXCL rejects an existing final pathname, including a symlink. O_NOFOLLOW rejects a symlink in the final component, but alone does not reject an existing regular file or secure every ancestor. These are different contracts. Use a trusted parent directory and a suitable temporary-file API rather than treating one flag as universal pathname protection.

The creation mode also applies only when a new file is created. Opening an existing file with O_CREAT and mode 0600 does not tighten that file’s previous permissions. Random names reduce collisions, but the security property is exclusive creation, not merely an unpredictable-looking string. A name-only API leaves an interval in which another process can claim the name.

Location does not establish isolation

Python’s tempfile.mkstemp securely creates and opens a file; the caller owns closing and deletion. TemporaryDirectory provides a restricted directory and normal-exit cleanup. TMPDIR influences location selection, but does not itself create a private directory or verify an isolation policy. Python caches its default-directory choice, so pass dir= explicitly when the operation requires a particular location.

systemd’s PrivateTmp= can give a service a separate temporary-file namespace. It changes sharing behavior and has platform and unit prerequisites; it is not equivalent to setting an environment variable. Do not depend on cross-service /tmp paths when those services have separate namespaces. This article’s local exercise does not enable or verify systemd isolation.

A tmpfs mount grows with use and can use swap when available and permitted. Its default size limit is half physical RAM when no size is specified; that is a ceiling, not memory reserved at mount time. Allocation and inode limits can independently prevent new work. /tmp is not necessarily tmpfs, so base capacity monitoring on the actual mount and workload.

When it breaks

Predictable names can redirect writes or reuse an object with unexpected permissions. Cleanup on only the success path leaks files after ordinary exceptions. Context managers and finally help those paths, but cannot promise execution after SIGKILL or a machine crash. Plan stale-file cleanup without deleting another process’s live work, and never rely on temporary storage for the only durable copy.

A shared capacity limit can make one writer disrupt another. Creation and later writes can fail at different stages; creating an empty file does not reserve room for its eventual contents. Bound scratch usage and choose a filesystem appropriate to its lifetime and size. Persistent application-state directories are not a blanket destination for disposable build output.

Atomic temporary files: mechanism and evidence boundaries.

Check it quickly

Save this as temp_contract.py and run python3 temp_contract.py on Linux with Python 3.11 or newer, a trusted temporary parent and assertions enabled. Do not use -O or PYTHONOPTIMIZE: optimization removes the os.write call inside an assertion. The fixture creates its own files under one identity and does not change existing permissions.

from pathlib import Path
from tempfile import TemporaryDirectory, mkstemp
import errno
import os
import stat

with TemporaryDirectory(prefix="temp-contract-") as directory:
 root = Path(directory)
 target = root / "target"
 target.write_text("original")
 predictable = root / "predictable"
 predictable.symlink_to(target)
 with predictable.open("w") as stream:
 stream.write("followed")
 assert target.read_text() == "followed"

 for flags, expected in [
 (os.O_WRONLY | os.O_CREAT | os.O_EXCL, errno.EEXIST),
 (os.O_WRONLY | os.O_CREAT | os.O_NOFOLLOW, errno.ELOOP),
 ]:
 try:
 fd = os.open(predictable, flags, 0o600)
 except OSError as error:
 assert error.errno == expected, error
 else:
 os.close(fd)
 raise AssertionError("pre-existing symlink was accepted")
 assert target.read_text() == "followed"

 before = stat.S_IMODE(target.stat().st_mode)
 fd = os.open(target, os.O_WRONLY | os.O_CREAT, 0o600)
 try:
 assert stat.S_IMODE(os.fstat(fd).st_mode) == before
 finally:
 os.close(fd)

 fd, name = mkstemp(prefix="owned-", dir=root)
 try:
 mode = stat.S_IMODE(os.fstat(fd).st_mode)
 assert mode & 0o077 == 0
 assert os.write(fd, b"synthetic data") == 14
 os.lseek(fd, 0, os.SEEK_SET)
 assert os.read(fd, 14) == b"synthetic data"
 finally:
 os.close(fd)
 os.unlink(name)
 assert not Path(name).exists()
 print("ordinary open followed link; EXCL and NOFOLLOW rejected it")
 print("existing mode preserved:", oct(before), "; temporary mode:", oct(mode))
assert not root.exists()
print("descriptor round trip and normal-exit cleanup passed")

The ordinary open changes the symlink target. Both guarded opens then fail with their specific expected errors without changing its contents. Reopening the existing target preserves its measured mode; the test intentionally does not assume a particular process umask. The secure temporary file has no group/other permission bits, and its returned descriptor supports the complete write/read round trip.

The earlier article reports Python 3.12.14 success with modes 0644 and 0600, but no matching retained execution record was established here. This review did not run filesystem examples. The code checks ordinary cleanup, not cross-user attacks, concurrent races, sudden termination, tmpfs exhaustion, network filesystems or namespace isolation. Printed summaries alone cannot replace those separate tests.

Sources

Linux open(2), O_CREAT mode application, O_EXCL and final-component O_NOFOLLOW semantics, checked 2026-10-15.
Python 3.12 tempfile, mkstemp, TemporaryDirectory, cached default selection and cleanup limits, checked 2026-10-15.
Linux tmpfs documentation, dynamic allocation, swap and independent size/inode limits, checked 2026-10-15.
systemd.exec(5), PrivateTmp= sharing boundaries and implementation prerequisites, checked 2026-10-15.
Linux unlink(2), directory write/search requirements and sticky ownership restrictions, checked 2026-10-15.
Python assert statement, optimization removes assertions and their expressions, checked 2026-10-18.

Frame policy names who may embed your page

Thu, 23 Sep 2027 00:00:00 +0000

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.

The embedded response can declare Content-Security-Policy: frame-ancestors 'none' to disallow embedding, or use an explicit set of permitted ancestors. The named origins belong to the pages allowed to contain this document. If a merchant embeds a payment page, the payment page’s policy needs to permit the merchant’s origin; listing the payment widget’s own origin does not express that relationship.

Put each restriction on the right response

frame-ancestors answers who may embed the current document. frame-src answers which frame sources the current document may load. A restrictive frame-src on the child does not stop a different parent from embedding that child. Similarly, default-src 'none' does not supply a fallback for frame-ancestors. These directives control different directions of the relationship and should not be substituted merely because their names contain “frame.”

Frame-ancestors is not supported through a CSP meta element; deliver it as a response header. For nested embedding, every ancestor must match the policy, not just the immediate parent. A widget legitimately allowed inside one application can still be blocked when that application itself appears inside an unapproved outer frame. Review the complete intended embedding chain before choosing an allowlist.

When it breaks

A deployment may add the policy to the container page while leaving the sensitive child response unrestricted. Another may put it in HTML metadata and see a reassuring configuration string that the browser does not enforce. Verify the response actually being framed and test browser rendering. An HTTP 200 alone proves neither successful embedding nor the absence of frame protections: browsers can receive a document and refuse to display it in that context.

Conflicting headers can also mislead reviewers. In modern supporting browsers, an enforced frame-ancestors directive takes precedence over X-Frame-Options for that response. Pairing a permissive ancestor policy with X-Frame-Options: DENY does not necessarily produce the stricter result someone expects. Keep any deliberately retained header policy consistent with the intended audience and browser support, rather than assuming every restriction combines the same way as multiple CSP policies.

Check it quickly

Save this as frame-policy.py, run python3 frame-policy.py --serve, and open the printed parent URL. Python 3.14.4 and Chrome 152 were used. The parent and child servers occupy different loopback ports. Six child responses contain only synthetic text and a message indicating successful rendering. The parent accepts messages from the expected child origin and displays them. Control-C closes both temporary servers.

import json
import sys
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Event, Thread
from urllib.request import urlopen

paths = ["open", "csp-block", "xfo-block", "csp-allow", "meta", "frame-src"]
requests = []


class Child(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def do_GET(self):
 name = self.path.lstrip("/")
 assert name in paths
 requests.append(name)
 meta = ('<meta http-equiv="Content-Security-Policy" content="frame-ancestors \'none\'">'
 if name == "meta" else "")
 body = ("<!doctype html><meta charset=utf-8>" + meta + "<p>Rendered: " + name + "</p>"
 "<script>parent.postMessage({frame:" + json.dumps(name) + "}," + json.dumps(app_origin) + ");</script>").encode()
 self.send_response(200)
 self.send_header("Content-Type", "text/html; charset=utf-8")
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Cache-Control", "no-store")
 if name == "csp-block":
 self.send_header("Content-Security-Policy", "frame-ancestors 'none'")
 elif name == "xfo-block":
 self.send_header("X-Frame-Options", "DENY")
 elif name == "csp-allow":
 self.send_header("Content-Security-Policy", "frame-ancestors " + app_origin)
 self.send_header("X-Frame-Options", "DENY")
 elif name == "frame-src":
 self.send_header("Content-Security-Policy", "frame-src 'none'")
 self.end_headers()
 self.wfile.write(body)


class Parent(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def do_GET(self):
 if self.path == "/events":
 body = json.dumps(requests).encode()
 kind = "application/json"
 else:
 body = ("""<!doctype html><meta charset="utf-8"><title>Frame policy lab</title>
<h1>Which child responses can this parent embed?</h1><pre id="result">Waiting for frame messages...</pre>
<button id="check">Show server requests</button><div id="frames"></div><script>
const child=""" + json.dumps(child_origin) + ";const names=" + json.dumps(paths) + """;
window.received=[];
window.snapshot=async()=>{
 const result={rendered:[...window.received].sort(),serverRequests:await (await fetch('/events')).json()};
 document.getElementById('result').textContent=JSON.stringify(result,null,2);return result;
};
addEventListener('message',event=>{
 if(event.origin===child && names.includes(event.data?.frame)) {
 window.received.push(event.data.frame);
 document.getElementById('result').textContent=JSON.stringify(window.received,null,2);
 }
});
document.getElementById('check').onclick=()=>window.snapshot();
for(const name of names) {
 const frame=document.createElement('iframe');frame.src=child+'/'+name;frame.title=name;
 frame.width=240;frame.height=100;document.getElementById('frames').append(frame);
}
</script>""").encode()
 kind = "text/html; charset=utf-8"
 self.send_response(200)
 self.send_header("Content-Type", kind)
 self.send_header("Content-Length", str(len(body)))
 self.end_headers()
 self.wfile.write(body)


child = HTTPServer(("127.0.0.1", 0), Child)
app = HTTPServer(("127.0.0.1", 0), Parent)
child_origin = f"http://127.0.0.1:{child.server_port}"
app_origin = f"http://127.0.0.1:{app.server_port}"
threads = [Thread(target=server.serve_forever, daemon=True) for server in (child, app)]
for thread in threads:
 thread.start()
try:
 for name in paths:
 with urlopen(child_origin + "/" + name, timeout=5) as response:
 assert response.status == 200
 if name == "csp-allow":
 assert response.headers["Content-Security-Policy"] == "frame-ancestors " + app_origin
 assert response.headers["X-Frame-Options"] == "DENY"
 response.read()
 requests.clear()
 print(json.dumps({"app_url": app_origin, "child_origin": child_origin,
 "wire_responses": 6}), flush=True)
 if "--serve" in sys.argv:
 Event().wait()
except KeyboardInterrupt:
 pass
finally:
 for server in (child, app):
 server.shutdown()
 server.server_close()
 for thread in threads:
 thread.join(timeout=5)

The open child renders. csp-block is refused by frame-ancestors none, and xfo-block is refused by X-Frame-Options DENY. The csp-allow child renders because its enforcing ancestor policy explicitly permits the parent, even though it also sends DENY. The meta child renders because that delivery mechanism cannot enforce frame-ancestors, while frame-src renders because its restriction governs frames the child would load, not this parent-child relationship.

Expect four rendering messages and six server requests. Click “Show server requests” to inspect both; the browser check also records two response-blocking failures for the denied frames. The default Python probe separately receives all six HTTP 200 responses, illustrating why header inspection alone cannot replace rendering checks. This experiment tests a single embedding level in one browser, not an account-action workflow or every nested integration. Before shipping, exercise legitimate embedding paths and blocked parents through the actual proxy or CDN, and verify that the intended child responses retain their policy.

In the article’s single-level browser fixture, all six child responses return HTTP 200, but only open, csp-allow, meta, and frame-src render. The child’s enforcing ancestor policy permits the parent in csp-allow and takes precedence over X-Frame-Options DENY. Real nested integrations still need their own checks.

Sources

MDN CSP frame-ancestors, allowed embedding parents, ancestor checks, and unsupported meta delivery, checked 2026-09-13.
MDN CSP frame-src, control over frames loaded by the current document, checked 2026-09-13.
MDN X-Frame-Options, DENY and SAMEORIGIN framing restrictions, checked 2026-09-13.
W3C CSP Level 3, frame-ancestors enforcement and its relationship with X-Frame-Options, checked 2026-09-13.

XXE follows external references with the parser’s authority

Wed, 22 Sep 2027 00:00:00 +0000

XML external entity processing can make a parser resolve a document-controlled reference using the application’s access. Depending on the parser and its configuration, this can expose files or initiate requests to other services. XML support alone does not establish vulnerability: identify the actual parser, enabled features, resolver and downstream processing before deciding what an input can do.

External access and expansion are different

An external parsed entity can identify a resource through a system identifier. If the application enables resolution and the process can reach that resource, parsing may load it. Reflected content is one possible leak, but outbound requests can matter even when the response never includes the resource. Access is constrained by resolver policy, filesystem rights, network controls and the target service’s own authentication.

Internal entities can instead expand entirely within the document, without file or network access. Repeated nested expansion can consume excessive resources in an insufficiently protected parser. That is distinct from XXE. A bounded thousand-character expansion demonstrates substitution; it does not prove a modern parser permits unlimited amplification. Recursive self-reference is not valid XML, and supported implementations may reject amplification well before memory exhaustion.

Set policy before parsing

If the input format does not require DTDs, reject document-type declarations through the parser’s supported policy or callbacks. Also disable unwanted external general entities, parameter entities and external subsets as appropriate for that implementation. Defaults vary by library and version. Turning off network fetching alone can still leave local file access, while schema validation alone may happen after a dangerous parse has already occurred.

If external resources are required, resolve only explicitly approved identifiers to controlled resources. Review schema imports, XInclude and transforms independently: an XXE setting need not govern those other loaders. Apply byte, nesting and resource limits and keep the parser maintained. No tiny wrapper establishes general resistance to every malformed-input or decompression attack.

When it breaks

A filter that searches raw bytes for the ASCII spelling of DOCTYPE can miss an encoded declaration, such as UTF-16. A textual search can also reject harmless comments containing that spelling. Parse structure with a component that understands the input encoding, then enforce the policy at the declaration boundary. Rejecting one familiar attack string is not evidence that all supported encodings are covered.

An SVG image upload may pass through a server-side XML parser or converter. That stage’s configuration decides whether external references are loaded; being SVG does not mean every browser automatically fetches XML external entities. Check each reparse step, including preview generation and document import, because a safe first parser does not protect a later component that enables a different resolver.

The exact assertions-enabled Expat fixture supports bounded parser behavior. It does not establish external resource access, every handler or encoding, or a general security guarantee.

Check it quickly

Save this as xxe_probe.py and run python3 xxe_probe.py with a maintained Python 3 installation. Use assertions enabled, without -O or PYTHONOPTIMIZE: optimization skips the parameter-entity setting call and positive controls inside assert statements. The example uses Expat callbacks, fixed bytes and small limits. No resolver opens a file or makes a network request. The names inside rejected declarations are inert test inputs.

from xml.parsers import expat

MAX_BYTES = 4096
MAX_DEPTH = 32


def parse_without_dtd(data):
 """Bounded demonstration policy, not a general XML security library."""
 if not isinstance(data, bytes):
 raise TypeError("supply original encoded bytes")
 if len(data) > MAX_BYTES:
 raise ValueError("input too large")
 parser = expat.ParserCreate()
 text = []
 depth = 0

 def reject(*args):
 raise ValueError("DTD and entity declarations are disabled")

 def start(name, attrs):
 nonlocal depth
 depth += 1
 if depth > MAX_DEPTH:
 raise ValueError("too deeply nested")

 def end(name):
 nonlocal depth
 depth -= 1

 parser.StartDoctypeDeclHandler = reject
 parser.EntityDeclHandler = reject
 parser.ExternalEntityRefHandler = reject
 assert parser.SetParamEntityParsing(expat.XML_PARAM_ENTITY_PARSING_NEVER)
 parser.StartElementHandler = start
 parser.EndElementHandler = end
 parser.CharacterDataHandler = text.append
 parser.Parse(data, True)
 return "".join(text)


internal = ('<!DOCTYPE r [<!ENTITY a "0123456789">'
 '<!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;">'
 '<!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;">]><r>&c;</r>')
# A bounded baseline: ordinary internal expansion, not a resource-exhaustion test.
baseline = expat.ParserCreate()
chunks = []
baseline.CharacterDataHandler = chunks.append
baseline.Parse(internal.encode(), True)
assert len("".join(chunks)) == 1000
assert parse_without_dtd(b'<r>hello &amp; goodbye</r>') == 'hello & goodbye'
assert parse_without_dtd(b'<r><!-- literal <!DOCTYPE is only a comment -->ok</r>') == 'ok'
external = '<!DOCTYPE r [<!ENTITY e SYSTEM "file:///not-read-by-this-demo">]><r>&e;</r>'
network = '<!DOCTYPE r SYSTEM "https://example.invalid/never-requested"><r/>'
svg = '<!DOCTYPE svg [<!ENTITY e "text">]><svg>&e;</svg>'
rejected = []
for name, payload in [
 ("internal", internal.encode()), ("file", external.encode()),
 ("external-subset", network.encode()), ("svg", svg.encode()),
 ("utf16-dtd", external.encode("utf-16")),
 ("oversize", b'<r>' + b'x' * MAX_BYTES + b'</r>'),
 ("depth", b'<r>' * (MAX_DEPTH + 1) + b'</r>' * (MAX_DEPTH + 1)),
]:
 try:
 parse_without_dtd(payload)
 except ValueError:
 rejected.append(name)
 else:
 raise AssertionError(f"policy accepted {name}")
assert len(rejected) == 7
try:
 parse_without_dtd(b'<r>unfinished')
except expat.ExpatError:
 pass
else:
 raise AssertionError("malformed XML accepted")
print("Expat:", expat.EXPAT_VERSION)
print("PASS: ordinary text/comment accepted; seven policy cases and malformed XML rejected")

Separate exact EN/ZH runs and an independent rerun passed on Python 3.12.14 with Expat 2.8.3 and assertions enabled; this source reviewer did not execute them. The fixture prints its linked Expat version. A baseline expands the small internal entity chain to exactly 1,000 characters. The restricted parser accepts ordinary text with the predefined ampersand entity and accepts a harmless comment. It rejects internal declarations, a file entity, an external subset, an SVG DTD, and the same file declaration encoded as UTF-16.

Separate cases exceed the 4,096-byte policy and the depth limit of 32. Malformed XML must raise the parser’s syntax exception. These checks separate ValueError from parser syntax errors, but do not assert which policy branch raised it; the UTF-16 case confirms the policy acts after encoding recognition rather than relying on one ASCII pattern.

The DTD callback rejects first; the cases do not independently exercise every handler or encoding. This is a bounded parser exercise, not an exploit against a file, network target or upload service. It does not validate schema processing, transformations, downstream reparsing, compressed-request handling or production resource isolation. Repeat the policy tests through the actual application entry points and use a maintained hardened XML facility when handling hostile documents.

Sources

Python 3.12 Expat interface, declaration callbacks, parameter-entity policy and encoded input, checked 2026-10-15.
Python XML security, library/version-specific vulnerability boundaries, checked 2026-10-15.
OWASP XXE Prevention, parser-specific external-resource controls, checked 2026-10-15.
W3C XML 1.0, entities, document types and the prohibition on recursive references, checked 2026-10-15.
Python assert statement, optimized execution omits assert code, including expressions with side effects, checked 2026-10-18.

Client certificates authenticate control of a private key

Mon, 06 Sep 2027 00:00:00 +0000

Mutual TLS authenticates a client’s control of a certificate’s private key as well as the server’s identity. It does not inherently identify a physical device. A copied software key can be used elsewhere; hardware binding and device attestation require additional mechanisms. An enrollment policy can associate a key with a device, but TLS alone does not establish that association.

mTLS authenticates control of a private key. Application authorization follows the verified identity; valid credentials can still receive 403. Physical device identity and credential lifecycle need additional controls.

Authentication still needs authorization

During certificate-based TLS 1.3 client authentication, the server requests a certificate and the client proves control of the corresponding private key through CertificateVerify. Sending certificate bytes alone is insufficient. Both peers must apply their intended trust rules, including chain validity and appropriate certificate usage; the client must also verify the server’s name.

The server’s client-CA trust pool and the client’s server trust pool serve different directions. Trust only the intended issuers, and define which verified certificate field identifies a workload. A URI SAN can supply an application identifier, but the issuer’s enrollment rules determine who may receive it. A name in a certificate is not automatically permission to call every API.

Requiring a certificate is also different from merely requesting one. In Go, RequireAndVerifyClientCert requires a valid client certificate; optional modes can allow a connection without one. After authentication, apply authorization to the verified identity. A valid guest may deserve HTTP 403 rather than an authenticated reader’s HTTP 200.

When it breaks

A missing certificate, unknown issuer, expired credential, or inappropriate extended key usage can prevent client authentication. Changing the server policy to accept any certificate or disabling server verification conceals the boundary instead of repairing the credential. Separate handshake failures from application denials so that operators investigate the right layer.

Private keys need controlled storage, issuance, rotation, and incident response. Certificate renewal does not necessarily replace the key. A stolen usable key may support impersonation until acceptance is withdrawn; waiting for expiry is not the only response. Go’s certificate Verify does not perform revocation checking, so do not assume a published revocation is automatically enforced.

TLS termination also changes where identity is established. A backend receiving a caller-controlled identity header has not thereby verified the caller’s certificate. Any trusted identity propagation must have its own authenticated boundary and spoofing protections. Existing connections and resumed sessions additionally need explicit lifecycle policy when credentials or permissions change.

Check it quickly

Save this as mtls_probe.go and run go run mtls_probe.go with Go 1.23 or newer. It generates client CAs and credentials in memory, backdating notBefore by one minute and setting notAfter one hour ahead. The loopback server uses httptest’s test server certificate; the supplied test client trusts that certificate. Neither trust store is installed globally, and private keys are never printed or written.

package main

import (
 "crypto/ed25519"
 "crypto/rand"
 "crypto/tls"
 "crypto/x509"
 "crypto/x509/pkix"
 "errors"
 "fmt"
 "io"
 "log"
 "math/big"
 "net/http"
 "net/http/httptest"
 "net/url"
 "runtime"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func authority(serial int64) (*x509.Certificate, ed25519.PrivateKey) {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), Subject: pkix.Name{CommonName: fmt.Sprint("fixture-ca-", serial)},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 IsCA: true, BasicConstraintsValid: true, KeyUsage: x509.KeyUsageCertSign,
 }
 der, err := x509.CreateCertificate(rand.Reader, template, template, public, private)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return certificate, private
}

func credential(serial int64, identity string, usage x509.ExtKeyUsage, ca *x509.Certificate, signer ed25519.PrivateKey) tls.Certificate {
 public, private, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 name, err := url.Parse("urn:example:" + identity)
 must(err)
 now := time.Now()
 template := &x509.Certificate{
 SerialNumber: big.NewInt(serial), URIs: []*url.URL{name},
 NotBefore: now.Add(-time.Minute), NotAfter: now.Add(time.Hour),
 KeyUsage: x509.KeyUsageDigitalSignature, ExtKeyUsage: []x509.ExtKeyUsage{usage},
 }
 der, err := x509.CreateCertificate(rand.Reader, template, ca, public, signer)
 must(err)
 certificate, err := x509.ParseCertificate(der)
 must(err)
 return tls.Certificate{Certificate: [][]byte{der}, PrivateKey: private, Leaf: certificate}
}

func main() {
 ca, signer := authority(1)
 foreignCA, foreignSigner := authority(2)
 reader := credential(3, "reader", x509.ExtKeyUsageClientAuth, ca, signer)
 guest := credential(4, "guest", x509.ExtKeyUsageClientAuth, ca, signer)
 foreign := credential(5, "reader", x509.ExtKeyUsageClientAuth, foreignCA, foreignSigner)
 serverOnly := credential(6, "reader", x509.ExtKeyUsageServerAuth, ca, signer)
 roots := x509.NewCertPool()
 roots.AddCert(ca)
 options := x509.VerifyOptions{Roots: roots, KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth}}
 _, err := foreign.Leaf.Verify(options)
 var unknown x509.UnknownAuthorityError
 check(errors.As(err, &unknown), "foreign issuer fixture must fail trust")
 _, err = serverOnly.Leaf.Verify(options)
 var invalid x509.CertificateInvalidError
 check(errors.As(err, &invalid) && invalid.Reason == x509.IncompatibleUsage, "server-only fixture must fail client usage")

 var handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 check(len(r.TLS.VerifiedChains) > 0, "handler requires a verified client chain")
 identities := r.TLS.VerifiedChains[0][0].URIs
 if len(identities) != 1 || identities[0].String() != "urn:example:reader" {
 http.Error(w, "forbidden", http.StatusForbidden)
 return
 }
 fmt.Fprintln(w, "reader allowed")
 }))
 server.Config.ErrorLog = log.New(io.Discard, "", 0)
 server.TLS = &tls.Config{
 MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13,
 ClientAuth: tls.RequireAndVerifyClientCert, ClientCAs: roots, SessionTicketsDisabled: true,
 }
 server.StartTLS()
 defer server.Close()
 request := func(certificate *tls.Certificate) (int, error) {
 config := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 check(!config.InsecureSkipVerify, "server identity verification must remain enabled")
 config.MinVersion = tls.VersionTLS13
 if certificate != nil {
 config.GetClientCertificate = func(*tls.CertificateRequestInfo) (*tls.Certificate, error) {
 return certificate, nil
 }
 }
 transport := &http.Transport{TLSClientConfig: config, DisableKeepAlives: true}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 request, err := http.NewRequest(http.MethodGet, server.URL, nil)
 must(err)
 request.Header.Set("X-Client-ID", "urn:example:reader")
 response, err := client.Do(request)
 if err != nil {
 return 0, err
 }
 defer response.Body.Close()
 _, err = io.Copy(io.Discard, response.Body)
 must(err)
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "client requires a verified TLS 1.3 server")
 return response.StatusCode, nil
 }
 for _, test := range []struct {
 name string
 certificate *tls.Certificate
 status int
 }{
 {"reader", &reader, 200}, {"guest", &guest, 403},
 {"missing", nil, 0}, {"foreign issuer", &foreign, 0},
 {"wrong usage", &serverOnly, 0}, {"reader again", &reader, 200},
 } {
 status, err := request(test.certificate)
 if test.status == 0 {
 check(err != nil && status == 0, "invalid client must fail before HTTP")
 } else {
 must(err)
 check(status == test.status, "wrong authorization result")
 }
 fmt.Println(test.name, "HTTP status:", status)
 }
 check(handled.Load() == 3, "only reader, guest, and reader again may reach HTTP")
 fmt.Println("three TLS rejections; authenticated guest denied despite claimed reader header")
 fmt.Println(runtime.Version())
}

The reader returns 200; a guest signed by the same trusted CA returns 403 despite claiming the reader identity in X-Client-ID. Authorization reads the verified certificate’s exact URI SAN, not that header. The fixture’s URNs are application labels, not network addresses, and only urn:example:reader is authorized.

Missing credentials, a foreign issuer, and server-only extended key usage each fail before HTTP. The zero printed for them is an internal no-response marker, not an HTTP status code. Separate X.509 checks confirm UnknownAuthorityError and IncompatibleUsage for the two invalid certificate fixtures. The final reader succeeds again, and exactly three requests reach the handler.

The callback deliberately offers each supplied client credential, including the foreign one, rather than silently selecting no certificate from the server’s advertised CA preferences. This exercises the server rejection path. Production selection should respect the certificate request. Each request uses a fresh transport with a two-second timeout; connection reuse and session tickets are disabled.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. This tests actual mutual TLS plus one explicit authorization rule, not hardware-backed identity or a production PKI. It does not test revocation delivery, automated renewal, expired clients during a handshake, resumed sessions, reverse-proxy identity forwarding, or authorization changes on existing connections. Those remain separate deployment checks.

Sources

RFC 8446: TLS 1.3, certificate requests and proof of private-key control, checked 2026-09-09.
Go crypto/tls, client-authentication modes, trust pools, and certificate selection, checked 2026-09-09.
Go crypto/x509, client-authentication usage, verified chains, and revocation limitations, checked 2026-09-09.
Go net/http/httptest, isolated TLS servers and trusted test clients, checked 2026-09-09.

SSRF makes the server open the door

Sun, 05 Sep 2027 00:00:00 +0000

Server-side request forgery makes a server issue a request selected or influenced by an attacker. A thumbnail service, importer, webhook tester, or document renderer may reach destinations that the requesting user cannot reach directly. The server contributes its network position and whatever credentials that particular fetch path actually attaches. A URL fetch does not automatically inherit every account credential available to the process.

Identify the authority being delegated

Internal services, loopback administration endpoints, and cloud metadata services are important targets when reachable. The consequence depends on authentication, response visibility, allowed methods, and network policy. Blind SSRF can still trigger actions or reveal timing without returning the target’s response. Do not rank severity from the feature’s name alone; identify what it can contact and what that contact can accomplish.

On EC2, instance-role credentials can be available through metadata when a role is attached and the relevant access is permitted. The role-name listing and the role-specific credential document are separate requests. Those temporary credentials represent that role’s permissions, not unlimited AWS access or necessarily the credentials used by every application on the instance.

IMDSv2 requires a token obtained through a PUT request and supplied in subsequent metadata requests. Requiring it blocks a simple unauthenticated GET-only path, but does not solve arbitrary SSRF that can perform the necessary methods and headers. Pair metadata configuration with least-privilege roles and effective network restrictions. Metadata can have IPv4 and, when enabled and supported, IPv6 reachability; review both.

Parse, resolve, and preserve the checked destination

An allowlist should describe the feature’s intended destinations. When possible, accept a resource identifier rather than an arbitrary URL. Otherwise constrain schemes, hosts, and ports with a parser whose interpretation matches the HTTP client. Reject unsupported userinfo and ambiguous syntax rather than approving a URL merely because an allowed name appears somewhere inside it.

For example, trusted.example before an at-sign is userinfo, not proof that the destination host is trusted. Legacy numeric IPv4 forms may be interpreted differently by different URL parsers and resolvers. IPv6 loopback is ::1, not 127.0.0.1. A string check for one spelling is therefore insufficient, and one runtime’s parsing result is not a portable guarantee about another client’s behavior.

Resolve allowed names and evaluate all returned addresses against the intended network policy. For a public-only fetcher, reject loopback, private, link-local, multicast, and other disallowed ranges. Address libraries and registries evolve, so test the versions actually deployed. A destination being globally routable does not itself make it an authorized or benign service.

When it breaks

Checking DNS and then allowing the client to resolve again leaves a time-of-check gap. Pin the validated connection address using a supported transport mechanism while preserving the intended TLS hostname, certificate verification, and HTTP authority. A proxy may resolve independently; validate the actual egress path, retries and fallback connections rather than assuming one local preflight controls them.

Redirects create new destinations. Disable them unless needed, or validate each hop before following it, including resolution and address selection. A previously approved hostname cannot authorize an arbitrary Location target. Egress rules provide a separate containment layer; they should match the workload’s required services and cover relevant address families.

A 200 response does not by itself prove SSRF, and a 4xx response does not prove that no forbidden request occurred. Applications can wrap errors, return cached data, or reject after making contact. Confirm the request against a controlled observation endpoint and distinguish response handling from actual network activity. Never probe real metadata credentials merely to make an example convincing.

Approved data is not proof of actual transport. Match policy to the real fetch path, including resolution, redirects, retries, proxies and TLS identity.

Check it quickly

Save as ssrf_policy.py and run python3 ssrf_policy.py. This deliberately narrow offline policy uses supplied address snapshots instead of DNS. The public address is only an input value; the script never contacts it. All decisions happen in memory, without credentials, sockets, metadata calls, or changes to network controls.

import ipaddress
from urllib.parse import urlsplit

ALLOWED = {'cdn.example.test'}


def approve(url, addresses):
 # Deliberately narrow input language for this offline model.
 if any(ord(c) <= 32 or ord(c) >= 127 for c in url) or '\\' in url:
 raise ValueError('unsupported URL characters')
 parts = urlsplit(url)
 if parts.scheme != 'https' or parts.hostname not in ALLOWED:
 raise ValueError('scheme or host denied')
 if parts.username is not None or parts.password is not None or parts.fragment:
 raise ValueError('userinfo or fragment denied')
 if parts.port not in (None, 443):
 raise ValueError('port denied')
 if not addresses:
 raise ValueError('empty resolution')
 checked = []
 for text in addresses:
 address = ipaddress.ip_address(text)
 if '%' in text or address.is_multicast or not address.is_global:
 raise ValueError('non-public address denied')
 checked.append(str(address))
 return parts.hostname, tuple(checked)


def rejected(label, url, addresses):
 try:
 approve(url, addresses)
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


url = 'https://cdn.example.test/logo.png'
# Address values only. There is no DNS lookup, socket, or HTTP request.
public_snapshot = ['8.8.8.8']
name, pinned = approve(url, public_snapshot)
rejected('userinfo on allowed host', 'https://attacker@cdn.example.test/logo.png', public_snapshot)
rejected('userinfo host confusion', 'https://cdn.example.test@169.254.169.254/', public_snapshot)
rejected('decimal host', 'https://2130706433/', ['127.0.0.1'])
rejected('loopback IPv6', 'https://[::1]/', ['::1'])
rejected('link-local answer', url, ['169.254.169.254'])
rejected('mixed answers', url, ['8.8.8.8', '127.0.0.1'])
rejected('multicast answer', url, ['224.0.0.1'])
rejected('redirect destination', 'https://internal.example.test/', ['10.0.0.1'])
rejected('changed DNS answer', url, ['127.0.0.1'])
if pinned != ('8.8.8.8',) or name != 'cdn.example.test':
 raise RuntimeError('approved snapshot changed')
print('PASS: public fixture accepted; nine denied cases; approved address snapshot retained')

Expect nine rejected cases and PASS. The allowed synthetic hostname with one public address establishes a positive path. Userinfo on an allowed host, userinfo host confusion, numeric and IPv6 destinations outside the allowlist, link-local and mixed answers, multicast, a redirected hostname, and a changed DNS answer fail. The approved tuple remains unchanged. Numeric and IPv6 URLs fail the host allowlist first, so these cases do not independently test IPv6 address classification. No example ran in this source review.

This tests decisions and retained data, not a production fetch implementation. It does not exercise DNS, transport pinning, proxies, TLS, redirect execution, or response limits. Passing it cannot establish that an HTTP library connects to the approved address. Integration tests must verify that wiring, including timeouts and resource limits, using isolated destinations with synthetic responses.

Sources

OWASP: SSRF Prevention Cheat Sheet, intended destinations, address validation, and redirects, checked 2026-10-15.
AWS: Instance Metadata Service, IMDSv2 token requests and endpoint behavior, checked 2026-10-15.
RFC 3986: URI Generic Syntax, authority, userinfo, and host syntax, checked 2026-10-15.
Python: ipaddress, address classification and version changes, checked 2026-10-15.

CSRF asks the browser where the request came from

Sat, 04 Sep 2027 00:00:00 +0000

Browsers can attach session cookies to attacker-triggered requests. CSRF defenses distinguish authorized request contexts; they do not prove that a person saw or intended an action.

This shows the article’s server fixture, not a browser test. SameSite reduces cookie delivery; trusted request context does not prove human intent. XSS and authentication require separate defenses.

Cookies travel without asking

Browsers attach cookies to a request according to domain, path, Secure, SameSite, and other browser rules, not on whether the page causing the request was the user’s earlier intent. That means a page on an attacker’s origin can make the victim’s browser send a state-changing request — a transfer, a password change — that carries the authenticated session cookie, and the server sees a request that looks like it came from the legitimate user. This is why a request’s mere presence of credentials is not evidence of the user’s intent; the browser is following the cookie rules, not the user’s choice.

A token ties the action to a page

The defense is to bind each state-changing request to a value that the attacking page cannot know. The server embeds an unpredictable per-session anti-CSRF token in its own forms and reads it back on submit; the attacker’s cross-site page, lacking the token, fails the check. Pair the token property with strict methods (don’t let GET perform a state change) so tokenized requests are the only way to mutate state. It still must be compared server-side — refusing when missing or mismatched — and never accepted from an attacker-supplied origin.

SameSite adds a browser-side guard

SameSite=Strict withholds the cookie on cross-site requests; explicit Lax also permits it on top-level navigations using safe methods. These restrictions reduce cookie delivery but do not replace the token check in this design. Same-site is broader than same-origin, and browser support and request context matter. The example uses a server-stored synchronizer token, not a double-submit cookie. Cross-site scripting can defeat these defenses by acting inside the trusted origin.

Read Origin as a source signal

Check Origin when present; otherwise a server can inspect the origin portion of Referer. These fields may be absent, and Origin can be null. This fixture deliberately rejects requests without a trusted source signal as well as a valid token. Compare the complete allowed origin, including scheme, host, and port, rather than a hostname prefix. Sec-Fetch-Site adds browser context but reports sites, not an exact origin. Non-browser clients can forge these headers; origin checks address browser request forgery, not user authentication or proof of human intent.

When it breaks

Four failures show up repeatedly. First, a state change behind GET: an <img> or link can trigger it, and SameSite=Lax still sends cookies on top-level GET navigation, so the forged navigation arrives authenticated. Second, intentional cross-site cookies: SameSite=None; Secure permits that delivery, so another CSRF defense must protect mutations. Modern browsers reject None without Secure; legacy behavior is not a safe fallback. Third, a token check that accepts absence: the handler verifies the value only when present, skips verification for API paths, or reads the token from the query string where it leaks through Referer and logs. Fourth, subdomain trust: Lax and Strict compare sites not origins, so evil-sub.example.com shares the site, and a subdomain able to plant parent-domain cookies can attack naive double-submit schemes or session handling. Prefer host-scoped session cookies and reject ambiguous duplicates. Credentials alone never establish request legitimacy.

Check it quickly

Save the following as csrf_probe.py and run python3 csrf_probe.py. It models the server gate with only the standard library: the method must be POST, the token must match the session value, and the origin signal must agree. No network or browser is involved, so its cases run without a browser. The fixed token is test data; a real application must generate an unpredictable token bound to the session.

from hmac import compare_digest
from urllib.parse import urlsplit
import sys

EXPECTED_ORIGIN = "https://bank.example"
SESSION_TOKEN = "token-issued-with-own-form"

def decide(method, origin, referer, token):
 """Mimic a CSRF gate: POST-only mutation plus token plus origin must agree."""
 if method != "POST":
 return 405, "state change requires POST"
 if not isinstance(token, str) or not token.isascii() or not compare_digest(token, SESSION_TOKEN):
 return 403, "missing or wrong token"
 if origin:
 if origin != EXPECTED_ORIGIN:
 return 403, "origin mismatch"
 elif referer:
 base = urlsplit(EXPECTED_ORIGIN)
 try:
 seen = urlsplit(referer)
 except ValueError:
 return 403, "referer mismatch"
 if seen.scheme != base.scheme or seen.netloc != base.netloc:
 return 403, "referer mismatch"
 else:
 return 403, "no origin signal"
 return 200, "transfer accepted"

def check(actual, expected, label):
 assert actual == expected, f"{label}: got {actual}, want {expected}"
 print(f"{label}: {actual[0]} {actual[1]}")

check(decide("POST", EXPECTED_ORIGIN, "", SESSION_TOKEN),
 (200, "transfer accepted"), "legitimate form post")
check(decide("POST", "https://evil.example", "", SESSION_TOKEN),
 (403, "origin mismatch"), "forged cross-site post")
check(decide("POST", EXPECTED_ORIGIN, "", ""),
 (403, "missing or wrong token"), "missing token")
check(decide("POST", "", "https://bank.example/transfer", SESSION_TOKEN),
 (200, "transfer accepted"), "referer fallback navigation")
check(decide("GET", EXPECTED_ORIGIN, "", SESSION_TOKEN),
 (405, "state change requires POST"), "state change over GET")

check(decide("POST", "", "", SESSION_TOKEN),
 (403, "no origin signal"), "missing origin signal")
check(decide("POST", "https://evil.bank.example", "", SESSION_TOKEN),
 (403, "origin mismatch"), "same-site subdomain")
check(decide("POST", EXPECTED_ORIGIN, "", "令牌"),
 (403, "missing or wrong token"), "non-ASCII token")
check(decide("POST", "", "https://[", SESSION_TOKEN),
 (403, "referer mismatch"), "malformed referer")

print("PASS: legitimate, forged, and missing-token cases behave differently")
print(sys.version)

The legitimate POST with the correct origin and token returns 200, the cross-site origin returns 403 even with a valid token, and the missing token returns 403 even with a correct origin. The Referer fallback accepts a same-origin source and the GET case returns 405, which shows why safe methods matter. Expected output ends with PASS: legitimate, forged, and missing-token cases behave differently plus the Python version.

Additional cases reject missing source headers, a same-site subdomain, a non-ASCII token, and a malformed fallback URL. This checks decision logic, not browser cookie handling, TLS, or session generation. Its literal comparisons intentionally omit URL normalization; equivalent explicit default ports can be rejected. Re-test actual routes with synthetic accounts in an isolated browser setup.

Sources

MDN: Cross-site request forgery (CSRF), attack shape, token and SameSite defenses, checked 2026-10-19.
OWASP: Cross-Site Request Forgery Prevention Cheat Sheet, token and SameSite guidance, checked 2026-10-19.
RFC 6265: HTTP State Management Mechanism, baseline cookie scoping; this RFC does not define SameSite, checked 2026-10-19.

Kubernetes Secrets require explicit access boundaries

Sat, 21 Aug 2027 00:00:00 +0000

A Kubernetes Secret is an API object for confidential values that workloads need. It gives operators a dedicated object type, consumption paths, and access-control targets. It does not make data unreadable to every other actor. Design the boundary around who can retrieve the object, create consumers, inspect their output, and administer the nodes that run them.

A Secret’s boundary includes both direct readers and actors who can create consumers. A narrow projection limits one delivery, not necessarily its author. Rotation also needs delivery, reload and issuer verification. Conceptual diagram; no new cluster test.

Encoding and protection are different layers

In the JSON API representation, Secret data values use base64; stringData is a write convenience for supplying strings. Base64 can be reversed without a key and is not encryption. The representation does not prove how a particular cluster protects its backing storage. Kubernetes documentation describes Secrets as unencrypted at rest by default unless encryption is configured. Verify the actual API-server and storage setup rather than inferring it from encoded output.

Storage encryption also does not prevent an authorized API reader from obtaining the data. RBAC rules for get, list, and watch can expose Secret contents, so a broad listing permission is not merely access to object names. Protect backups and diagnostic output too. A working application eventually receives usable values, which means a compromised authorized consumer remains inside the data’s trust boundary.

Secrets are intended for small values. Kubernetes v1.34.0 limits the sum of decoded data values to one MiB; that check does not count the base64 representation or metadata. Separate request and metadata limits still apply. Mount only required keys and restrict access to the relevant containers. Unix file modes can narrow access within a workload, but do not replace API authorization or control of workload creation. Environment injection also has an exposure and lifecycle tradeoff; choose it from the application’s needs rather than assuming it is automatically safer than a file.

When it breaks

Denying get on Secrets does not necessarily deny indirect access. A subject allowed to create Pods in a namespace can normally name a Secret for a volume in its Pod specification. Kubelet then supplies the data to that workload. Permissions to create suitable controllers can have similar consequences. Review workload-creation rights and applicable admission controls alongside direct data-reading rules.

Broadly mounting every key expands the set of values a process can read. Selecting one key through volume items limits that particular projection, but a privileged creator may be able to request a different projection. Do not mistake a narrow manifest for proof that the actor writing it has equally narrow authority. The intended consumer and the authority to define consumers are separate parts of the boundary.

Rotation requires more than editing an API object. Delivery, application reload, credential issuance, and revocation have their own timing. Environment snapshots and subPath mounts do not automatically refresh like a normal Secret projection. An updated file also does not force an application to discard a value it already cached. Test the issuing system and consumers together before claiming that old credentials are no longer accepted.

Check it quickly

The fixture and observations below are retained from the original article. This review did not rerun the Kubernetes integration; reported success is historical, not a new execution result.

Use a disposable Kubernetes cluster with administrator access for test impersonation and python:3.11-slim-bookworm available on its nodes. Save this as secret-access.py and run python3 secret-access.py KUBECONFIG_PATH CONTEXT against its dedicated configuration. Kubernetes 1.34.11 was used for the recorded run. Every value in this fixture is deliberately synthetic, and output reports checks without printing the stored value.

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

import base64
namespace = 'notes-secrets-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 demo = 'DEMO_ONLY_NOT_A_CREDENTIAL'
 k('create', '-n', namespace, '-f', '-', payload={'apiVersion': 'v1', 'kind': 'Secret', 'metadata': {'name': 'example'},
 'type': 'Opaque', 'stringData': {'needed': demo, 'unused': 'UNUSED_DEMO'}})
 stored = obj(namespace, 'secret', 'example')
 assert base64.b64decode(stored['data']['needed']).decode() == demo
 apply(namespace, {'apiVersion': 'v1', 'kind': 'ServiceAccount', 'metadata': {'name': 'creator'},
 'automountServiceAccountToken': False})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'Role',
 'metadata': {'name': 'pod-creator'},
 'rules': [{'apiGroups': [''], 'resources': ['pods'], 'verbs': ['create', 'get']},
 {'apiGroups': [''], 'resources': ['pods/log'], 'verbs': ['get']}]})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'RoleBinding',
 'metadata': {'name': 'pod-creator'},
 'subjects': [{'kind': 'ServiceAccount', 'name': 'creator', 'namespace': namespace}],
 'roleRef': {'apiGroup': 'rbac.authorization.k8s.io', 'kind': 'Role', 'name': 'pod-creator'}})
 identity = 'system:serviceaccount:' + namespace + ':creator'
 denied = k('--as', identity, 'get', 'secret', 'example', '-n', namespace, expected=None)
 assert denied.returncode != 0 and 'Forbidden' in denied.stderr
 probe = "from pathlib import Path\nimport json,time\nroot=Path('/example')\nprint(json.dumps({'synthetic_value_matches':(root/'one').read_text()=='DEMO_ONLY_NOT_A_CREDENTIAL',\n 'unused_key_absent':not (root/'unused').exists(),\n 'service_account_token_absent':not Path('/var/run/secrets/kubernetes.io/serviceaccount/token').exists()}),flush=True)\ntime.sleep(600)"
 podspec = spec(probe)
 podspec['serviceAccountName'] = 'creator'
 podspec['volumes'] = [{'name': 'example', 'secret': {'secretName': 'example',
 'items': [{'key': 'needed', 'path': 'one'}], 'defaultMode': 0o400}}]
 podspec['containers'][0]['volumeMounts'] = [{'name': 'example', 'mountPath': '/example', 'readOnly': True}]
 definition = {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'reader', 'namespace': namespace},
 'spec': podspec}
 k('--as', identity, 'create', '-f', '-', payload=definition)
 wait_for(lambda: obj(namespace, 'pod', 'reader'), pod_ready)
 output = wait_for(lambda: k('--as', identity, 'logs', '-n', namespace, 'reader').stdout.strip(), bool)
 observed = json.loads(output)
 assert all(observed.values())
 print(json.dumps({'api_base64_decodes_to_synthetic_value': True,
 'direct_secret_get_forbidden': True, 'same_identity_can_create_consuming_pod': True,
 'mount_observation': observed, 'etcd_encryption_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

The script creates a Secret with two dummy keys and confirms that its API base64 representation decodes to the supplied synthetic text. It binds a service account to a Role permitting Pod creation and inspection of Pod logs, without permitting Secret reads. A request impersonating that account to get the Secret returns Forbidden.

The same impersonated subject then creates a Pod that mounts only the needed key. Its own program verifies the expected dummy value, absence of the unused key, and absence of an automatically mounted service-account token. The subject can read those boolean results through its permitted log access. The original article reports that all checks passed, demonstrating the indirect workload path despite the direct denial.

The namespace is removed afterward. No real credential, issued service-account token, backing-store encryption, or rotation process was tested. The experiment establishes authorization and projection behavior, not a complete secret-management system. Assess both direct readers and actors who can create or alter readers before describing a Secret as narrowly scoped.

Sources

Kubernetes: Secrets, API representation, consumption and access implications, checked 2026-10-15.
Kubernetes: Good practices for Secrets, encryption, least privilege and workload access, checked 2026-10-15.
Kubernetes: RBAC authorization, resource verbs, role bindings and namespace scope, checked 2026-10-15.
Secret validation (v1.34.0), ValidateSecret sums decoded data-value bytes before comparing MaxSecretSize, checked 2026-10-18.

Security · XB Field Notes

Forwarding an SSH agent

The remote gets a capability

Forwarding follows effective configuration

Limit the delegation

When it breaks

Check it quickly

Sources

OCSP stapling delivers status evidence under a client policy

Deliver evidence without transferring trust

Check support before enabling anything

When it breaks

Check it quickly

Sources

Security context defines constraints that need runtime evidence

Put each setting at the right scope

When it breaks

Check it quickly

Sources

Certificate transparency makes issuance observable

A promise is not an inclusion proof

When it breaks

Check it quickly

Further reading

Sources

SYN cookies answer when the queue overflows

Two queues, two different symptoms

The cookie is the state you refused to store

What a cookie cannot carry

When it breaks

Check it quickly

Sources

The forward-secrecy boundary of TLS ECDHE

Two kinds of keys do different jobs

When it breaks

Check it quickly

Further reading

Sources

Kernel entropy turns device noise into keys

Separate collection from output

Choose an initialization-aware interface

When it breaks

Check it quickly

Investigate identity reuse with direct evidence

Sources

Image signatures bind a digest to a trusted signer

Digests are the identity, tags are pointers

A tag string does not bind image content

Verification is the control, not the signature

When it breaks

Check it quickly

Sources

OAuth code flow trades a code for a token

Public clients can use code flow

Bind the exchange to the original request

When it breaks

Check it quickly

Further reading

Sources

Request smuggling desyncs the proxy chain

One stream, incompatible boundaries

Desynchronization has more than one impact

When it breaks

Check it quickly

Sources

JWTs carry a signature and a lifetime

Signed tokens are one JWT form

Validation is an application contract

When it breaks

Check it quickly

Further reading

Sources

Prepared statements separate values from SQL structure

When it breaks

Check it quickly

Inspect reuse in the real deployment

Sources

Setuid changes effective identity at exec

Distinguish the file bit from process credentials

Execution can suppress the transition