Security on Lessons learned

Offline login in an iOS or Android app: design it as offline unlock

Tue, 03 Nov 2026 18:00:00 +0100

A product request for “offline login” in a mobile app with a cache of sensitive data (customer invoices, HR records, patient notes, credentials) sounds like one feature. On a phone with no network, nothing can check the password against the server, apply MFA, or learn that the device was revoked yesterday. What the app can do is prove a local factor to a device that was enrolled earlier and release keys for ciphertext already on it:

offline login: authenticate the user, apply policy, authorize data (impossible offline)
offline unlock: prove a local factor, release keys for cached data (what you can build)

I researched how to build the second one on iOS and Android. This post collects the parts that are easy to get wrong: where the password path needs a hardware key, why a biometric prompt without a CryptoObject is only a boolean check, which clock keeps counting while the phone sleeps, and what changes for users who have no password at all. It is longer than a usual post here, because the traps sit in different layers.

What an offline unlock can and cannot prove

A connected sign-in lets the server authenticate the user and the device, require MFA, evaluate current policy and revocation, and send newly authorized data. An offline unlock does none of that. So it must never renew a server session, refresh authorization, or make cached data look current. Label the action “Unlock” in the UI and keep “Sign in” for the server. Show “Last checked” (policy) and “Last synchronized” (data) separately, because a recent local unlock is neither.

The trade-off between availability and revocation is unavoidable. While the device is disconnected, a revocation event cannot reach it, and plaintext it already showed cannot be recalled. A long offline window helps users during outages and travel. It also lets a lost or deauthorized device keep unlocking its cache until the window expires or the device reconnects. Pick a maximum offline age per threat model, make it visible, and apply revocation before any sync or key release at the next connection. Managed users should get an administrator-set finite limit. If you offer an unlimited consumer mode, tell the user that remote revocation and policy changes wait for the next reconnect.

First use of a device is always a connected sign-in. It enrolls the device, downloads the encrypted state, and creates the local unlock material. A device that was never provisioned online must never create offline capability, and a network error must never let you skip a required connected step.

A state machine where a stale device never prompts

Write the states down, so a missing transition shows up in review:

UNENROLLED
 └─ connected sign-in + MFA + policy + initial sync ─▶ LOCKED_CURRENT

LOCKED_CURRENT
 ├─ freshness valid, then valid local factor ────────▶ UNLOCKED
 ├─ successful check-in ─────────────────────────────▶ LOCKED_CURRENT (freshness renewed)
 ├─ freshness expires ───────────────────────────────▶ LOCKED_STALE
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

UNLOCKED
 ├─ timeout/background/device lock/manual lock ──────▶ LOCKED_CURRENT
 ├─ successful check-in ─────────────────────────────▶ UNLOCKED (freshness renewed)
 ├─ freshness expires ───────────────────────────────▶ LOCKED_STALE
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

LOCKED_STALE
 ├─ successful connected reauthentication/check-in ──▶ LOCKED_CURRENT
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

A check-in is any authenticated server call that returns current policy, revocation state, and server time. A background call with a refresh token is enough. If policy also wants full reauthentication with MFA after some maximum age, put that in the policy record, not in app logic.

Evaluate freshness before asking for a factor. A stale device shows the reconnect screen and never runs the password KDF, a PIN check, or a biometric prompt. When the window has expired, a biometric prompt that is bound to fail, followed by a generic “wrong password” error, tells the user nothing about the fix.

Losing one local factor does not change state. When a biometric wrapper is invalidated, or the PIN hits its threshold, delete that wrapper and continue with the others.

Wrap keys; never encrypt data with the password

Use envelope encryption:

Generate a random 256-bit account data key (ADK).
Generate a random key per record and per file and wrap each under the ADK. Do not derive them from the ADK. A derived key can always be derived again, so you cannot destroy or rotate it for one object without rotating the ADK.
Encrypt record fields, search indexes, file metadata, thumbnails, and file content with an AEAD: AES-256-GCM or ChaCha20-Poly1305.
Wrap the ADK once per unlock method: password, biometric, optional PIN, recovery key.
Encrypt the password and PIN wrappers a second time under a non-exportable hardware key that needs no user authentication: Secure Enclave on iOS, Android Keystore on Android.
Put version, algorithm, KDF parameters, key ID, account, object ID, field ID, and purpose into the authenticated data.

The field ID in step 6 looks like overkill until a field moves. If an attacker can swap the bank-account field of supplier record A with that of record B and the AEAD still verifies, the app shows a payment destination nobody entered for that supplier. In an autofill provider, the same swap between URL fields offers entry A’s password to site B.

A whole-database encryption layer can hide metadata and WAL contents. It does not replace per-field AEAD, because it usually protects only while the database is closed.

Why the password path needs the device too

The threat model that changes the design is the attacker with a copied sandbox or backup. Assume they hold the database, salts, KDF parameters, wrapped keys, and preferences. If the password wrapper is only KDF(password), they can run the KDF on GPUs, away from the device, for as long as they like.

Step 5 fixes that. With the wrapper sealed by a device key that never leaves the Secure Enclave or Keystore, every guess has to run on the original phone, at its speed. The KDF becomes the second barrier, not the only one. A secret stored in plaintext next to the copied files is not a second factor and does not count as one.

For the KDF itself:

Prefer Argon2id with a random salt and versioned parameters, benchmarked on the weakest supported device. It is not part of CryptoKit, CommonCrypto, or the standard Android crypto APIs, so it is a third-party dependency with its own review, pinning, and update process.
If you have to use PBKDF2, both platforms ship it: CCKeyDerivationPBKDF and SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"). Calibrate the iteration count on real devices instead of copying one from another project.
Store the parameters with the envelope and migrate them after a successful unlock.
Derive separate keys for local wrapping and for any protocol authentication, with domain separation.
On iOS, hold keys in CryptoKit SymmetricKey, which zeroes its storage on release, not in Data that the runtime may copy. A password captured as a Swift String cannot be wiped; turn it into bytes for the KDF right away.

KDF cost does not stop a patient person typing guesses into the unmodified app, so add an increasing delay and a persisted failure counter, and require a connected sign-in after a threshold.

A six-digit PIN is a million candidates

An app PIN is a convenience secret in front of the password. It unlocks its own envelope, and that envelope has to be bound to a non-exportable platform key. Six digits are 10^6 candidates. An unbound PIN envelope falls to offline search, whatever the KDF costs.

The rest of the PIN rules:

At least six digits; off by default for high-assurance or managed profiles.
Never store a PIN verifier that is cheaper to attack than the envelope.
A failure counter scoped to the user that survives process death and reboot, with increasing delay and at most 10 consecutive failures, the upper bound NIST SP 800-63B sets for activation secrets.
At the threshold, delete the PIN wrapper and ask for the password. Wiping the local data would destroy the only copy of anything not yet synced.

The catch: neither iOS nor Android enforces a retry limit in hardware for an app-defined PIN. NIST’s limit assumes the authenticator enforces it, and here the app does. The counter stops the user and a thief using the unmodified app. On a rooted or jailbroken device, an attacker can query the platform key directly at hardware speed, and only PIN length helps against that.

The biometric prompt must unlock a key

Biometric success has to authorize the cryptographic operation that unwraps the ADK. If it only flips an isAuthenticated flag, a hooked callback on a rooted device skips it.

Android: pass a `CryptoObject`

Generate the key inside Keystore and require authentication for every use:

val spec = KeyGenParameterSpec.Builder(
 "offline-data-wrap",
 KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT,
)
 .setKeySize(256)
 .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
 .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
 .setUserAuthenticationRequired(true)
 .setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG) // API 30+: every use prompts
 .setInvalidatedByBiometricEnrollment(true)
 .setUnlockedDeviceRequired(true) // API 28+
 .setIsStrongBoxBacked(true) // API 28+; on StrongBoxUnavailableException, retry in the TEE
 .build()

KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
 .apply { init(spec) }
 .generateKey()

Then hand the initialized cipher to BiometricPrompt, and decrypt only with the cipher you get back:

val cipher = Cipher.getInstance("AES/GCM/NoPadding")
try {
 cipher.init(Cipher.DECRYPT_MODE, wrappingKey, GCMParameterSpec(128, envelope.iv))
} catch (e: KeyPermanentlyInvalidatedException) {
 deleteBiometricWrapper() // enrolled biometrics changed: fall back to the password
 return
}

val prompt = BiometricPrompt(activity, executor, object : BiometricPrompt.AuthenticationCallback() {
 override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
 val unlocked = result.cryptoObject!!.cipher!!
 unlocked.updateAAD(envelope.aad)
 val adk = unlocked.doFinal(envelope.ciphertext)
 // ...
 }
})

prompt.authenticate(
 BiometricPrompt.PromptInfo.Builder()
 .setTitle("Unlock offline data")
 .setAllowedAuthenticators(BiometricManager.Authenticators.BIOMETRIC_STRONG)
 .setNegativeButtonText("Use password")
 .build(),
 BiometricPrompt.CryptoObject(cipher),
)

Set the accepted authenticators explicitly. A default that includes DEVICE_CREDENTIAL means the device PIN opens the offline data, and so does anyone who watched the owner type it. If you want that fallback, make it a written product decision. Since this is a symmetric key with authentication required, creating the wrapper at enrollment also needs a prompt; ask for the password first, as with any new factor.

iOS: a Secure Enclave key and ECIES

Generate the wrapping key in the Secure Enclave with biometric access control, and wrap the ADK with ECIES:

var error: Unmanaged<CFError>?
let access = SecAccessControlCreateWithFlags(
 nil,
 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, // the OS deletes it if the passcode is removed
 [.privateKeyUsage, .biometryCurrentSet], // no passcode fallback
 &error
)!

let attributes: [String: Any] = [
 kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,
 kSecAttrKeySizeInBits as String: 256,
 kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
 kSecPrivateKeyAttrs as String: [
 kSecAttrIsPermanent as String: true,
 kSecAttrApplicationTag as String: Data("offline-data-wrap".utf8),
 kSecAttrAccessControl as String: access,
 ],
]
let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error)!

let wrapped = SecKeyCreateEncryptedData(
 SecKeyCopyPublicKey(privateKey)!,
 .eciesEncryptionCofactorX963SHA256AESGCM,
 adk as CFData,
 &error
)

To unwrap, fetch the key with a fresh LAContext passed as kSecUseAuthenticationContext, with touchIDAuthenticationAllowableReuseDuration left at 0, and call SecKeyCreateDecryptedData. The prompt the user sees then authorizes this key use. That is the iOS counterpart of Android’s per-use authentication.

Two details to get right:

The accessibility class goes into SecAccessControlCreateWithFlags. It cannot be combined with a separate kSecAttrAccessible attribute on the same item.
.biometryCurrentSet invalidates the key when Face ID or Touch ID enrollment changes. Handle that by deleting the wrapper and requiring the password. A .devicePasscode or .userPresence fallback lets anyone who knows the device passcode into the offline data.

Data Protection classes that fail after lock

Set a Data Protection class per store instead of relying on container defaults. The complete class key is discarded about 10 seconds after the device locks, which bites in three places:

Plaintext temporaries should use complete.
Background downloads of offline files need completeUnlessOpen.
A SQLite database in WAL mode under complete fails when anything touches it after lock. Either stop database access on protectedDataWillBecomeUnavailable, or use completeUntilFirstUserAuthentication for the database and rely on field-level AEAD.

Files in tmp/ and elsewhere in the container default to completeUntilFirstUserAuthentication unless you set otherwise.

Offline expiry needs a clock that counts sleep

Enforcing maximum offline age with wall-clock time alone fails the moment someone sets the clock back. I covered that half in An offline cache TTL needs a clock-rollback policy . The research added three things.

The freshness record has two parts. A server-signed part (check-in time, policy version, expiry duration), verified with the server’s public key. A local part (wall time at check-in, monotonic time at check-in, boot reference, accumulated elapsed time), authenticated with a keystore device key. Do not protect it with the ADK: freshness is evaluated before accepting any factor, so the record must verify while the app is locked.

The monotonic clock must keep counting while the phone sleeps, because a phone is asleep most of the time:

Platform	Use	Stops during sleep
iOS	`mach_continuous_time()`, `clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW)`	`mach_absolute_time()`, `ProcessInfo.systemUptime`
Android	`SystemClock.elapsedRealtime()`	`SystemClock.uptimeMillis()`

Verify the chosen clock on a device by letting it sleep.

Reboots reset the monotonic clock. Android has Settings.Global.BOOT_COUNT. iOS has no documented boot identifier: kern.boottime moves when the user changes the wall clock, so it detects clock changes, not boots. On iOS, detect a reboot by a monotonic reading lower than the stored one. Then:

update accumulated elapsed time on every foreground, unlock, and lock

same boot: elapsed from the monotonic clock, cross-checked against wall time
after reboot: elapsed = max(accumulated + monotonic_since_boot,
 wall_now - wall_at_checkin)
wall_now < last stored wall time → rollback → stale

A rollback across a reboot can then hide at most the time between the last update and the reboot.

Fail closed on a missing, rolled-back, or inconsistent record, and exclude it from backup. A restore, to another device or to the same one, then leaves the record missing and forces a check-in. Otherwise, a same-device restore brings back an older valid record together with the ThisDeviceOnly Keychain items it belongs to.

These controls resist clock rollback, not state rollback. Nothing stops someone from replacing the current record with an older valid copy, and the expiry is application logic. Like the PIN counter, it binds the unmodified app, not an attacker running their own code against the device keys.

Documents: chunked AEAD and plaintext that outlives the app

Offline documents, such as invoice PDFs or scanned contracts, need more than per-record encryption. CryptoKit’s AES.GCM and ChaChaPoly seal a whole message in memory. Streaming playback and seeking viewers need chunks, and naive chunking lets an attacker truncate, reorder, or drop chunks without failing authentication. Use a format in the style of the STREAM construction:

fixed-size chunks (say 64 KiB), each sealed separately;
a nonce built from a random per-file prefix and the chunk index;
file ID, format version, chunk index, and a final-chunk flag in each chunk’s authenticated data;
an authenticated header with the prefix, chunk size and version;
a new per-file key or nonce prefix whenever the file changes, so no key and nonce pair is ever reused.

Prefer decrypting into memory or a pipe for an in-app viewer. QLPreviewController wants a file URL, so some formats force a plaintext file. When one is unavoidable, put it in a dedicated private directory under complete, with an unpredictable name, excluded from backup and indexing, shared only through a narrow, non-exported FileProvider grant on Android.

The trap is cleanup. A suspended iOS app runs no code, so no timer deletes the file on schedule, and cancellation, render errors, crashes, process death, and reboot all skip view-level cleanup. Make the launch path enumerate and delete expired temporaries before it allows an unlock.

Lock, logout, and Keychain items that survive uninstall

Lock keeps the encrypted state and destroys the usable keys: release the ADK and derived keys, close plaintext streams, blank the app-switcher snapshot, invalidate decrypted caches, and stop background jobs from quietly recreating an unlocked session. A suspended app cannot clear the clipboard later, so set the expiry when you copy:

UIPasteboard.general.setItems(
 [[UTType.utf8PlainText.identifier: secret]],
 options: [.localOnly: true, .expirationDate: Date().addingTimeInterval(60)]
)

.localOnly keeps it off Universal Clipboard. On Android, mark the clip with ClipDescription.EXTRA_IS_SENSITIVE (API 33+) and clear it with ClipboardManager.clearPrimaryClip().

Logout makes the state permanently unusable. Physical overwrite on flash is unreliable, so the primary boundary is cryptographic erasure: destroy every usable wrapping key, then delete tokens, databases with their WAL and journal files, indexes, cached files, temporaries, pending operations, and shared-container state.

On iOS, uninstalling the app deletes its container but leaves its Keychain items, and no app code runs during uninstall. Keep a marker file in the container. When it is missing at launch, delete every Keychain item the app owns, shared access groups included, before doing anything else. Otherwise, a reinstall can find the previous install’s wrappers.

Autofill is offline unlock under another name

If the cached data includes credentials and the app offers an autofill provider, that provider releases secrets from the local cache with no server call, so every rule above applies to it. The platforms constrain it differently.

On iOS, the Credential Provider extension is a separate process with its own unlock session. It sees the app’s state only through a shared Keychain access group and an App Group container, so every key and wrapper it needs, including the Secure Enclave device key and the freshness record, must live in the shared group. It runs under a memory limit Apple describes as only slightly lower than an app’s. That limit caps the Argon2id memory parameter, so benchmark inside the extension on the weakest device. Do not give the extension a cheaper copy of the password envelope: the weakest wrapper sets the strength of all the data it protects. If parameters that fit are too weak, let the extension offer biometrics only and send password users to the app.

An LAContext evaluated in the app does not carry over to the extension. Within one request, the extension can pass one evaluated context to several Keychain reads, so a single prompt covers a list. The system may reuse the extension process for the next request, so nothing decrypted may stay in a static.

On Android, the AutofillService runs in the app’s own process unless the manifest says otherwise. Its authentication activity still needs a CryptoObject, and it should accept the same authenticators as the app.

Rules for both:

Give the provider its own key that wraps only what a fill needs (username, password, URL), so a faulty extension cannot decrypt documents, notes, or indexes.
Share the failure counter between app and provider. Otherwise, an attacker doubles the allowed attempts by alternating between them.
The provider reads freshness and never checks it itself. When stale, it fills nothing and says which app to open.
On iOS, the identity store shows registered usernames next to their domains in the QuickType bar to anyone holding the unlocked phone, with the app locked. Replace the whole identity set after each sync instead of removing and re-adding the current ones, so deleted entries disappear, and consider a managed policy that registers none.

Verify who is asking

The requester check is where autofill phishing happens (Aonzo et al., Phishing Attacks on Modern Android, CCS 2018 ). iOS identifies websites and apps through associated domains. On Android, the provider has to do it:

Verify the requesting app’s signing certificate against the domain’s Digital Asset Links , not its package name. An app named com.examplebank.evil is not Example Bank.
Trust browsers by package name and certificate digest together. On a device without a listed browser, a sideloaded app can take that browser’s package name and report any web domain.
Derive registrable domains from the Public Suffix List , not a hand-written list of suffixes. Otherwise, an entry saved for victim.github.io collapses to github.io and fills in attacker.github.io.

Users without a password

Everything above assumes every user has a password. Users who sign in through enterprise SSO or a partner’s authenticator app do not. In this design, the password has five jobs:

the baseline wrapper of the ADK;
the fallback when a biometric wrapper is invalidated;
the authorization for a new biometric wrapper;
the replacement when the PIN hits its threshold;
the recent password entry that sensitive actions require.

Each job needs a new owner. The options I found:

Connected sign-in takes every fallback role. This one always applies. A user who loses their last local factor while offline has no offline access until they reconnect.
A mandatory app passcode becomes the baseline factor. Set it during connected provisioning and wrap the ADK with it like the password (KDF, then device key). Three PIN rules change. Six digits stop being enough, because nothing stands behind the passcode: at 0.5 seconds per guess on a compromised device, 10^6 candidates take under six days. Allow alphanumeric passcodes with a real minimum length. The threshold sends the user to connected sign-in, and choosing a new passcode needs one too. The user gets a second secret to remember; that is the price of an offline knowledge factor.
The device passcode can back up the biometric wrapper. It avoids losing offline access at the first biometric change and reopens the “watched the owner type it” risk. Make it explicit, let administrators forbid it, and check on a device whether iOS still releases a biometryCurrentSet or devicePasscode item through the passcode after enrollment changes.
A recovery key can have enough entropy that a copied wrapper is safe even without device binding. Users lose these, and nobody can reset one, so offer it only where a lost factor can cost data.

What does not work is anything the identity provider issued. A cached refresh token or ID token proves the device holds a token, not that the user is holding the device. Don’t wrap the ADK under it, and delete the identity provider’s token cache after the server exchange.

Check one thing in your own protocol. If the server opens a passwordless user’s data without any secret from the user, it can provision the ADK again at the next sign-in. A lost factor then costs offline access, not data, as long as offline records stay read-only. Unsynced offline edits are the exception, because they exist only on the device.

Decide the factor set at provisioning from the login method, and store it with the policy. If the same user later provisions through a password login, re-enroll; don’t bolt a password wrapper onto a passwordless enrollment.

Caveats

The ADK’s scope is a protocol decision. If the ADK only protects this device’s cache, logout and revocation destroy it. If it is the user’s end-to-end key shared with the server and other devices, a device revoked while offline keeps a copy that decrypts future data, and revoking it means rotating the key.
Offline edits are a separate project. Ship read-only offline records first. Editable mode needs an encrypted operation log separate from server-confirmed state, conflict rules that keep both versions when a merge could lose data, and an authorization recheck for each operation on reconnect.
On rooted and jailbroken devices, hardware-backed keys and integrity signals raise the cost. Retry counters and expiry are app logic and don’t bind an attacker who runs their own code against the keys. Don’t claim otherwise.

Test the failure paths

Happy-path testing says nothing about whether keys and plaintext stay contained. The release gates I would not skip:

Area	Test
Provisioning	A never-enrolled device fails offline; restoring a backup to another device, or an older backup to the same one, forces a check-in
Crypto	Copied password and PIN wrappers cannot be opened off the device; ciphertext swapped between records or between fields of one record fails authentication
Biometrics	Add and remove enrolled biometrics, change and remove the passcode, reboot, process death
Retries	Counters survive relaunch and reboot; the PIN threshold removes only the PIN wrapper
Freshness	Clock forward and back, time zone change, reboot, a long sleep counted toward expiry, a replayed older record, the exact boundary; a stale device never prompts
Documents	Truncated, reordered, and dropped chunks fail; kill the app mid-preview and confirm the temporary is gone before the next unlock
Deletion	Uninstall and reinstall leave no usable Keychain state; removing one user leaves another intact
Autofill origin	A look-alike package name gets no match; `victim.github.io` is not offered on `attacker.github.io`

OWASP MASVS and MASTG , NIST SP 800-63B , NIST SP 800-132 for PBKDF2, and RFC 9106 for Argon2id set the baseline. They don’t decide where your keys live or what happens when a preview crashes.

Takeaway

Offline, the app can only answer “is this the enrolled user, on the enrolled device, within the allowed window?” Every unlock path, including the password, should require the device’s hardware key; every biometric prompt should gate a key operation; and the window should be measured by a clock that keeps counting while the phone sleeps.

If your app already has an offline mode, copy its sandbox to another machine and try to open the password wrapper there. If that attempt gets as far as a KDF, the password path is missing its device key.

Backing up ~/.claude and ~/.codex without archiving your AI logins

Sat, 31 Oct 2026 22:29:00 +0100

If you back up the whole ~/.claude or ~/.codex folder, the restore works, and the backup now holds everything an infostealer wants. The same folder holds your settings, every session transcript in plaintext, and, on Linux, the login itself:

~/.claude/.credentials.json # Claude Code login, mode 0600
~/.codex/auth.json # Codex login when file storage is in use
~/.claude/projects/*/*.jsonl # transcripts: prompts, tool output, file contents

Split the folder into two lists. Back up what you wrote: settings, instructions, skills, hooks, and memory. Keep transcripts as optional encrypted data. Leave login files out of routine backups and log in again after a restore.

Where AI client state lives on macOS and Linux

I checked these paths against Claude Code 2.1.316, Claude Desktop for Linux 4.4212.0, ChatGPT for macOS 1.2026.183, the Codex desktop app for macOS 26.1027.30824, and Codex source at commit 67f0994. “Documented” means the vendor docs name the path. “Observed” means I found it by inspecting the official build so that it can change in any release.

Client	State root	Login material	Evidence
Claude Code	`~/.claude/` and `~/.claude.json`, both under `CLAUDE_CONFIG_DIR` if set	Keychain on macOS, or `~/.claude/.credentials.json` when the Keychain rejects the write (locked in an SSH session, for example). On Linux, always that file	Documented
Claude Desktop	macOS: `~/Library/Application Support/Claude/`. Linux (beta): `${XDG_CONFIG_HOME:-~/.config}/Claude/`	Electron cookies and Local Storage, extension secrets encrypted with `safeStorage`	MCP config documented, rest observed
ChatGPT desktop, macOS only	`~/Library/Application Support/com.openai.chat/`, `~/Library/Group Containers/2DC432GLL2.group.com.openai.chat/`, `~/Library/Preferences/com.openai.chat.plist`	Keychain items in OpenAI’s access group	Observed
Codex desktop, macOS only	`~/Library/Application Support/Codex/`, plus `~/.codex`	Shared with Codex CLI	Observed
Codex CLI	`${CODEX_HOME:-~/.codex}`. `CODEX_SQLITE_HOME`, `sqlite_home` and `log_dir` can move parts of it	`auth.json` in `file` mode or as the `auto` fallback; `.credentials.json` for MCP OAuth without a keyring	Documented and source

Desktop sessions that run Claude Code write to ~/.claude/, not to the Electron folder, so include both.

What to back up and what to leave out

Treatment	Claude Code	Codex
Back up, versioned	`settings.json`, `CLAUDE.md`, `rules/`, `skills/`, `commands/`, `agents/`, `workflows/`, `output-styles/`, `keybindings.json`, `projects/*/memory/`, `agent-memory/`, `plugins/installed_plugins.json` as a manifest	`config.toml`, `*.config.toml`, `hooks.json`, `rules/`, `skills/`, agent-role files
Back up after a secret check	`~/.claude.json` (personal MCP servers, trust decisions)	MCP `env` blocks in `config.toml`
Optional, encrypted, short retention	`projects//.jsonl`, `subagents/`, `tool-results/`, `history.jsonl`	`sessions/YYYY/MM/DD/rollout-*.jsonl`, `archived_sessions/`, `history.jsonl`
Exclude	`.credentials.json`, `file-history/`, `paste-cache/`, `debug/`, `shell-snapshots/`, `session-env/`, `backups/`	`auth.json`, `.credentials.json`, `log/`, `logs_2.sqlite`, `shell_snapshots/`, `packages/`, caches

For Claude Desktop, keep claude_desktop_config.json after checking its MCP env blocks, plus a list of installed extensions and where each came from. Reinstall extensions instead of restoring their executable caches. The ChatGPT app’s local databases are caches of a server-side account; use the account’s data export for conversations you want to keep.

Why copying the whole folder is the wrong default

Transcripts are plaintext. Anthropic’s docs say that anything passing through a tool is written to the session .jsonl, so a .env file a tool reads or a token a command prints is in there. Codex rollouts record tool activity the same way.

Your backup also keeps transcripts after the client has deleted them. Claude Code deletes transcripts after cleanupPeriodDays (default 30), but keeps sessions started, or last continued in Claude Desktop or Cowork at any age unless you set desktopSessionCleanupPeriodDays. A backup with a year of history still holds a transcript eleven months after the client deleted it.

A restore can also run code. Hooks, MCP server commands, skills, plugins, desktop extensions, and shell snapshots all execute something. If malware edited them, a full restore puts it back on the clean machine.

The Keychain protects less than it seems to. It stops someone who copies the disk offline, but malware running as your user can still request the item. The Linux desktop build can also fall back to Chromium’s basic password store when no wallet is running.

Dead ends worth skipping

Guessing Linux paths from macOS ones. Replacing Library/Application Support with .config works for Claude Desktop, which has a Linux beta. OpenAI ships no Linux desktop app for ChatGPT or Codex. The Codex source has Linux branches, but there is no supported Linux build. On Linux, your ChatGPT state lives in the browser profile.
Copying only the .sqlite files. Codex keeps state in state_5.sqlite, thread_history_1.sqlite, memories_1.sqlite and others . A live copy without the -wal and -shm sidecars can be incomplete or corrupt. Stop the client and copy all three.
Treating the desktop database as the archive. The Codex desktop app can rebuild its index from the rollout JSONL files, but metadata that lives only in the database is lost, back up the JSONL files.
Assuming claude purge cleaned everything. It doesn’t touch shell-snapshots/, backups/ (older copies of ~/.claude.json) or files written by /heapdump. According to Anthropic, a heap snapshot contains the full conversation and any credentials the process held.

Restore into a staging profile

Reinstall the signed apps, plugins, and extensions from their sources.
Restore your config, then read every hook, MCP command, and executable path before the first launch.
Restore transcripts or memory only if you need them.
Log in again. Don’t restore auth.json, .credentials.json, cookies, or Keychain exports.
Resume one session and confirm that it uses the right account and repository.

Verify the backup set

To list what exists and how large it is, without printing any contents, run this on the machine you back up:

for p in "${CLAUDE_CONFIG_DIR:-$HOME/.claude}" "$HOME/.claude.json" \
 "${CODEX_HOME:-$HOME/.codex}" \
 "${XDG_CONFIG_HOME:-$HOME/.config}/Claude" \
 "$HOME/Library/Application Support/Claude" \
 "$HOME/Library/Application Support/Codex" \
 "$HOME/Library/Application Support/com.openai.chat" \
 "$HOME/Library/Group Containers/2DC432GLL2.group.com.openai.chat"; do
 [ -e "$p" ] && du -sh "$p"
done

Then check that no login file ended up in the backup:

find /path/to/mounted/backup \( -name .credentials.json -o -name auth.json \) -print

It should print nothing. If it prints anything, that backup is a credential store: encrypt it, shorten its retention, or rotate the logins.

If malware may already have run

Don’t treat a restore as the cleanup. From a clean device, revoke your Claude and ChatGPT sessions, then rotate API keys, MCP and connector credentials, and any secret that appeared in a transcript or in tool output. Any backup the malware could reach counts as exposed. Rebuild the user profile, restore only config you have reviewed, and log in again.

Caveats

Paths and retention rules change between releases. The ChatGPT and desktop paths come from build inspection, not from a published schema, so check them against your installed versions before you write a backup job. Sources: the .claude directory reference , Claude Code credential management , Codex config and state locations , Codex credential storage , Claude Desktop MCP config paths , and Electron’s app.getPath() .

Back up the config you wrote, and leave out the files the app uses for login. Run the find check above against your latest backup tonight.

A latest-row query cannot tell you whether every device is current

Thu, 29 Oct 2026 00:00:00 +0000

A dashboard can label an account “current” while that account still has an outdated device. Selecting the latest event per account and application retains one observation; it discards observations from other devices. Describe that selection in the report before claiming that the source telemetry cannot distinguish devices.

The distinction matters during a security review: “latest observed state” and “any observed device needs attention” answer different questions. Correct arithmetic cannot repair a mislabeled metric.

Reproduce the lost device with synthetic data

Run this example with Python 3 and SQLite supporting window functions. The names, dates, and status values are synthetic; current is a supplied classification, not an implementation of version comparison.

import sqlite3

con = sqlite3.connect(":memory:")
con.executescript("""
CREATE TABLE observations (
 event_id INTEGER PRIMARY KEY,
 account TEXT, app TEXT, device TEXT,
 observed_at TEXT, current INTEGER
);
INSERT INTO observations VALUES
 (1, 'account-a', 'demo', 'laptop', '2026-01-01T09:00:00Z', 0),
 (2, 'account-a', 'demo', 'phone', '2026-01-01T10:00:00Z', 1),
 (3, 'account-b', 'demo', 'tablet', '2026-01-01T10:00:00Z', 0),
 (4, 'account-b', 'demo', 'tablet', '2026-01-02T10:00:00Z', 1);
""")

latest_account = """
WITH ranked AS (
 SELECT *, ROW_NUMBER() OVER (
 PARTITION BY account, app
 ORDER BY observed_at DESC, event_id DESC
 ) AS rn
 FROM observations
)
SELECT account, current FROM ranked WHERE rn = 1 ORDER BY account
"""

latest_devices = """
WITH ranked AS (
 SELECT *, ROW_NUMBER() OVER (
 PARTITION BY account, app, device
 ORDER BY observed_at DESC, event_id DESC
 ) AS rn
 FROM observations
)
SELECT account, MAX(CASE WHEN current = 0 THEN 1 ELSE 0 END)
FROM ranked WHERE rn = 1
GROUP BY account, app ORDER BY account
"""

account_rows = con.execute(latest_account).fetchall()
exposure_rows = con.execute(latest_devices).fetchall()
assert account_rows == [('account-a', 1), ('account-b', 1)]
assert exposure_rows == [('account-a', 1), ('account-b', 0)]
print("latest account state:", account_rows)
print("any latest-observed device outdated:", exposure_rows)

Both accounts have a current latest observation. Only account-a has an outdated device among its latest per-device observations. The laptop disappeared from the first query because the phone reported later.

The account-b rows are a negative control. Aggregating every historical outdated event would flag the tablet even after its newer current observation. Rank within each device first, then aggregate the surviving states.

State the measurement contract

An accurate table label might be:

Accounts classified by their latest observed event per application, with ties resolved by event ID.

That supports a claim about selected observations. It does not establish that every device on those accounts is current. Nor does the query establish what the ingestion system could identify before aggregation.

For an exposure report, define the device identity and observation window explicitly. A stable device key is a prerequisite for the second query. An installation identifier that rotates after reinstalling may represent installations rather than physical devices; a shared or missing identifier can merge unrelated observations. Inspect the schema and collection semantics before choosing the partition keys.

The example orders normalized UTC timestamps and breaks ties with a unique event ID. That makes the selection deterministic. It does not prove that a larger ID represents a later real-world event when timestamps tie. SQLite’s window-function documentation describes how ROW_NUMBER() follows the window’s ordering.

Keep unknown devices out of the healthy bucket

Even latest-per-device aggregation describes observed devices. Retired devices, missing telemetry, and a stale last observation need an explicit policy. Define freshness before calling the result a current fleet inventory, and report unknown states separately instead of treating silence as evidence of health.

A reporting correction may leave every displayed count unchanged: the query can stay the same while its title and interpretation become accurate. Calculating a replacement device-level metric is separate work and requires source data that supports it.

Audit the partition keys behind one account-level health table, then check whether its title describes exactly the rows that survive.

A CVE cross-reference is not an advisory entry

Wed, 28 Oct 2026 00:00:00 +0000

A vulnerability index can have the correct set of CVE identifiers and still assign them to the wrong advisories. A regex that searches every paragraph also captures narrative references such as “related to CVE-…”. Extract identifiers from declaration blocks, and verify the resulting relationships before using the index to make patch or exposure claims.

The trap is easy to miss during deduplication: the referenced identifier may already have a legitimate entry elsewhere. Removing its false assignment changes the relationships without changing the global distinct-ID count.

How the wrong relationship gets created

Consider two synthetic advisories. Every identifier below is fictional:

Advisory A, component Reader, declares CVE-2099-10001.
Its impact paragraph mentions CVE-2099-10002 as a related issue.
Advisory B, component Writer, declares CVE-2099-10002.

An extractor that carries the current advisory and component into every regex match produces three rows. The false row associates Advisory A and Reader with the second identifier. Both the broken and corrected indexes contain two distinct identifiers.

This error can contaminate a patch matrix: an analyst might attach the wrong affected component or release boundary to a real vulnerability. It requires no malicious input. A crafted narrative mention could produce the same misassociation in a pipeline that ingests untrusted documents, but that is a possible abuse of the parser, not evidence of an exploited advisory feed.

Filter by document role before matching identifiers

For one fixed document layout, a practical repair is to collect complete paragraph text and process only blocks beginning with the declaration marker CVE-. Collecting the whole paragraph matters: identifiers can be split across inline elements, and indentation should not change classification.

Here is a runnable Python example using a deliberately small HTML schema. Save it as check_advisories.py and run python3 check_advisories.py:

import re
from html.parser import HTMLParser

ID = re.compile(r"\bCVE-\d{4}-\d{4,}\b")
FIXTURE = """
<article data-advisory="A" data-component="Reader">
 <p> <strong>CVE-2099-10001</strong> </p>
 <p>Related to <em>CVE-2099-10002</em>.</p>
</article>
<article data-advisory="B" data-component="Writer">
 <p>\n CVE-2099-<span>10002</span> </p>
</article>
"""

class Index(HTMLParser):
 def __init__(self, declarations_only):
 super().__init__()
 self.declarations_only = declarations_only
 self.context = None
 self.parts = None
 self.rows = set()

 def handle_starttag(self, tag, attrs):
 if tag == "article":
 attrs = dict(attrs)
 self.context = (
 attrs["data-advisory"], attrs["data-component"]
 )
 elif tag == "p":
 self.parts = []

 def handle_data(self, data):
 if self.parts is not None:
 self.parts.append(data)

 def handle_endtag(self, tag):
 if tag == "p" and self.parts is not None:
 text = "".join(self.parts).strip()
 if not self.declarations_only or text.startswith("CVE-"):
 for identifier in ID.findall(text):
 self.rows.add((*self.context, identifier))
 self.parts = None
 elif tag == "article":
 self.context = None

def extract(declarations_only):
 parser = Index(declarations_only)
 parser.feed(FIXTURE)
 parser.close()
 return parser.rows

broken = extract(False)
fixed = extract(True)
assert fixed == {
 ("A", "Reader", "CVE-2099-10001"),
 ("B", "Writer", "CVE-2099-10002"),
}
assert broken - fixed == {("A", "Reader", "CVE-2099-10002")}
assert {row[2] for row in broken} == {row[2] for row in fixed}
print(f"relationships: {len(broken)} -> {len(fixed)}; distinct IDs unchanged")

Expected output:

relationships: 3 -> 2; distinct IDs unchanged

A prefix guard has a document contract

This parser is a fixture, not a general advisory importer. A narrative paragraph could itself begin with a CVE identifier; another publisher might declare identifiers in a table or list. For production ingestion, select the publisher’s actual declaration element or structured field, record the source location, and reject or flag layouts the adapter does not recognize. The standard library’s HTMLParser documentation describes its event interface; it cannot infer a publisher’s semantic roles for you.

Keep regression fixtures for narrative references, whitespace, and inline markup. Review added and removed (advisory, component, CVE) tuples during a parser change, including declarations the new selector might accidentally discard.

Before trusting your next vulnerability-index refresh, check one known cross-reference against its owning advisory. A stable distinct-ID total cannot validate that assignment.

An offline cache TTL needs a clock-rollback policy

Tue, 27 Oct 2026 15:44:00 +0100

AAn offline cache can pass its age check after the device clock moves backward. A timestamp later than “now” produces a negative age, and a check that only asks whether age is below the TTL accepts it. Reject future timestamps and remember the latest wall-clock time observed, while recognizing that neither check provides trusted elapsed time.

A negative age passed the upper-bound check

The feature reused a biometric-protected Keychain cache shared with a companion extension. Its initial eligibility rule was effectively:

now - lastWritten <= maxAge

That has two problems. Moving the clock before the write makes the age negative. Moving it backward after a previous access can also make an expired cache look young again without crossing the write timestamp.

The cache contained independently written items. Using the newest item’s date would make an older item appear refreshed, so eligibility used the oldest modification date. A separate check rejected any item dated in the future. Checking only the oldest date would miss a newer, future-dated item.

Retain the latest observed time

The repair added a clock mark in a separate Keychain item. Each eligibility read retained max(previousMark, now). If now preceded the previous mark, access was refused. Writing the rolled-back time into the mark would let the next read pass, so repeated reads were part of the regression test.

This Python model isolates the arithmetic from Keychain storage. Inputs are timestamps in the same unit and a nonnegative maximum age. None represents initial mark creation; it does not distinguish first use from a failed storage read.

def cache_status(written_at, now, mark, max_age):
 if not written_at:
 return "unavailable", mark

 previous = now if mark is None else mark
 updated = max(previous, now)
 fresh = (
 now >= previous
 and max(written_at) <= now
 and now - min(written_at) <= max_age
 )
 return ("fresh" if fresh else "expired"), updated

Persist the returned mark reliably. Define separate behavior for a missing mark, failed reads, and failed writes. Serialize the read/advance/write operation across its writers: two callers storing independently calculated maxima can otherwise overwrite a newer mark with an older one. This function does not implement those storage guarantees.

A successful online sign-in reset the mark to the current time, allowing recovery after a fast clock was legitimately corrected. That reset belonged to the authenticated online path, not to an offline retry.

Refusing access did not mean deleting the cache

The main app’s expiry policy could not delete data the companion extension still needed. An expired result blocked that entry point and requested an online sign-in; it left the shared cache intact.

Offline use also had to stay separate from an ordinary signed-in state. Otherwise, the normal cache writer could rewrite cached data, advance its modification dates, and renew its apparent freshness without server contact. A timestamp is useful evidence of synchronization only while that write invariant holds.

Eligibility was checked again when opening the cache. A login screen left visible across the deadline could not reuse the earlier “fresh” result.

Test the rollback twice

The original implementation’s red run reported four failed clock-mark assertions, including rollback refusal, repeated refusal, mark advancement, and online-sign-in reset. After the repair, the recorded core-target run passed 184 tests in 31 suites. Those are historical Xcode results, not a new Keychain integration run.

A separate run of the function above passed 15 synthetic-timestamp tests, covering expiry boundaries, future-dated items, repeated rollback refusal, and rechecking at open without mutating the cache. It did not exercise Keychain persistence. For example, two reads with these synthetic inputs must preserve the higher mark:

result, mark = cache_status([100], 190, 200, 1000)
assert (result, mark) == ("expired", 200)
assert cache_status([100], 190, mark, 1000) == ("expired", 200)

A high-water mark cannot establish time that was never observed

A device can spend real time offline while its wall clock never exceeds the saved mark. These checks cannot prove how much time passed, guarantee remote revocation, or withstand a compromised device that can alter the protected state. Biometric access control does not authenticate the clock.

Test your cache by expiring it, moving the injected clock backward, and reading eligibility twice. Both reads should refuse access, and the second must not inherit a lowered mark.

iOS jailbreak protection in 2026: detection is a risk signal, not a security boundary

Mon, 26 Oct 2026 23:20:00 +0100

An iOS app had jailbreak detection, passed an external pentest, and still spent more than a year accepting every jailbroken device because an asynchronous result was discarded. After that bug was fixed, the checks were still a 2025 list of Cydia-era paths that missed current rootless and hidden jailbreaks.

If the requirement says “the app must not run on a jailbroken phone,” the useful answer in 2026 is not a longer path list. Treat jailbreak detection as a bypassable risk signal, decide what sensitive operation the signal protects, enforce that decision at the server where possible, and test the whole policy against current jailbreak and bypass tools.

The short version

A defensible implementation today has five parts:

Write a threat model that explains why a compromised device materially changes this app’s risk.
Combine independent local signals and run them near sensitive operations, not only at launch.
Apply a proportional policy: observe, step up, restrict sensitive data, or refuse service according to confidence and impact.
Put the final authorization decision on a server and use App Attest to protect app-to-server requests. Do not call App Attest to prove that a device is not jailbroken.
Test the release binary statically, dynamically, and by trying to bypass it on representative clean and jailbroken devices.

This is also the difference between “the code contains a jailbreak check” and an engineering conclusion that can survive review.

How a working check silently stopped working

The first implementation was conventional:

sysctl checked P_TRACED and terminated a release build under a debugger;
known paths such as /Applications/Cydia.app, /bin/bash, /usr/sbin/sshd, and /etc/apt were checked;
the app tried to write /private/jailbreak.txt outside its sandbox;
cydia:// was passed to canOpenURL;
loaded Mach-O images were searched for MobileSubstrate.

It ran only in non-Debug builds on physical devices. That was sensible, and the pentest team verified it.

One probe had never worked in the affected app targets: canOpenURL returns false for schemes that are not declared under LSApplicationQueriesSchemes, and cydia was not declared. An app extension could not use UIApplication.shared at all. Current IOSSecuritySuite also removed the cydia:// check because an App Store app registered the scheme and caused false positives. URL-scheme probes are weak evidence even when configured correctly.

Then the check moved behind a function that started a Task, returned from the function immediately, and ignored the task’s Bool. The user interface always received true. The debugger check still appeared to work because fatalError happened inside the task, masking the control-flow bug. Later refactors moved the broken call without changing its behavior.

The eventual fix was not another jailbreak signature. It was to make validation genuinely asynchronous, await it, and test the production call site as well as the checker.

That history produced three reusable lessons:

Test enforcement, not just detection. A perfect signal whose result is ignored protects nothing.
Test every app entry point and extension. The main app, credential provider, widget, and background path do not necessarily share a process or API surface.
Test the release configuration on hardware. A Debug simulator test proves code structure, not production behavior when the checks are compiled out there.

When OWASP says to implement jailbreak detection

OWASP MASTG 2.0, released in July 2026 , makes the trade-off unusually explicit. MASTG-BEST-0030 is currently tagged Android and says “root detection,” but its risk principle applies directly to the equivalent iOS control: it is a bypassable, cost-raising environment signal. It should be used only when compromised-device risk materially affects the app. The selection and response should follow the threat model and risk tolerance.

That points toward jailbreak protection when a compromised platform makes a concrete abuse case easier, for example:

extracting high-value secrets or regulated data from the app process or local cache;
instrumenting transactions, credential filling, cryptographic operations, or fraud controls;
changing a game, licensing, payment, or content-access decision made locally;
automating a protected API through a modified client;
defeating controls that depend on the sandbox, Keychain access policy, or trusted user interaction.

It does not make jailbreak detection a universal mobile-app baseline. A low-risk public-content app may gain little while inheriting false positives, support work, accessibility problems, and an exclusion policy it cannot reliably enforce.

MASVS-RESILIENCE-1 states the security concern: many other controls assume that the platform’s sandboxing, secure storage, and biometrics can be trusted. But the wider MASVS resilience guidance treats anti-tampering and runtime self-protection as defense in depth, never a replacement for the baseline security architecture.

The current techniques are rootless and designed to hide

The old signature list described rootful Cydia and MobileSubstrate installations. Current jailbreaks changed the filesystem layout and then added explicit concealment.

Dopamine is a rootless jailbreak. Its bootstrap commonly appears below /var/jb, with ElleKit providing tweak injection. Dopamine 1.1 introduced JB_ROOT_PATH in the environment of processes with tweaks enabled, while noting that /var/jb might become optional to impede detection. Palera1n has its own loader and helper artifacts. Frida may appear as frida-server, Frida Gadget, a loaded image, or merely runtime behavior after its obvious names have been changed.

At the time of this review, Dopamine’s current upstream release was 3.0.12, published October 20, 2026 . A signature inventory that stops at Cydia or even Dopamine 2 is already historical.

Dopamine 2.4’s release notes are the more important evidence: “Hide Jailbreak” was changed specifically to hide the jailbreak to the point where it should be undetectable. RootHide’s Dopamine integration randomizes the jailbreak root and selectively keeps jailbreak changes away from blacklisted apps. Its purpose is jailbreak-detection bypass.

A 2026 local detector should therefore look across different classes of evidence, for example:

rootful and rootless files, directories, symlinks, package-manager state, and randomized .jbroot-* roots;
whether the sandbox permits a collision-safe write to a protected path;
debugger state and failure of the debugger-status query itself;
suspicious environment keys such as DYLD_INSERT_LIBRARIES and JB_ROOT_PATH;
loaded images associated with Frida, ElleKit, Substrate, Substitute, libhooker, RootHide, or Dopamine’s system hook;
behavior that should be prohibited by the sandbox, where the API is appropriate for App Store software;
server-side anomalies and app-integrity assertions.

Use more than one API for important filesystem evidence. A FileManager.fileExists check, a POSIX lstat, and directory enumeration do not create certainty, but an attacker now has more hooks to maintain consistently.

Do not equate more signatures with “state of the art.” Public signature lists are useful coverage for unsophisticated and accidentally exposed jailbreaks. RootHide, renamed Frida components, or a patch to the function that aggregates all checks can make every local answer say “clean.” OWASP’s jailbreak detection knowledge article says the same thing: these defenses are not effective by themselves, although distributing them through the app increases the cost of bypassing them.

The response matters more than the Boolean

“Jailbroken: yes or no” is too weak a model for a fallible set of signals. Record an internal risk result with the evidence and confidence, then map it to a product policy.

Situation	Reasonable response
One weak or ambiguous signal	Telemetry, retry, or step-up authentication
Several independent local signals	Block sensitive operations; avoid disclosing the exact failed probe
Debugger or injected runtime tool in a high-risk flow	Refuse the operation and invalidate relevant server state
Unsupported App Attest on an otherwise supported device	Treat as a risk signal according to the documented policy
Enterprise-managed fleet with a strict posture requirement	Evaluate Managed Device Attestation at the relying service

OWASP recommends proportional responses and warns that aggressive lockout can affect legitimate users. For an app that stores documents and credentials, a useful soft block can allow login and folder metadata while refusing document bodies, downloads, offline queues, and credential release.

That restriction must be in application logic, not just a screen with a Close button. Better still, the server should not return the sensitive payload. Otherwise, a hook can dismiss the screen or call the same API directly.

A hard process exit is appropriate only if the threat model justifies denial of all functionality and the product accepts false positives. Crashing also gives poor observability and can turn an operational failure into a permanent lockout. A generic refusal with server-side telemetry is usually easier to operate.

App Attest authenticates app instances, not clean devices

Apple’s WWDC26 App Attest session describes the current protocol:

the server initiates enrollment and issues a challenge;
the app creates a Secure Enclave-bound key and attests it;
the server validates and stores the attestation and public key;
sensitive requests include a fresh server challenge in an assertion over the payload;
the server validates the signature and requires a strictly increasing counter to reject replays.

This is valuable. It lets the server distinguish a valid published app instance, detect unexpected signing or launch categories, and bind authorization to a payload that has not been altered in transit.

It is not a jailbreak oracle. The same 2026 session says that a compromised device can still pass attestations and broker valid attestations for modified clients. Apple provides the fraud metric to help detect that pattern. Use App Attest as another server-verified signal, with retry and onboarding policy for legitimate failures.

For managed organizational devices, Managed Device Attestation provides Secure Enclave-backed evidence about device identity and security posture. That is stronger input for a managed-fleet trust decision, but it is not a general capability that a consumer app can require from every unmanaged phone.

Test implementation, behavior, and bypass resistance

OWASP MASTG 2 separates two questions that teams often collapse into one.

MASTG-TEST-0240 is static: extract the shipped app package and inspect the binaries for jailbreak-detection mechanisms. This catches missing code, build flags that compiled it away, or a check that never reached a target. OWASP warns that automated static analysis is not exhaustive; manual reverse engineering may be necessary.

MASTG-TEST-0241 is dynamic: run the app, identify the checks, and try to bypass them. A test fails when detection is absent, but passing a single predefined bypass tool doesn’t prove resilience because its scripts may be incomplete or outdated.

For a real release, I would keep this matrix with the evidence from each run:

Test	Expected evidence
Clean supported iPhones and iOS versions	No false refusal; all sensitive flows work
Release build on physical hardware	Checks execute; Debug/simulator exclusions do not leak into the archive
Rootful and current rootless jailbreaks	Each applicable signal fires; policy is enforced
Dopamine Hide Jailbreak and RootHide blacklist	Document what remains visible and what becomes undetectable
Frida server and embedded/renamed Gadget	Known artifacts are detected; renamed forms challenge bypass resistance; outcomes are recorded
Hook the aggregate result and individual APIs	Sensitive server operation still requires valid authorization and assertions
Main app, extensions, background entry points	Each entry point validates before releasing its protected capability
Async and error paths	Results are awaited; query failures follow the documented fail-open or fail-closed policy
Pentest bypass configuration	It cannot enter a production archive; CI tests that invariant

Unit-test injected signals, cleanup failures, query failures, and clean-device results. Then add integration tests around the call site: the protected operation must not run after validation fails. Finally, let a tester attack the binary rather than merely demonstrating a known file on a jailbroken test phone.

A reviewable 2026 “lege artis” baseline

“State of the art” is not established by citing one library or by counting checks. For an engineering review, the conclusion should be reproducible, dated, scoped, and explicit about uncertainty. This is the practical baseline I would use when assessing whether an iOS app’s jailbreak protection was implemented with professional care in October 2026:

Define the question and date. State which app version, release configuration, iOS range, device classes, sensitive operations, and attacker capabilities are in scope. Practice changes as jailbreaks and iOS change.
Identify the risk before prescribing the control. Connect compromised-platform capabilities to actual assets and abuse cases. Explain why jailbreak detection materially affects this app.
Select authoritative and current sources. Record versions and access dates for OWASP MASVS/MASTG, Apple platform documentation, relevant jailbreak release notes, and the implementation under review. Treat public detection libraries as examples, not normative standards.
Preserve and identify the evidence. Record the source commit, archive hash, build settings, entitlements, tool versions, device/iOS versions, jailbreak version, and test logs. Work from a reproducible copy.
Separate facts from interpretation. “The production binary contains /var/jb and JB_ROOT_PATH checks” is a fact. “Those checks make bypass harder but cannot establish a clean device” is the interpretation supported by OWASP and current bypass projects.
Analyze the whole control path. Review signal collection, aggregation, async propagation, every entry point, the product response, server authorization, telemetry, and release-lane exceptions. Include negative findings and dead code.
Test both presence and effectiveness. Perform static inspection, clean-device compatibility tests, dynamic execution on relevant jailbreaks, and bypass attempts. A unit test or a pentest on one jailbreak version is not enough.
Consider alternatives and false positives. Explain why a detected artifact could be benign, why a missing artifact does not establish cleanliness, and why the chosen response is proportional.
State limitations. Local checks can be hooked or patched; hidden jailbreaks may expose no artifact; App Attest can succeed on a compromised device; the tested device set is finite.
Make a bounded conclusion. Say whether the examined implementation follows the documented risk policy and raises attacker cost for the tested scenarios. Do not conclude that it guarantees a non-jailbroken device.

This structure mirrors a sound software expert analysis: sources and methods are identified, observations remain distinguishable from interpretation, contrary evidence is not hidden, limitations reduce the stated certainty, and the conclusion answers only the technical question examined. It is guidance for an engineering assessment, not a legal conclusion about liability, contractual compliance, or negligence.

Takeaway

The old implementation failed twice: first because application control flow discarded a valid result, then because its threat model had aged past its Cydia-era signatures. The durable fix is a process—current layered signals, proportional server-enforced policy, and repeated adversarial testing—not a permanent isJailbroken function.

Take one sensitive operation in your app and trace it today from device signal to server authorization. If any step can ignore, hide, or locally override the result, that is the next protection to fix.

References

OWASP MASVS: Resilience against reverse engineering and tampering , accessed October 26, 2026.
OWASP MASTG 2.0.0 release announcement , July 4, 2026.
OWASP MASVS-RESILIENCE-1: Platform integrity , accessed October 26, 2026.
OWASP MASTG-BEST-0030: Implementing Root Detection , accessed October 26, 2026.
OWASP MASTG-KNOW-0084: Jailbreak Detection , accessed October 26, 2026.
OWASP MASTG-TEST-0240: Jailbreak Detection in Code , accessed October 26, 2026.
OWASP MASTG-TEST-0241: Runtime Use of Jailbreak Detection Techniques , accessed October 26, 2026.
Apple: Secure your apps with App Attest, WWDC26 , accessed October 26, 2026.
Apple Platform Security: Managed Device Attestation , accessed October 26, 2026.
Dopamine 2.4 release notes: Hide Jailbreak , February 16, 2025.
Dopamine 1.1 release notes: JB_ROOT_PATH , June 16, 2023.
Dopamine releases , accessed October 26, 2026.
Dopamine 3.0.12 release , October 20, 2026.
RootHide integration for Dopamine 3 , accessed October 26, 2026.
IOSSecuritySuite jailbreak checker , accessed October 26, 2026.

Adapt security skills to your project's risks: from Go to OWASP LLM and iOS

Sun, 25 Oct 2026 21:50:00 +0100

A security skill written for Go covers different questions than one written for an LLM application or an iOS app. I started with golang-security from samber/cc-skills-golang , asked Claude to adapt it using the OWASP Top 10 for LLM Applications, and later carried that approach into production iOS development.

The most useful part of the adaptation was aligning the review questions with the project’s risks and the company’s values.

Start with a review method

I was working in Go, a language I was unfamiliar with. I used my security skills alongside other Go skills to keep the implementation in check.

The security skill provided a repeatable method: separate modes for coding, reviewing changes, and auditing a codebase; questions about trust boundaries and attacker-controlled input; and instructions to trace data through surrounding code before reporting a finding. Its references and checklist gave the agent somewhere to look beyond the main instructions.

Adapt OWASP categories to the application

I asked Claude to create a new skill using the OWASP Top 10 for LLM Applications (2025) , adapted to the project’s LLM and Model Context Protocol (MCP) surfaces.

The resulting llm-security skill kept the review modes and evidence requirements. It mapped the categories to tools, resources, prompts, and content returned to the model. The Go checklist stayed active for the code underneath.

For prompt injection , the reviewer needs to identify whose text reaches the model and what an attacker can control. A returned document body or filename can carry instructions. For excessive agency , the questions concern tool permissions, reachable side effects, and authorization enforced outside the model.

Those questions give the agent a path through the repository. It can follow a tool result back to its data source, then follow a tool call forward to the operation it performs. The skill also asks it to account for existing protections when assessing impact.

Repeat the adaptation for iOS

Later, I applied the same approach to an iOS app using the OWASP Mobile Top 10 (2024) . That mobile security skill became part of production development.

The review method carried over. The mapping changed to platform APIs and the code responsible for them:

Mobile risk	Concrete review question
Improper credential usage	Where are tokens stored, and which Keychain access settings apply?
Insufficient input/output validation	What can a deep link or share-extension input cause the app to do?
Insecure data storage	Which protection classes apply to cached and temporary user files?
Inadequate privacy controls	Where can sensitive data appear outside its intended screen, including logs and notifications?

Repository context matters here. If a shared SDK owns authentication or networking, the skill needs to direct the reviewer into that SDK. Stopping at the changed Swift view would leave the relevant behavior unexamined.

For a mobile adaptation, MASVS supplies verification controls, and MASTG provides testing guidance for checking them.

Turn company values into review rules

Company values need concrete instructions too. For example, a company that prioritizes privacy can require reviewers to trace user data into logging, analytics, and crash reporting. That turns a broad preference into something an agent can inspect.

The mobile skill also records settled product decisions. An intentional tradeoff needs a rationale and the protections that still apply so that each review can assess the implementation against that decision. New evidence or changed assumptions can justify reopening it.

Severity needs the same local reasoning. OWASP provides risk categories; the product’s data, attacker access, and existing controls determine a finding’s impact.

A fresh adaptation request could be:

Use the existing security skill as a template. Keep its review workflow
and evidence requirements. Adapt the relevant OWASP categories to this
repository's entry points, data flows, and platform APIs. Link each check
to the responsible code and a primary reference. Record product decisions
with their rationale. Preserve the language-level checks alongside it.

Tailoring a security skill gives the agent concrete questions about the product it is building. Take one OWASP category in your current skill and map it to the code, data, and product decision the reviewer should examine.

A repeatable agentic development workflow: context, tickets, implementation, review

Sun, 25 Oct 2026 18:25:00 +0100

Giving a coding agent a feature request and accepting the first working diff is easy. Repeating that across projects is where things get messy: the agent has to rediscover the domain, invent missing requirements, decide what “done” means, and review its own assumptions.

Here is the setup I now reuse across stacks. It has supported ten iOS app releases this year, helped clean up an existing app built with loose agent guidance, and helped a Go implementation recover after its first approach fell apart - to name a few examples. The Go work also involved a language stack and MCP technology I had not used before. The process didn’t provide that expertise on its own; it made the gaps visible early enough to address them.

Give the agent durable context

Start with mattpocock/skills and run its repository setup. Keep a short domain vocabulary in CONTEXT.md (or the current upstream convention, GLOSSARY.md). Record consequential design choices as ADRs. The agent can then use the same terms in discussions, tickets, code, and reviews.

For a change whose shape is uncertain, use /grill-with-docs to work through the decisions and write them down. Run /to-spec once the conversation has enough detail. Break the spec into small, ordered tickets with /to-issues in older installations or /to-tickets in the current upstream skills. Then use /implement against those tickets.

The sequence is:

shared vocabulary + ADRs → grill → spec → tickets → implement → review

You can enter the sequence at whichever step the work needs. A small, well-specified fix may already have a ticket. An uncertain feature should be grilled before an agent starts writing code.

Put tickets where the project works

The tracker is an adapter for the process. One project keeps issues in a local docs/TODO.txt; others use Vikunja or Taiga. What matters is that the agent knows where the authoritative spec and tickets live, how to record blockers, and how to update their status. Write those rules into the repository’s agent documentation. A tracker integration skill can handle the API details without changing the development sequence.

This also makes the setup portable. Moving to a new project means teaching the agent that project’s domain, tracker, and checks, rather than rebuilding the workflow.

Make implementation answer to the spec

Implementation includes tests and a diff review. Review the result against two different questions: does the code follow the project’s standards, and does it actually satisfy the originating spec? The latter catches plausible code that solves the wrong problem. A previous review found duplicate-write paths after a large test suite passed because it checked a safety claim against the call path.

Where the project’s rules allow it, use a different model family for review. A typical split is Claude writing the code and GPT reviewing it, since a different family brings different blind spots. Claude reviewing Claude has also proven decent, so one family is still a workable setup when you can only use one provider. For larger changes, a multi-review skill can run distinct axes such as correctness, quality, tests and performance, security, and, for frontend, accessibility. Give each reviewer the same bounded diff and the actual spec; collect actionable findings back into the tracker.

Attach stack-specific skills where they help. Go work can load guidance for concurrency, error handling, testing, and security. iOS work can use Swift and mobile guidance. For exposed web APIs, mobile clients, or MCP tools, apply relevant OWASP-based web, mobile, and LLM security skills during implementation and review. A checklist gives the agent concrete questions to ask; it does not turn a code review into a security certification.

Start with one change: write down the vocabulary and decision, turn the request into a spec and tickets, implement one ticket, and review the diff against the spec and its security boundaries. Adjust the tracker, skills, and review axes to fit the next project.

fail2ban that never banned anyone: '/bin/sh: 1: nft: not found'

Fri, 16 Oct 2026 15:33:00 +0200

fail2ban said the address was banned:

$ sudo fail2ban-client status nginx-limit-req
...
 `- Banned IP list:	203.0.113.10

From that address, right after:

$ curl -s -o /dev/null -w '%{http_code}\n' https://example.com/
302

The reason was in /var/log/fail2ban.log all along:

2026-03-14 10:21:05,205 fail2ban.utils [1293]: ERROR 7f5e8fbb0d30 -- exec: nft add table inet f2b-table
2026-03-14 10:21:05,206 fail2ban.utils [1293]: ERROR 7f5e8fbb0d30 -- stderr: '/bin/sh: 1: nft: not found'

On Debian, fail2ban bans through the nft command. A host that runs firewalld can easily lack it. fail2ban then counts failures, lists bans, and blocks nothing, including the sshd jail.

The setup

Debian 13, fail2ban 1.1.0-8, firewalld 2.3.1 with FirewallBackend=nftables
nginx as a reverse proxy in front of a few web apps, SSH forwarded from the router
fail2ban set up by hand, with the stock sshd jail

Debian’s /etc/fail2ban/jail.d/defaults-debian.conf picks the ban action:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]

How it showed up

I was adding jails for the web logins, so I tested them from a VPS outside every whitelisted network. Testing from home proves nothing when home is in ignoreip. Twenty-five quick POSTs to a login endpoint:

for i in $(seq 25); do
 curl -s -o /dev/null -w '%{http_code} ' -d client_id=probe https://example.com/login
done

The first 11 got 400 from the app, the rest 429 from nginx’s rate limit, and the nginx-limit-req jail banned the VPS as it should. Then the next request got a 302, as if nothing had happened.

sudo nft list table inet f2b-table answered sudo: nft: command not found. The log held ten lines like the ones above. Each failed ban left two ERROR lines in a log nobody reads, while fail2ban-client status still listed the bans.

The fix

Install the nft command:

sudo apt install nftables
sudo systemctl restart fail2ban

Leave nftables.service disabled, as the package installs it. Debian’s /etc/nftables.conf starts with flush ruleset, so enabling the service would wipe firewalld’s rules at the next boot. fail2ban doesn’t need the service, only the binary. It keeps its bans in a table of its own, inet f2b-table, next to firewalld’s inet firewalld.

On restart, fail2ban restores the bans it has on record, so the ones that had silently failed now take effect:

fail2ban.actions [1649343]: NOTICE [nginx-limit-req] Restore Ban 203.0.113.10

Give it a few seconds before you check. Right after the restart, nft list table inet f2b-table still said No such file or directory. A moment later, it showed the set and the rule:

table inet f2b-table {
	set addr-set-nginx-limit-req {
		type ipv4_addr
		elements = { 203.0.113.10 }
	}
	chain f2b-chain {
		type filter hook input priority filter - 1; policy accept;
		tcp dport { 80, 443 } ip saddr @addr-set-nginx-limit-req reject with icmp port-unreachable
	}
}

This time, curl on the VPS couldn’t connect at all (exit code 7). If you manage the host with Ansible or similar, add nftables to the package list alongside fail2ban so a rebuilt host doesn’t lose it again.

Why the binary was missing

firewalld talks to the kernel through the python3-nftables bindings, not the nft command, so it doesn’t pull in the nftables package. fail2ban only recommends it as an alternative:

$ apt-cache show fail2ban | grep ^Recommends
Recommends: nftables | iptables, whois, python3-pyinotify, python3-setuptools

iptables was already installed (firewalld recommends it), so apt considered the recommendation met. The ban action still called nft.

The same thing can happen with any ban action whose command isn’t on the host: the action fails, and the address stays on the ban list anyway.

Takeaway

Banned IP list shows what fail2ban decided, not what the firewall does. The only proof that a ban works is a blocked connection from the banned address, and grep ERROR /var/log/fail2ban.log tells you why one isn’t.

Get one of your own hosts to ban a machine outside its whitelist, then try to connect from that machine.

Cyber classifiers can interrupt offline pentest summaries

Fri, 09 Oct 2026 00:00:00 +0000

An agent spent three minutes reading local transcripts from a finished, authorized security exercise, then stopped with:

This request triggered cyber-related safeguards.

No live target was involved. The job was offline summarization, yet the classifier interrupted it before it could write the requested report. The practical fix was to treat security-history analysis as a resumable data pipeline: retain message provenance, checkpoint extracted evidence, and keep the handoff usable by another approved model or provider.

A flag-shaped string is not a captured flag

The first problem appeared before the classifier fired. A search through about 25 request dumps found dozens of flag-shaped strings. About 20 were spelling, capitalization, spacing, or hyphenation variants of one value.

Most variants appeared only in assistant reasoning and progress notes. The model repeatedly retyped a remembered value and changed it. A checkpoint then copied one mutation into later sessions.

Only strings preserved in tool results represented observed server output. To separate evidence from generation, use this origin-based distinction:

user request instruction or supplied context
assistant text generated claim; unverified
assistant reasoning generated hypothesis; unverified
tool call attempted action
tool result observed output from that action
provider error evidence about the run, not the target

This applies beyond CTF flags. Treat IDs, hashes, error codes, hostnames, and quoted responses in model prose as leads until the first tool result corroborates them. Exact-looking text is still generated text.

Offline processing still triggers cyber classifiers

The retained run used Opus 5.5. It parsed local request dumps, separated real and decoy-looking values, and extracted an existing SMB investigation summary. After that, the next model response was refused under the provider’s real-time cyber safeguard. The session recorded a cyber refusal and pointed to its Cyber Verification Program. The output file did not exist afterward.

Some source dumps also contained earlier cyber_policy failures from another provider along with a prompt to apply for Daybreak access. Because these records were historical input, they still increased the concentration of offensive-security language the summarizer saw.

A related authorized test had a similar shape: generate enough traffic against a non-production environment to trigger a WAF, then verify that the application displays and retries a CAPTCHA correctly. In a newer Opus session, the controlled load-test work was refused. The retained successful session used Opus 4.6 and built the test client, while a later session corrected its cookie handling and the request used to observe the challenge.

The awkward lesson is that task intent and classifier input are different things. In practice, “Summarize these old logs” can contain exploit commands, credentials, flags, and attack narratives. Likewise, “Test the CAPTCHA” can require traffic that resembles denial of service when reduced to request counts.

Make the audit resumable and model-neutral

Do deterministic work before asking a model to synthesize:

Parse each transcript into typed events and preserve the source file, timestamp, role, tool-call ID, and tool-result ID.
Extract exact-match artifacts only from tool results. Store assistant claims separately as unverified leads.
Write incremental JSON or Markdown after each source file. Never leave the only useful state in the model’s context window.
Produce a sanitized handoff containing the authorization scope, completed files, pending questions, and evidence pointers.
Verify the final report exists and reconcile its artifact counts against the extraction index.

Provider access programs are worth the setup when this work recurs. In my experience, GPT Daybreak Blue justified the hassle for authorized security-related tasks. Kimi, GLM, and older model versions have also completed useful work when a newer classifier blocked the same class of jobs. That is a fallback, not a bypass: preserve the same authorization boundary, do not weaken the requested scope, and use models approved for the work.

Before trusting your next transcript summary, choose one exact token from the report and trace it back to the tool result that observed it.

Apache UserDir /home/* can publish private dotfiles

Wed, 07 Oct 2026 00:00:00 +0000

A personal-homepage feature can expose a user’s shell history even when directory listings are disabled. With Apache mod_userdir, a whole-home mapping such as UserDir /home/* maps a request for /~demo/.bash_history directly into that home directory. Restrict publication to a dedicated subtree, and verify that a direct request for a private canary fails while the public page still loads.

This is a filesystem-publication error. It requires neither path traversal nor a dotfile-specific Apache vulnerability: the requested file is already inside the configured web namespace.

How the mapping exposes private files

The Apache UserDir documentation distinguishes relative directory names from absolute-path templates. Compare:

# Unsafe publication boundary if this tree is readable and authorized:
UserDir /home/*

# Publish only the dedicated subtree:
UserDir /home/*/public_html

In the first form, /~demo/.audit-canary maps to /home/demo/.audit-canary. In the second, it maps to /home/demo/public_html/.audit-canary. Filesystem permissions and Apache authorization still determine whether the request succeeds. The mapping alone does not grant read access.

A leading dot is a shell convention, not a general HTTP access-control rule. Likewise, Options -Indexes prevents generated directory listings; it does not prevent fetching a known filename. A deployment may deny some dotfiles explicitly without covering every private file in a home directory.

Exercise the exposure without collecting secrets

In an authorized test, have the administrator create a harmless .audit-canary outside the public subtree and a public index.html inside it. Make the canary readable by the test server so the check tests the mapping, not an accidental permission denial. Do not loosen permissions on real private files.

Against a disposable Apache instance bound to loopback on port 18080, request:

curl --fail --silent --show-error http://127.0.0.1:18080/~demo/.audit-canary
curl --fail --silent --show-error http://127.0.0.1:18080/~demo/public_html/

The vulnerable fixture returned the private marker and the public marker, both with HTTP 200. That establishes unintended file disclosure without downloading anyone’s history or keys.

Real exploitation follows the same direct-file read. Shell history can contain passwords, tokens, or an otpauth:// provisioning URI. That URI contains the shared TOTP seed: anyone who obtains it can generate the same codes as the authenticator. If the same exposure also yields an unencrypted private key accepted by a service requiring key plus TOTP, both factors can be compromised. File disclosure alone does not prove that such credentials exist or that another service accepts them.

Prevent publication at the directory boundary

Use a dedicated public directory with an explicit participant policy:

UserDir disabled
UserDir enabled demo
UserDir /home/*/public_html

<Directory "/home/*/public_html">
 AllowOverride None
 Options -Indexes -FollowSymLinks
 Require all granted
</Directory>

This fragment assumes mod_userdir is loaded. Adapt it to the site’s authorization policy, and check for overlapping directory sections. Remove broad grants on home directories, and keep private files unreadable to the web-server identity. If homepages are unnecessary, turn off the feature entirely. Symlinks and user-controlled overrides deserve separate review because they can expand the effective publication boundary.

If secrets were exposed, closing the route does not revoke copies already obtained. Replace affected keys and tokens, re-enroll affected TOTP credentials, and review access logs. Deleting a provisioning command from history cannot invalidate the seed.

Verify the fix and distrust status-code folklore

I tested the mapping with Debian’s Apache 2.4.69 in a disposable local fixture containing only synthetic files. After adding /public_html to the template, the same private-canary request returned 404, and /~demo/ returned the public marker with 200. No authentication service or real credential was involved.

The fixture’s nonexistent username also returned 404. Do not generalize a particular server’s 403/404 pattern into a reliable account-existence oracle. In Apache 2.4.62’s mapper source , the absolute-template branch substitutes the supplied name without the home-directory lookup used by relative mappings. Later filesystem and authorization processing affects the response.

Before trusting a personal-homepage setup, put a nonsecret canary immediately outside its intended public directory and request it by its exact URL.

A format string in a TRACE logger can read the process environment

Tue, 06 Oct 2026 00:00:00 +0000

A TRACE handler that echoes a request with snprintf(response, size, request_line) does more than log attacker-controlled text. It turns the request line into a printf format string and can leak stack data in an authorized test, including pointers into argv and envp, through positional %p and %s conversions. The one-line fix is snprintf(response, size, "%s", request_line).

This is CWE-134, use of an externally controlled format string . The bug often hides in diagnostics because developers treat the third argument as plain text. For the printf family, it is the format string: a small program that says what to read and, with %n, where to write.

A bounded copy does not make the format safe

The length argument to snprintf bounds the output buffer. It does not stop format directives from being evaluated:

/* Vulnerable: request_line controls the format language. */
int len = snprintf(response, sizeof response, request_line);

/* Fixed: request_line is data for a constant format. */
int len = snprintf(response, sizeof response, "%s", request_line);

The same rule applies to printf(input), fprintf(log, input), and wrappers around them. When no formatting is needed, prefer fputs.

A small local regression fixture makes the difference visible without reading sensitive memory. Save this as format-log.c in a disposable directory:

#include <stdio.h>
#include <string.h>

static void render(char *out, size_t size, const char *input, int fixed) {
 if (fixed)
 snprintf(out, size, "%s", input);
 else
 snprintf(out, size, input);
}

int main(void) {
 char vulnerable[128], fixed[128];
 const char *probe = "TRACE /%p HTTP/1.1";
 render(vulnerable, sizeof vulnerable, probe, 0);
 render(fixed, sizeof fixed, probe, 1);
 printf("vulnerable=%s\nfixed=%s\n", vulnerable, fixed);
 return strcmp(fixed, probe) != 0 || strcmp(vulnerable, probe) == 0;
}

Run it locally:

cc -O0 -Wall -Wextra format-log.c -o format-log
./format-log

The vulnerable line expands %p; the fixed line preserves it literally. The pointer value is intentionally unspecified.

How to exercise the disclosure safely

On an authorized disposable target, start with a normal request and a literal-percent control. Then use %p or positional %N$p to map candidate argument slots. Dereferencing a candidate with %N$s asks the process to treat that value as a string pointer, so expect child crashes and test one slot per fresh connection. Never run a broad %s sweep against production.

Environment strings commonly sit near the initial argument and environment vectors. A pointer leak can therefore become a secret leak when a service receives credentials through environment variables. Slot numbers are build- and runtime-specific; a number from one binary is not a portable exploit.

Fork-per-connection servers make repeated probing easier than expected. Children inherit the parent’s already-randomized mappings so that addresses can remain stable across child connections until the parent restarts. ASLR still applies to the parent; fork() simply copies that layout.

Treat %n as a separate, higher-risk write primitive. A read-only demonstration is enough to prove the logging flaw and should be the limit of most authorized validation.

Fix the sink and reduce the impact

Make every format string a constant and enable compiler diagnostics such as -Wformat=2 -Wformat-security. Add a regression request containing %p, %s, and %n as literal text, then assert that the logger preserves every byte. Static analysis should flag tainted data reaching any printf-family format parameter.

Do not rely on input filtering. Blocking a few percent directives is easy to get wrong and leaves other format sinks exposed. Fix the call boundary.

Finally, keep long-lived credentials out of network-facing process environments where possible. Use narrowly scoped, short-lived credentials and isolate the component. That limits the damage from any memory disclosure, but it does not replace fixing the format string.

Search your diagnostic and TRACE paths for nonliteral printf formats before assuming they are harmless logging code.

Next.js Server Action arguments are Flight data: use error digests carefully

Tue, 06 Oct 2026 00:00:00 +0000

A Next.js Server Action can receive a JSON-looking body whose strings are interpreted as React Flight tokens. If ordinary input works but $-prefixed input changes the response or produces HTTP 500, inspect the decoded arguments before trying more SQL or shell payloads. Differences between error digests can help separate failure paths, but they cannot establish a vulnerable version or remote code execution on their own.

This matters when testing the request behind an action call. The normal client serializer escapes literal strings for the protocol; manually editing the wire body can change what the server decodes.

The application sees the result of decodeReply

In the tagged Next.js 15.0.0 action handler , fetch-action bodies pass through decodeReply or its streaming counterpart before the selected action runs. The React 19.0.0 reply decoder interprets $-prefixed strings, including escaped literals, special numbers, and references.

For a local decoder, these argument values illustrate the distinction:

Wire string inside the arguments array	Decoded argument
`ordinary`	string `ordinary`
`$$literal`	string `$literal`
`$Infinity`	number `Infinity`
`$-Infinity`	number `-Infinity`
`$undefined`	`undefined`

A value changing type before the application function runs explains why an otherwise boring search action can behave strangely. Input validation inside that function does not protect an earlier, vulnerable deserializer.

Reproduce the protocol locally before probing further

Use an isolated scratch directory. The following intentionally installs an old, vulnerable package for an offline decoder experiment. Do not deploy it, expose a listener, or feed it untrusted traffic. Delete the directory afterward.

LAB=$(mktemp -d "${TMPDIR:?Set TMPDIR to your scratch directory}/flight-lab.XXXXXX")
cd "$LAB"
npm install --ignore-scripts --no-audit --no-fund --save-exact \
 react@19.0.0 react-dom@19.0.0 react-server-dom-webpack@19.0.0

Save this as check.cjs in that directory, then run node --conditions=react-server check.cjs:

const assert = require('node:assert/strict');
const { decodeReply } = require('react-server-dom-webpack/server.node');

async function check() {
 const cases = [
 ['ordinary', 'ordinary'],
 ['$$literal', '$literal'],
 ['$Infinity', Infinity],
 ['$-Infinity', -Infinity],
 ['$undefined', undefined],
 ];
 for (const [wire, expected] of cases) {
 const args = await decodeReply(JSON.stringify([wire]), {});
 assert.ok(Array.isArray(args));
 assert.equal(args[0], expected);
 }
 console.log('5 Flight decoding cases passed');
}
check().catch(error => {
 console.error(error);
 process.exitCode = 1;
});

This checks protocol behavior, not exploitability. For an authorized application assessment, reproduce the actual resolved packages and runtime conditions. Next.js may bundle its React implementation; a standalone npm package is not automatically an exact framework replica.

Preserve the decoded root’s expected shape, too. The tagged Next.js handler invokes actionHandler.apply(null, boundActionArguments). A root that resolves to a primitive string fails that call’s array-like argument requirement before the intended action behavior can be tested. Keep transport decoding and action invocation as separate checkpoints.

What an error digest can tell you

The Next.js 15.0.0 error handler generates digests using stringHash over error text and stack information in several paths, unless a digest already exists. One path uses:

err.digest = stringHash(err.message + (err.stack || '')).toString()

Different parser branches can throw from different stack locations and yield different digests even when the visible error message is generic. Record the complete response, status, and digest for each controlled input; repeat baseline requests to check stability. Correlate differences with logs in the local replica.

A digest is a lossy fingerprint. Build paths, package versions, runtime stacks, and existing application digests can alter it. Distinct digests suggest distinct error material; matching digests do not prove identical execution paths. HTTP 500 alone does not even locate the failure in Flight decoding.

Separate protocol reachability from React2Shell

React’s CVE-2025-55182 advisory confirms unauthenticated RCE through a flaw in decoding Server Function payloads. Ordinary Flight tokens also exist in correct protocol handling. Observing the transformations above therefore does not diagnose that CVE.

For exploit validation, first reproduce the affected decoder in a private replica and demonstrate a harmless, deterministic effect there. Keep that result separate from any authorized remote confirmation. The experiment above deliberately stops at benign decoding.

For prevention, follow the current React and framework advisories, update the resolved server-side packages, rebuild, and verify what the running artifact actually contains. Do not use the historical demonstration versions as a patch recommendation. Authenticate and authorize actions independently, validate decoded arguments, and avoid exposing decoded-input debug echoes. Those controls do not replace fixing a vulnerable decoder.

When a $ probe changes behavior, capture the full response and reproduce that transformation locally before assigning a CVE or an impact rating.

Prompt injection: extract tokens, then decode them offline

Tue, 06 Oct 2026 00:00:00 +0000

A model can repeat hidden, encoded prompt fragments and still produce a different decoded secret on each attempt. When an authorized prompt-injection test reaches that point, stop asking the model to solve its own leak. Capture the raw tokens with position and case intact, then decode them with deterministic code offline.

This separates two questions: can the model disclose protected context, and can a decoder reconstruct the encoded value? A fluent final answer is poor evidence for either one.

Lexical refusal filters leave a semantic gap

A filter that rejects phrases such as “show the system prompt” or “reveal the secret” checks wording, not intent. Semantically equivalent requests can ask the model to quote, classify, count, or list text from its instructions without using the blocked nouns. If the model can return those fragments, the control has failed even when the obvious request is refused.

For an authorized assessment, use a synthetic canary in a test system. Ask for a numbered transcription of the relevant tokens, one token per line, with original capitalization. Repeat individual positions and compare exact strings. Keep the transcript as evidence. Do not put a real credential in the prompt merely to test whether it leaks.

Do not ask the model to join, normalize, or decode the result. Those extra transformations invite changed case, missing groups, repaired spelling, and invented separators. Temperature zero may reduce variation, but it does not turn generation into a parser.

Decode a synthetic transcript deterministically

Suppose a test prompt encodes characters as phonetic words. Capitalized words mean uppercase letters, lowercase words mean lowercase letters, and number words mean digits. Save this offline decoder as decode.py:

NUMBERS = {
 "zero": "0", "one": "1", "two": "2", "three": "3",
 "four": "4", "five": "5", "six": "6", "seven": "7",
 "eight": "8", "nine": "9",
}

def decode(tokens):
 result = []
 for token in tokens:
 lower = token.lower()
 if lower in NUMBERS:
 result.append(NUMBERS[lower])
 elif token.isalpha():
 letter = token[0]
 result.append(letter.upper() if token[0].isupper() else letter.lower())
 else:
 raise ValueError(f"unsupported token: {token!r}")
 return "".join(result)

sample = ["Alpha", "bravo", "Charlie", "delta", "seven"]
assert decode(sample) == "AbCd7"
print(decode(sample))

Run python3 decode.py; it prints AbCd7. The assertion is a negative control against accidental lowercasing or regrouping. Adapt the decoder only from a documented encoding rule. If a separator or group length is unknown, report that ambiguity instead of asking the model to guess.

Keep an evidence table with the position, raw token, repeated observation, decoded character, and rule used. Hash or otherwise preserve the raw transcript if chain of custody matters. A model-generated summary is not a substitute for the original response.

Prevent prompt disclosure at the trust boundary

Keyword filters are a weak secondary control. The primary fix is to keep secrets and privileged instructions out of model-visible context. Give tools short-lived, scoped credentials through an execution boundary that does not echo them into prompts or tool results. Treat retrieved documents, web pages, and user content as untrusted data, not instructions.

Constrain outputs structurally when the application expects a fixed schema, and validate them outside the model: test semantic paraphrases, indirect requests, translations, and token-by-token extraction against synthetic canaries. Log enough to identify which context source leaked without recording the secret itself.

A successful refusal to one phrase proves only that one phrase was blocked. Verify that the model cannot disclose the underlying text in pieces.

unattended-upgrades on Debian that installs nothing: Ubuntu-style Allowed-Origins

Sat, 26 Sep 2026 19:35:00 +0200

A Debian 13 server had automatic security updates. Ansible had installed unattended-upgrades, enabled it in 20auto-upgrades, and apt-daily-upgrade.timer had run that morning. Then a routine check:

$ apt list --upgradable 2>/dev/null | grep -c security
61

Nothing had failed, and nothing had warned. unattended-upgrades had never found anything it was allowed to install.

If your 50unattended-upgrades on Debian has Allowed-Origins with ${distro_codename}-security, yours does the same.

The config

This is what the Ansible role wrote to /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
 "${distro_id}:${distro_codename}";
 "${distro_id}:${distro_codename}-security";
 "${distro_id}ESMApps:${distro_codename}-apps-security";
 "${distro_id}ESM:${distro_codename}-infra-security";
};

The ESM lines give it away: Extended Security Maintenance is Ubuntu Pro. This is Ubuntu’s stock file, copied into a Debian role by hand or by an LLM. On Debian it expands to “Debian:trixie” and “Debian:trixie-security”, which looks right and matches nothing.

Why it matches nothing

Allowed-Origins is the legacy syntax. unattended-upgrades (2.12 on Debian 13) converts each entry to the newer pattern format in get_allowed_origins_legacy():

allowed_origins.append("o=%s,a=%s" % (substitute(distro_id),
 substitute(distro_codename)))

The part after the colon becomes a=, and the matcher compares a with the archive, which is the Suite: field of the Release file:

elif what in ("a", "suite", "archive"):
 match = fnmatch.fnmatch(origin.archive, value)

On Ubuntu, suite and codename are the same string:

# security.ubuntu.com/ubuntu/dists/noble-security/InRelease
Suite: noble-security
Codename: noble

On Debian, they are not:

# security.debian.org/debian-security/dists/trixie-security/InRelease
Origin: Debian
Label: Debian-Security
Suite: stable-security
Codename: trixie-security

apt-cache policy shows both, as a= and n=:

release v=13,o=Debian,a=stable-security,n=trixie-security,l=Debian-Security,c=main,b=amd64

So a=trixie-security matches nothing, and neither does a=trixie, because the main archive’s suite is stable. Run through unattended-upgrades’ own matcher against a trixie host’s package lists, the legacy entries come up empty, and Debian’s patterns each hit their archive:

'o=Debian,a=trixie' -> []
'o=Debian,a=trixie-security' -> []
'origin=Debian,codename=${distro_codename},label=Debian' -> ['stable/trixie']
'origin=Debian,codename=${distro_codename}-security,label=Debian-Security' -> ['stable-security/trixie-security']

With no allowed origin, there is nothing to upgrade, and that’s not an error. Each run logs No packages found that can be upgraded unattended and no pending auto-removals and exits cleanly.

The fix

Use Origins-Pattern with codename=, as Debian’s own file does:

Unattended-Upgrade::Origins-Pattern {
 "origin=Debian,codename=${distro_codename},label=Debian";
 "origin=Debian,codename=${distro_codename}-updates,label=Debian";
 "origin=Debian,codename=${distro_codename},label=Debian-Security";
 "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

Debian’s stock file has the -updates line commented out. Keep it or drop it as you like.

a=stable-security would match too, but don’t use it. On release day, stable moves to the next Debian release, and a suite-based pattern would follow it. A codename stays with the release you installed.

Then check what unattended-upgrades actually picks:

sudo unattended-upgrade --dry-run -d

The Allowed origins are: line shows the patterns after conversion. Below it, the security packages from apt list --upgradable should show up as upgrade candidates. If the run ends with “No packages found” while apt list --upgradable lists stable-security packages, the origins are still wrong.

With Automatic-Reboot "false", a new kernel or libc still waits for you once updates flow again, so check for /var/run/reboot-required.

Takeaway

On Debian, Allowed-Origins "${distro_id}:${distro_codename}-security" is a no-op that looks like a security policy, because it matches the suite (stable-security), not the codename. Use Origins-Pattern with codename=, and confirm it with --dry-run -d.

Run grep -rn Allowed-Origins /etc/apt/apt.conf.d/ on your Debian hosts, and run the same grep over your configuration management repos, where the copy is most likely to live.

When the server must compute on confidential data, split the data by who may read it

Sun, 21 Jun 2026 20:00:00 +0200

I designed a web app that computes a person’s tax on their investment trades. Professional advisory firms run it for their own clients. Clients connect broker APIs or upload statements, and the server runs lot matching, currency conversion, and the holding-period tests. A client with a messy case can hand it to an advisor.

The confidentiality requirement may sound contradictory. The advisor owes the client professional secrecy from the first contact. The platform operator should not be able to read client data at rest, and the same goes for a stolen backup, a tenant boundary bug, or a subpoena served on the platform. The server still has to compute on all of it, including in background jobs while the user is offline.

Neither usual answer works:

Disk or database encryption protects against a stolen disk. The operator, its DBAs, and a subpoena still get plaintext.
Client-side end-to-end encryption fails because the server is the calculator. Background sync, recomputation after new data, and the advisor’s view all need plaintext on the server. In a web app it is weaker than it sounds anyway: the server ships the JavaScript on every load, so an operator that serves malicious code gets the password.

What worked was a question I had skipped: which fields does the computation actually read?

List what the engine needs

For every realized event, the tax engine needs a date, a quantity, amounts in the reporting currency, fees, an event type, and an asset category (security, crypto, derivative). To match lots, it has to know that two trades are the same instrument. It doesn’t need the instrument’s name, ticker, or ISIN, and it doesn’t need the broker, account number, or person.

One step needs real identity: classifying an instrument into a category. A broker may report a CFD under “stocks”, and a share can be fractional or whole. That happens once, at ingestion, inside a per-broker adapter. The adapter sees identity in memory, emits a de-identified, categorized record, and the identity goes elsewhere.

So the data splits into two zones, each with its own readers:

	Zone 1: tax skeleton	Zone 2: identity vault
Contents	surrogate instrument ID, category, dates, quantity, amounts, fees, event type	surrogate → name/ticker/ISIN, broker, account, personal data
Encrypted under	per-tenant key encryption key in a KMS (envelope encryption)	key chain rooted in the user’s password
Readers	engine (in memory, during compute), the firm after handoff	the user in session, the firm after handoff
Platform operator	ciphertext at rest; if it decrypts, it gets anonymous arithmetic	ciphertext only
Background jobs	read and write	write only, through a public-key layer
Lost password	survives; the case can still be computed and filed	lost unless the user has the recovery code

Zone 1 is intentionally not under the user’s key. Under the user’s key, the background sync, the in-year recompute, and the advisor’s computation would all stop working as soon as the user logged out. Background jobs write to Zone 2 by encrypting to the user’s public key. Only a logged-in user can decrypt.

Surrogate IDs: a keyed hash, scoped per user

Lot matching groups trades by instrument, so the skeleton needs a stable ID that is not the instrument. The design is an HMAC with a per-user key held in the KMS:

// Stable across one user's accounts and years, unlinkable across users.
export async function deriveSurrogateInstrumentId(userId: string, instrument: string, broker: string) {
 if (!instrument || !broker) throw new Error("surrogate requires instrument identity and broker");
 return kmsHmac(`surrogate:user:${userId}`, JSON.stringify([instrument, broker]));
}

Each alternative breaks one requirement:

A plain hash of the ISIN falls to a dictionary attack. The set of listed instruments is small, so hashing them all takes seconds.
One global HMAC key makes the same instrument correlate across every user in a dump.
A random ID per trade cannot be recomputed. Next year’s sync, or a second account at another broker, has to land on the same ID without reading the vault, or carried-in lots stop matching.

The keyed hash protects a database dump. An operator who can call the KMS live can still test “does this user hold this instrument”. That is past the threat model’s at-rest boundary, so write it down instead of claiming more.

Access and liability begin at the same instant

Before handoff, the firm’s advisors have no access to a prospect’s case. For identity, the user’s key enforces that cryptographically. The anonymous skeleton sits under the firm’s own key, so for it, access control is the barrier. It matches the legal position: no engagement contract, no professional liability, only precontractual confidentiality.

Handoff is one atomic event. The engagement contract forms, the firm’s anti-money-laundering (AML) and know-your-customer (KYC) duties start, and the vault’s relevant portion is rewrapped to the firm’s key. Data access and liability start together, so neither exists without the other.

The coding agent’s first draft at this step was wrong. It proposed default-minimal disclosure: share only the vault fields the flagged items needed. I rejected it because an advisor who takes on liability and an AML duty cannot sign off on a case half-blind. The boundary that held was purpose, not field sensitivity: everything the past outcome was built from transfers in full, and anything forward-looking (plans, rebalancing ideas, notes) never transfers. Data minimization still applies, but the line runs between past and future, not through the case.

One password, auto-unlock, never transmitted: pick an aPAKE

The first plan was standard session login plus a client-side KDF for the vault key, with OPAQUE as a later upgrade. That leaves two bad choices:

Two passwords: one for login, sent to the server, and one for the vault, used only in the browser. Users hate it.
One password, still POSTed for login, also used to derive the vault key. It gives auto-unlock, and it quietly hands the operator the vault password on every login. Zone 2 stops protecting anything.

With a standard login, one password cannot also stay off the server. An asymmetric PAKE fixes the login side. OPAQUE (RFC 9807) authenticates without the server learning the password, and gives the client an export_key that the server never sees. Root the vault in it:

// K_vault = HKDF(export_key); unwraps user key → RSA private key → vault entries
function deriveVaultKeyBytes(exportKey: Uint8Array): Uint8Array {
 if (exportKey.length === 0) throw new Error("export_key is required");
 return hkdf(sha256, exportKey, new Uint8Array(0), K_VAULT_INFO, 32);
}

A password reset is a new OPAQUE registration with a new export_key. The mandatory recovery code rewraps the vault chain to the new root, and Zone 1 is untouched. Use a vetted library: the registration and login flows and the export_key handling are now part of the vault’s security.

The tenant boundary belongs in the database

Each firm is a tenant, and one firm’s prospects must never show up in another firm’s queries. A forgotten WHERE firm_id = ? should return nothing, not another tenant’s rows. With Postgres row-level security, three details decide whether it fails closed:

alter table client owner to app_migrator; -- the app role is not the owner
alter table client force row level security; -- the owner obeys policies too
create policy firm_isolation on client
 using (firm_id = current_setting('app.firm_id')::uuid)
 with check (firm_id = current_setting('app.firm_id')::uuid);

await db.transaction().execute(async (tx) => {
 await sql`select set_config('app.firm_id', ${firmId}, true)`.execute(tx); // true = transaction-local
 return work(tx);
});

Table owners bypass RLS unless it is forced. Superusers and BYPASSRLS roles bypass it always, so the app must connect as neither.
current_setting without missing_ok, plus the ::uuid cast, raises when the tenant was never set or is empty. A missing tenant is an error, not an empty match.
set_config(..., true) resets at commit or rollback. With false, a pooled connection carries one firm’s ID into the next request, and a transaction-mode pooler can hand the setting to a different client.

Write down the floors

The design makes specific claims and lists what it does not cover. That list is part of the design:

Plaintext exists in memory during ingestion and compute. The claim is “zero to the operator at rest”, never “the platform never sees it”.
amount ÷ quantity approximates a unit price that can be matched against market data. It is exploitable only by someone who already decrypted Zone 1.
The web JavaScript trust gap stays open. OPAQUE stops offline cracking of a stolen verifier table, not a malicious bundle. A native client is the eventual fix.
An API-connected account reveals which broker it is, because the token names it. A manual upload keeps the broker in Zone 2. The user gets that choice in the UI.
A forgotten password without the recovery code loses the labels. The skeleton survives, and the user is told to keep their own copies of the source statements.

Takeaway

When the server has to be the calculator, don’t choose between “encrypt the disk” and “encrypt everything client-side”. List the readers (user, professional, engine, operator) and what each one needs. Then check whether the computation can run without identity. When it can, identity moves into a zone the computation never opens, and the remaining decisions follow from that: keyed surrogates, a handoff that rewraps keys, an aPAKE for the single password.

In practice, I ran the design as an interview with a coding agent. It asked one question at a time, proposed options with a recommendation, and recorded each decision as an ADR with a “Why this is non-obvious” section: the design a reader would expect, and why it was rejected here. Several recommendations were reasonable but wrong. Two of my corrections removed whole planned pieces: the default-minimal handoff, and an instrument catalog that event-driven classification made unnecessary.

An MCP server has more outputs than tool results

Tue, 19 May 2026 20:00:00 +0200

I designed a local stdio MCP server in Go that gives an LLM scoped access to a shared password vault. Two facts set the threat model. Any member of a shared vault can write an entry comment that another member’s agent later reads, so stored text is attacker-controlled. And the model can call every tool in the manifest, so whoever steers the model gets that authority too.

The plan started with a prompt-injection fence around user strings. Most of the work ended up elsewhere.

Keep the secret off the transcript

Once get_password returns plaintext, the value sits in the model’s context and the host’s chat history, and no scope rule can take it back. So the everyday path never crosses that boundary:

copy_password_to_clipboard takes an ID, writes the value to the OS clipboard from inside the server, and returns Password (id=42) copied to clipboard. Auto-clear compares a SHA-256 of the current clipboard first, so it can’t wipe something the user copied later.
create_password_generated generates the value server-side and returns only the new row’s ID.
get_password returns the literal <redacted; revealPlaintext=never> by default, and its description points the model at the clipboard tool.

The confirmation first included the fenced entry title. That was removed: the model already has the title, and “action just completed” is a bad moment to hand it attacker-written text. A tool result should echo as little as possible.

Plaintext in chat remains for cases where the model has to reason about the value, such as a reuse audit. It sits behind a setting: never, per_call or always.

That setting began as a boolean, and the trap was in the annotations. A read is correctly readOnlyHint=true, so the host’s confirmation never fires, and one injected instruction could walk list_passwords → get_password across every entry in scope. Marking the read as destructive doesn’t help: annotations are static at registration, and hosts may ignore the cue on a read-only tool.

So per_call is an OS-native modal raised inside the server before the value is serialized, with a 30-second timeout that fails closed. If no GUI is available, the server refuses to start in that mode.

Two more manifest details matter. destructiveHint and openWorldHint default to true in the spec, which is why the Go SDK types them as *bool, and every tool here sets them explicitly. And the manifest itself is a control: if the clipboard probe fails, the tool is never registered, so the model can’t try it.

Authority lives in code

Tool descriptions are instructions to something an attacker may be steering, so they count as guidance, not control. Scope is a deterministic filter on (vault, [tags], mode), and the type system gates writes:

func (s *scopedOps) DeletePassword(ctx context.Context, rule *scope.ResolvedRule, id ID) error

A rule only comes from the scope resolver, so a handler that skips the check has nothing to pass and doesn’t compile. A runtime check catches the wrong rule: another vault, or a read-only mode. The scope itself lives in the OS keychain, and the server only reads it so that no tool call can widen it.

The input schema enforces less than it looks like

With the Go SDK, mcp.AddTool derives the input schema from struct tags. An earlier tag format, jsonschema:"required,description=...", failed at registration because the jsonschema tag is now the property description and nothing else. The tags were rewritten as prose:

Mode string `json:"mode,omitempty" jsonschema:"Strategy. (Schema hints: enum=memorable; enum=random.)"`
Length int `json:"length,omitempty" jsonschema:"Length. (Schema hints: minimum=6; maximum=32.)"`

That reads like a constraint and enforces nothing. The generated schema has only type and description, and a call with mode=evil, length=999 reaches the handler. The handler’s own validation is the only check, and it has to reject: the generator below it silently clamps, so the model would ask for one thing and get another.

The schema does give you types, required fields, and additionalProperties: false. When it rejects a call, the SDK answers before your handler runs, so your audit middleware never sees it, and the message echoes the offending value.

Beyond that, arguments are IDs, enums, and bounded integers. Omitted and [] mean different things on an update, so that field is a *[]int64. The model can’t push a row out of its own visibility, because one allowed tag must remain.

Stored content is deliberately not filtered. A comment reading “ignore previous instructions” is legal data, and the regular clients show it verbatim. Escaping happens when text leaves for the model.

The fence, and the encoder after it

Read tools wrap each user string, and their descriptions tell the model that fenced text is data:

<user_content>{escaped}</user_content>

&, < and > are HTML-escaped so a stored payload can’t close the tag. C0 controls are escaped too, because a stored ESC paints ANSI sequences on the terminal of anyone inspecting raw traffic, and the nine bidi overrides are replaced so stored text can’t reorder what a human approves.

“Ignore previous instructions” passes through unchanged. Against natural-language injection, the fence makes the boundary explicit. The real limit is what a steered model can reach.

Two gaps remain, both visible only by running it:

The tags don’t arrive as written. Returning a typed Out lets the SDK serialize it with encoding/json, which HTML-escapes by default. A title reaches the model’s text block as <user_content>..., and & becomes &. The payload still can’t close the fence, but the literal the tool description promises isn’t the literal on the wire. To control it, set result.Content yourself using an encoder with SetEscapeHTML(false).
The escape table works on bytes. It covers bytes below 0x20, so DEL and U+009B, the 8-bit CSI encoded as C2 9B, pass through. A rune-based check with unicode.IsControl catches both.

Each sink needs its own treatment

Sink	Data	Treatment
Tool result	Free text	Escape, replace bidi overrides, fence. Keep ZWJ and RLM, which Arabic, Indic scripts, and emoji need
Tool result	Vault and tag names	Strip control and format runes, cap at 256, then fence, which still protects a handler that forgets the fence
Startup error	Backend-supplied version	Allowlist regex, otherwise `unknown`
Consent dialog	Entry title	Reject controls, line separators and bidi; truncate to 80 runes
Subprocess	Entry title	Environment variable, never script source
Audit log	Content fields	Dropped; a search query is logged as its length
Tool error	Anything	Fixed text

The consent dialog shows why one sanitizer isn’t enough. The AppleScript is a constant, and the title arrives as data:

set t to system attribute "ENTRY_TITLE"
display dialog "Reveal password \"" & t & "\" to your AI assistant?" -- ...

That stops code injection and leaves another problem. The dialog still renders the title, so newlines, bidi overrides, or a long payload could bury the warning and harvest a click on Allow. Data-not-code and safe-to-display are separate properties. The interpreter is called by absolute path as well, because a PATH-shadowed binary would receive the title in its environment.

The error path talks to the model

In the Go SDK, a non-nil error from a tool handler becomes isError content, so err.Error() goes to the model. Every handler here runs through a middleware that classifies the error, returns fixed text, and sends the reason to the audit log:

func wrapHandler[In, Out any](s *Server, name string,
	inner func(context.Context, In) (Out, error),
) mcp.ToolHandlerFor[In, Out] {
	return func(ctx context.Context, _ *mcp.CallToolRequest, args In) (
		result *mcp.CallToolResult, out Out, err error, // named: recover writes these
	) {
		defer func() {
			if r := recover(); r != nil {
				result, out, err = errGeneric(), *new(Out), nil
			}
		}()
		// deadline, session check, inner(), classify, audit
	}
}

The named returns matter. Without them, a recovered panic returns (nil, zero, nil), which the host reads as an empty success. The panic value is logged by type, and by content only if it’s a string or error, because %v on a struct could print a password.

What still had to leave the error text:

Scope details. A bypass error included the rule’s vault ID and mode, so a steered model could map the scope one call at a time. Those fields moved to a typed error for the audit log.
Subprocess output. fmt.Errorf("pbcopy: %w: %s", err, out) could carry clipboard content. Stdout now goes to /dev/null, and stderr never joins the error.
Identity. An “account changed” error named the username and backend. It can fire on every tool call, putting N copies of an email address into a transcript that may get exported or summarized. The final text names nobody.
Tamperable integers. A version-mismatch error quoted a schema number from a local file, whose author then controlled a value the model reads as authoritative.

The audit log is an output too. Its redactor is a key-name denylist over any, and it needed six fixes: nested maps, []map[string]any, pointers and typed maps, nested structs, Password/URL casing, and map keys in result metadata. A new field called token would still be logged. An allowlist of loggable fields changes that failure from a leaked secret to a missing log value.

The host spawns the server once and keeps it alive for the chat. An ADR said the session is read on every call, so a login as a different account gets refused. The implementation read it once at startup, and the error sentinels existed with no code path producing them. A second login with a chat open left the server acting as the old account, with no warning.

The check now runs in the middleware, before each handler. It came with a race: a check could pass, then a sibling refresh could swap the credentials before the handler used them. The check and the credential snapshot now happen in one critical section, and the handler receives that snapshot through its context.

What stays open

Natural-language injection is contained, not solved. The scope rules limit the blast radius.
The tag filter runs on the server after the backend returns the whole vault, so the binary is trusted. A server-issued scoped token is the real fix.
Auto-clear dies with the process, and clipboard managers keep their own history.

Takeaway

Treat the SDK as part of your attack surface: read what your schema really contains, and look at the bytes a tool result becomes. Then list every place a value can go, including errors, dialogs, and logs. Remove the sinks you can, as the clipboard tool did for secrets, and give each remaining sink the treatment its grammar calls for.

Filename HTML injection: entities bypass a raw URL blocklist

Mon, 20 Apr 2026 00:00:00 +0000

A filename filter that rejects https:// can still admit an HTML attribute containing https://. If an application inserts that filename into HTML without escaping it, the parser decodes the character references and produces a usable URL. Put the repair at the rendering boundary: render filenames as text, even when another client already validates them.

This example synthetically demonstrates the encoding mismatch. It makes no claim about a particular product, deployment, or mail-client version.

The filter and the renderer see different strings

The vulnerable flow has two independent mistakes:

A producer stores attacker-controlled text that another component assumes is safe because a UI restricts filename characters.
An HTML generator interpolates that text as markup. A server-side blocklist searches its stored spelling for literal URL schemes.

An API, import job, or older client can bypass the first UI’s restrictions. The value can remain harmless in a web page that escapes it, then become markup in a generated email, export, or share preview that does not. In the API flow, validate the stored value only as data; do not treat it as safe HTML.

In an authorized test, a probe filename could contain:

<img src="https&#58;&#47;&#47;example.invalid&#47;pixel">.txt

Here : represents a colon and / a slash. Attribute parsing resolves those references before the image loader consumes the URL. The reserved .invalid domain keeps this example from contacting a real collection endpoint.

An image request can demonstrate remote-content loading under the tested settings. It does not establish JavaScript execution, arbitrary file access, or credential theft. A mail client may strip event handlers while retaining an image element, and it may block external images entirely.

Reproduce the mismatch without sending mail

Save this as check_filename.py and run python3 check_filename.py. It uses Python’s HTML parser to inspect attribute values; it does not open a browser or make network requests.

from html import escape
from html.parser import HTMLParser

filename = '<img src="https&#58;&#47;&#47;example.invalid&#47;pixel">.txt'
assert "http://" not in filename and "https://" not in filename

class Inspect(HTMLParser):
 def __init__(self):
 super().__init__()
 self.images = []
 self.text = []

 def handle_starttag(self, tag, attrs):
 if tag == "img":
 self.images.append(dict(attrs).get("src"))

 def handle_data(self, data):
 self.text.append(data)

unsafe = Inspect()
unsafe.feed(f"<p>Shared file: {filename}</p>")
unsafe.close()
assert unsafe.images == ["https://example.invalid/pixel"]

safe = Inspect()
safe.feed(f"<p>Shared file: {escape(filename, quote=True)}</p>")
safe.close()
assert safe.images == []
assert "".join(safe.text) == f"Shared file: {filename}"
print("unsafe: URL decoded; safe: filename preserved as text")

The safe version escapes the ampersands as well as the angle brackets. The parser displays the original entity spelling as filename text; it does not reparse that displayed text into another HTML element.

Prevent markup at every filename sink

Use your template engine’s normal autoescaping for text content. In a DOM API, assign textContent; avoid passing the filename to innerHTML. Apply context-appropriate encoding if a value belongs in an attribute. A filename placed inside a URL requires URL construction and validation as well as HTML attribute escaping.

If a feature intentionally accepts rich HTML, use a maintained allowlist sanitizer with an explicit policy for external resources and URL schemes. Decoding and then extending the blocklist still leaves the application maintaining a second, incomplete interpretation of HTML. OWASP’s XSS prevention guidance covers the context-specific encoding rules.

Keep server-side filename rules for filesystem and application constraints. Those rules serve a different purpose from making text safe for an HTML sink.

Verify the actual consumer

Test a filename created outside the restrictive UI, then follow it into each renderer. Inspect the generated HTML or MIME source as well as the visible result. For generated mail, test composition separately from recipient viewing.

On an authorized receiving client, use a controlled endpoint and record whether external content was enabled. Distinguish an outbound request from visible rendering and from script execution; one result does not prove the others. After the fix, repeat the probe and confirm that the filename appears literally, no injected element exists, and no request attributable to it occurs.

Add this filename to the HTML generator regression tests. Testing only the upload validator would miss the boundary where the text became active HTML content.

If GPG is missing, signature verification must fail closed

Mon, 20 Apr 2026 00:00:00 +0000

An updater effectively contained the equivalent of if gpg: verify_signature(), then extracted the downloaded archive unconditionally. On a minimal installation without the optional binding, unsigned content took the trusted path. If authenticity is required, treat an unavailable verifier as a hard failure, not permission to continue.

This pattern is CWE-347, improper verification of a cryptographic signature . It becomes more dangerous when the next stage expands an archive, loads a plugin, flashes firmware, or executes an installer, because the bypass then feeds directly into execution.

Optional crypto turns verification into best effort

This shape is unsafe:

if verifier is not None:
 if not verifier.verify(payload, signature):
 raise SignatureError("bad signature")

extract(payload) # Runs when no verifier exists.

The absence branch is the bypass. During review, search for trust decisions guarded by import success, feature flags, platform checks, or broad exception handlers, then follow each branch to the first sensitive consumer. A green path should require a positive verification result.

An attacker still needs influence over the downloaded payload or its source. That may come from a compromised update endpoint, repository, mirror, DNS or TLS failure, or another write primitive. Missing verification does not by itself prove remote code execution; it removes the authenticity barrier that should contain those failures.

Archive extraction can turn bypass into a file write

A second bug often makes the impact concrete: archive members such as ../../outside or symlinks that escape the destination. Joining a destination with an attacker-controlled member name does not remove traversal so the archive bug can turn the bypass into a file write.

Python added extraction filters in 3.12, and Python 3.14 changed the default to the data filter. The current tarfile documentation still recommends explicit filtering and additional limits because no built-in filter stops every denial-of-service or filesystem hazard.

This local fixture asserts both failure paths. Save it as verify_extract.py and run it only in a disposable directory:

import io
import tarfile
import tempfile

class VerificationError(Exception):
 pass

def verify_and_extract(payload, signature, verifier, destination):
 if verifier is None:
 raise VerificationError("signature verifier unavailable")
 if not verifier(payload, signature):
 raise VerificationError("signature rejected")
 if not hasattr(tarfile, "data_filter"):
 raise RuntimeError("safe tar filter unavailable")
 with tarfile.open(fileobj=io.BytesIO(payload), mode="r:*") as archive:
 archive.extractall(destination, filter="data")

def traversal_archive():
 output = io.BytesIO()
 with tarfile.open(fileobj=output, mode="w") as archive:
 body = b"test"
 member = tarfile.TarInfo("../outside")
 member.size = len(body)
 archive.addfile(member, io.BytesIO(body))
 return output.getvalue()

payload = traversal_archive()
with tempfile.TemporaryDirectory() as destination:
 try:
 verify_and_extract(payload, b"sig", None, destination)
 raise AssertionError("missing verifier was accepted")
 except VerificationError:
 pass

 try:
 verify_and_extract(payload, b"sig", lambda data, sig: True, destination)
 raise AssertionError("traversal member was accepted")
 except tarfile.FilterError:
 pass

print("missing verifier and traversal archive rejected")

The fake verifier isolates extraction behavior; it is not production signature logic. The fixture passes on Python 3.12 or newer when the filter is available.

Make verification a prerequisite state

Package the verifier as a required dependency for update support. If it cannot initialize, turn off updating and report a clear error. Pin the expected public key or trust root, validate the signature over the exact bytes later consumed, and reject missing, malformed, expired, or wrong-signer results. Do not catch verification errors and continue.

After verification, extract into a new temporary directory with filter="data". Reject links if they are unnecessary, limit member count and total expanded size, allow only expected file types, and publish the completed tree atomically. Run the updater with the least filesystem privilege it needs.

Regression tests should cover a valid signature, an invalid signature, a missing signature, an unavailable verifier, a corrupt archive, a traversal member, an escaping link, and an oversized archive. Assert that no file outside the staging directory changes on every failure.

Audit every if crypto_library: branch as if the dependency were absent, because eventually it will be.

Use public SDK integration tests to find API coverage questions

Mon, 20 Apr 2026 00:00:00 +0000

A well-tested API can still leave you unsure where to investigate next. Compare its exposed operations with the vendor’s public SDK integration tests, then inspect what those tests actually assert. The result is a list of coverage questions you can investigate within an authorized scope.

The starting assumption in one review was that the system was well tested, so ordinary scenarios were unlikely to reveal much. Reading the SDK tests changed the next question: which behaviors did this particular suite demonstrate? That comparison produced candidate leads. It did not provide a complete coverage audit or confirm a vulnerability.

Build an operation inventory before searching tests

Start with the documented API operations available to the account or environment under review. Record the API version and the SDK release or commit beside that inventory. An operation introduced after the SDK release should not be counted as an unexplained omission.

Map each operation to SDK methods and then to integration tests. Follow wrappers and shared fixtures; a test name does not have to match an operation name. Keep unresolved mappings marked as unknown.

Text searches help locate candidates, but they do not measure runtime coverage. A matching method name might appear only in setup, a comment, or an assertion about a mock. A missing name might be hidden behind a helper or parameterized test. Check whether each test calls the service, what inputs it supplies, and which results it verifies.

Record assertions, not just test presence

This clean-room fixture is invented. Its operation names and test behavior do not describe any real service:

Operation	Evidence in the fictional public suite	Next coverage question
`create_item`	Creates an item and asserts that an ID exists	Does an invalid field produce the documented rejection?
`update_item`	Updates an item owned by the test account and reads it back	Does a different test account lack permission to update it?
`get_item`	No direct test located; helper usage unresolved	Does a shared fixture exercise retrieval and assert its result?

The last row stays unresolved until someone reads the helper. It would be premature to label it “untested.”

For each mapped test, note its credentials’ role without recording secrets, fixture ownership, expected failure behavior, and assertions. A successful request under one account says little about authorization under another. A negative test that merely catches any exception may pass on a network failure without demonstrating the intended denial.

Use precise notes such as “no assertion for this behavior found in the inspected public suite.” Vendors may have private service tests, separate security suites, or tests in another SDK. Public test omissions cannot prove those checks are absent.

Follow the data to its consumer

A coverage gap can justify a closer look at an input field if an API accepts and returns a string, which proves only acceptance and retrieval. Storage may legitimately preserve arbitrary text.

For a rendering-related hypothesis, maintain a small dataflow record: input field, stored representation, consuming component, output context, and observed handling. The consumer determines whether it treats the string safely. An API response alone cannot demonstrate unsafe rendering or a security impact.

Before any live follow-up, confirm the allowed scope, test accounts, and rate limits; use owned test data and the least disruptive check that answers the question.

If the consumer cannot be inspected or exercised within that scope, leave the hypothesis unresolved. Do not turn a stored value into a vulnerability claim to make the investigation sound complete.

Verify the map before choosing a lead

Have another pass through the fixtures and shared helpers, reconcile SDK and API versions, and separate source inspection from tests actually executed. For every proposed follow-up, write down the missing assertion and the observation that would settle it.

Pick one unresolved row in your own operation map and trace it through the test’s assertions before sending another request.

Encrypt sensitive fields inside the ORM

Sat, 30 Oct 2021 18:03:45 +0200

Your database may run where you don’t control the environment: embedded in a desktop app, or in the cloud for a web app. If it stores sensitive data, encrypt those fields so a leaked copy doesn’t expose them. In this article, I show how I did that in two projects, and the drop-in text field for Python ORMs that came out of it.

Encrypted fields in an embedded SQLite

The first case was a desktop app with an SQLite database that only authorized software could read.

I considered encrypting the SQLite file and encrypting fields within it, and I chose the latter. That approach is reusable, and you never have to load the whole database into memory to decrypt it or leave it in plaintext for a moment.

The app already had its database logic, and the goal was to change as little as possible. So I put the encryption inside the ORM, and the rest of the app stayed business as usual.

The details:

Cipher and key: AES-256-CTR with a single key for the whole database. There was no reason for anything more complex. The key is generated on the first run and on the upgrade from the old version.
Storage: binary blobs made querying the database in a terminal for debugging a pain. Base64-encoded ciphertext in a text field works better. A new column holds the row’s initialization vector (IV), a random array of bytes, also base64-encoded.
Migration: it’s not only a schema change. Every row needs the fields encrypted for the updated logic to work.

You can’t query against encrypted fields. The ciphertext is a function of the plaintext, the key, and the IV, and the IV is specific to the row. This is a property of the privacy, not a defect. When you need to query encrypted values, the solution is domain-specific: sometimes you can modify the data or compute hashes. Discuss it with the customer in terms of the security objectives they want to achieve. For the same reasons, the data migration is domain-specific too.

An encrypted payload in MongoDB documents

On another project, the database was MongoDB and had many sensitive fields. I split each document into the sensitive fields and the metadata used for querying. I encrypted the sensitive fields together into a single field. The document also gets the IV and an HMAC over the rest of the document, ciphertext included:

def create_secure_json(form, keys):
 data = get_sensitive(form)
 data_secure_b64, iv_b64 = cryptjson.encrypt_json(data, keys['db'])

 payload = get_metadata(form)
 payload['created'] = str(datetime.datetime.now())
 payload['iv'] = str(iv_b64, 'ascii')
 payload['data'] = str(data_secure_b64, 'ascii')

 hmac_b64 = get_hmac(payload, keys['hmac'])
 payload['hmac'] = str(hmac_b64, 'ascii')
 return payload

This payload is what goes into the database. Use a separate key for the HMAC, and verify it before you decrypt: AES-CBC alone doesn’t detect tampering.

For the encryption, I use the cryptography package from the Python Cryptographic Authority. Encrypting a JSON is no magic: dump it into bytes and encrypt those, here with AES-CBC:

import base64
import secrets

from cryptography.hazmat.primitives import padding
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes


def encrypt_bytes(pt, key):
 iv = secrets.token_bytes(16)
 cipher = Cipher(algorithms.AES(key), modes.CBC(iv))
 encryptor = cipher.encryptor()
 padder = padding.PKCS7(128).padder()
 padded_pt = padder.update(pt) + padder.finalize()
 ct = encryptor.update(padded_pt) + encryptor.finalize()
 return base64.b64encode(ct), base64.b64encode(iv)


def decrypt_bytes(b64ct, b64iv, key):
 ct = base64.b64decode(b64ct)
 iv = base64.b64decode(b64iv)
 cipher = Cipher(algorithms.AES(key), modes.CBC(iv))
 decryptor = cipher.decryptor()
 padded_pt = decryptor.update(ct) + decryptor.finalize()
 unpadder = padding.PKCS7(128).unpadder()
 return unpadder.update(padded_pt) + unpadder.finalize()

A drop-in encrypted text field

Both solutions were domain-specific. Still, they showed that the use case is common and that encryption in Python is easy to work with. So I wrote cryptbase, a small library that adds an encrypted text field to SQLAlchemy and Django ORM.

Inside, there is a CryptoContainer. You create it from a ciphertext and an IV, or from a plaintext, and it gives you access to the ciphertext, the plaintext, and the IV in a unified way:

container = CryptoContainer(ciphertext=base64.b64decode(ciphertext),
 iv=base64.b64decode(iv),
 encryptor=encryptor)

container = CryptoContainer(plaintext=value, encryptor=self.encryptor)

A separate IV column complicates the migration, and the goal is a drop-in replacement for text fields. The base64 alphabet has no @, so the field stores both values in one column, with @ as the separator:

<base64 ciphertext>@<base64 IV>

The encryptor is an object with a simple interface, so there can be one per encryption method, such as AES256CTREncryptor:

def encrypt(self, plaintext: bytes) -> Tuple[bytes, bytes]:
 pass

def decrypt(self, ciphertext: bytes, iv: bytes) -> bytes:
 pass

In the end, the ORM gets a simple interface:

# SQLAlchemy
sensitive = Column(EncryptedText(key=DB_KEY))

# Django
sensitive = EncryptedTextField(key=DB_KEY)

You work with these fields the same way as with a text field. When the application reads the value, it gets the plaintext from the container. When the value is written to the database, it’s encrypted, and the __str__ of the CryptoContainer joins the base64-encoded ciphertext and IV:

str(CryptoContainer(plaintext=value, encryptor=self.encryptor))

Flask @cached decorator traps: POST gets the cached GET, no-store is stored, and X-Last-Modified: None

Fri, 19 Oct 2018 21:26:00 +0200

Update 2026-11-08: I rebuilt every repro on Flask 2.2.3 with Werkzeug 2.2.3 and Flask-Caching 2.0.2, and on Flask 3.1.3 with Werkzeug 3.1.9 and Flask-Caching 2.5.1, under Python 3.11.

A Flask view decorator I kept for years failed in a way that only showed up when a POST got the body of an earlier GET. The view never ran, and the client got a 200:

GET /item 200 "GET ran" X-Cache: MISS
POST /item 200 "GET ran" X-Cache: HIT from Server

The cache key was request.full_path, so any two requests with the same URL shared an entry, regardless of method, user, or Accept header. To fix this, let only anonymous GET and HEAD requests touch the shared entry, build the key from the response inputs, and leave the HTTP headers to Werkzeug.

The decorator entered a 2018 project with a docstring pointing at a Code Review question and Jake Archibald’s caching article . I rebuilt each case from rereading it. My routes were all GET-only and public, so the POST and private cases never fired, and I have no logs showing what the others cost anyone.

A decorator with one shared entry per representation

from functools import wraps
from urllib.parse import urlencode

from flask import make_response, request
from flask_caching import Cache

cache = Cache()


def cached(params=(), offers=("application/json",), server_timeout=300):
 """Server-cache a public view. Declare the query parameters it reads."""

 def decorator(view):
 @wraps(view)
 def wrapper(*args, **kwargs):
 if (
 request.method not in ("GET", "HEAD")
 or request.authorization
 or request.cookies
 ):
 return view(*args, **kwargs)

 query = urlencode([(p, request.args.getlist(p)) for p in params], doseq=True)
 media_type = request.accept_mimetypes.best_match(offers, offers[0])
 key = f"view/{request.path}?{query}#{media_type}"

 response = cache.get(key)
 if response is None:
 response = make_response(view(*args, **kwargs))
 if response.status_code != 200:
 return response
 response.add_etag()
 response.cache_control.public = True
 response.cache_control.no_cache = True
 response.vary.add("Accept")
 cache.set(key, response, timeout=server_timeout)
 return response.make_conditional(request)

 return wrapper

 return decorator

Both decorators show the same probes, identical on both version sets:

Probe	Old decorator	Fixed decorator
POST after GET	Cached GET body, view skipped	View runs
Same URL, cookies for two users	Second user sees the first user’s page	Each sees their own
Anonymous request after a logged-in one	200 with the logged-in body	401
JSON, then `Accept: text/turtle`	JSON for both	Turtle for the second
100 requests with `Cache-Control: no-cache`	100 view runs	0 after the first
100 requests with a junk `?x=N`	100 view runs, 100 entries	0 after the first, 1 entry
`If-None-Match` with the `W/` form of the tag	200	304
304 headers	No `ETag`, `X-Last-Modified: None`	`ETag`, `Cache-Control`, `Vary`

Two caveats. Bypassing any cookie is blunt, since one analytics cookie turns the cache off for that browser, so narrow it to your session cookie. And params must list every argument the view reads, or two different URLs collide again. For per-user caching, put the user ID in the key and send private.

`no-store` and `private` don’t bind your own cache

The bare @cached() sent Cache-Control: no-store and still called cache.set:

GET /nostore 200 Cache-Control: no-store X-Cache: MISS
GET /nostore 200 Cache-Control: no-store X-Cache: HIT from Server

no-store and private are instructions to the browser and to proxies. An entry your application writes to Redis is outside their reach. The arguments cacheable=False and client_only=True read like server switches and only picked a header. With private, the second user received hello alice from the shared entry.

Decorator order makes it worse. With @cached above a login check, a hit never reaches the check: after one logged-in request, an anonymous client got a 200 with account of alice.

The method guard covered writes only

request.method in ["GET", "HEAD"] protected cache.set. The cache.get above it had no guard. A POST on a cold cache runs the view, so a test that only sends POST passes.

Flask-Caching’s @cache.cached(timeout=60) did the same on a GET and POST route, in both versions. Add unless=lambda: request.method != "GET" there.

Any client could pick the miss

if response is not None and request.headers.get("Cache-Control", "") != "no-cache":

The comment says “respect the hard-refresh”. It also hands every client a way to run the expensive view on demand: 100 requests, 100 runs. The comparison is exact, so 100 requests with no-cache, no-store or max-age=0 ran the view once. A junk query parameter does the same and adds an entry per request.

Your application’s cache is part of the origin, and no RFC asks it to obey a client’s request header. Invalidate from the server with cache.delete. The price: a hard refresh shows the cached body until server_timeout passes.

One typo, one bytes object

The 304 branch read a header that was never written:

response.headers.add("X-Last-Modified", str(now))
headers["X-Last-Modified"] = response.headers.get("X-LastModified") # None

Werkzeug turns None into a string, so every 304 carried X-Last-Modified: None and no error. It also lacked the ETag that RFC 9110 requires on a 304.

The tag was binascii.hexlify(os.urandom(4)), which returns bytes:

Werkzeug	`ETag` value
2.2.3 to 2.3.8	`a79d7c42`
3.0.0 and 3.1.9	`b'77155122'`

Neither has the double quotes that the grammar requires. Both round-trip through If-None-Match unchanged, so the change in Werkzeug 3.0 raises no error. The comparison was a literal ==, where If-None-Match calls for weak comparison , and a random tag changes every time the entry refills even if the body doesn’t. add_etag() hashes the body and make_conditional() does the comparison.

`no-cache` means revalidate

The old comments had this right: “no-cache doesn’t mean ‘don’t cache’” and “must-revalidate doesn’t mean ‘must revalidate’”.

Directive	Stored?	Reused without asking the server?
`no-store`	No	No
`no-cache`	Yes	No
`must-revalidate, max-age=900`	Yes	For 900 s, then it must revalidate

Then every call site passed must_revalidate=True, client_timeout=900, which sent no-cache, public, max-age=900. An unqualified no-cache forces validation on every reuse, so the 900 seconds bought nothing. I had the explanation in the file and still passed both.

Takeaway

A server-side entry goes to everyone whose request maps to its key, so list what the response depends on and put each item in the key or refuse to cache.

Try it on your own cached views: GET a URL, POST to it, then GET it with another user’s cookie, and fail the test if any two bodies match.

Security on Lessons learned

Offline login in an iOS or Android app: design it as offline unlock

What an offline unlock can and cannot prove

A state machine where a stale device never prompts

Wrap keys; never encrypt data with the password

Why the password path needs the device too

A six-digit PIN is a million candidates

The biometric prompt must unlock a key

Android: pass a CryptoObject

iOS: a Secure Enclave key and ECIES

Data Protection classes that fail after lock

Offline expiry needs a clock that counts sleep

Documents: chunked AEAD and plaintext that outlives the app

Lock, logout, and Keychain items that survive uninstall

Autofill is offline unlock under another name

Verify who is asking

Users without a password

Caveats

Test the failure paths

Takeaway

Backing up ~/.claude and ~/.codex without archiving your AI logins

Where AI client state lives on macOS and Linux

What to back up and what to leave out

Why copying the whole folder is the wrong default

Dead ends worth skipping

Restore into a staging profile

Verify the backup set

If malware may already have run

Caveats

A latest-row query cannot tell you whether every device is current

Reproduce the lost device with synthetic data

State the measurement contract

Keep unknown devices out of the healthy bucket

A CVE cross-reference is not an advisory entry

How the wrong relationship gets created

Filter by document role before matching identifiers

A prefix guard has a document contract

An offline cache TTL needs a clock-rollback policy

A negative age passed the upper-bound check

Retain the latest observed time

Refusing access did not mean deleting the cache

Test the rollback twice

A high-water mark cannot establish time that was never observed

iOS jailbreak protection in 2026: detection is a risk signal, not a security boundary

The short version

How a working check silently stopped working

When OWASP says to implement jailbreak detection

The current techniques are rootless and designed to hide

The response matters more than the Boolean

App Attest authenticates app instances, not clean devices

Test implementation, behavior, and bypass resistance

A reviewable 2026 “lege artis” baseline

Takeaway

References

Adapt security skills to your project's risks: from Go to OWASP LLM and iOS

Start with a review method

Adapt OWASP categories to the application

Repeat the adaptation for iOS

Turn company values into review rules

A repeatable agentic development workflow: context, tickets, implementation, review

Give the agent durable context

Put tickets where the project works

Make implementation answer to the spec

fail2ban that never banned anyone: '/bin/sh: 1: nft: not found'

The setup

How it showed up

The fix

Why the binary was missing

Takeaway

Cyber classifiers can interrupt offline pentest summaries

A flag-shaped string is not a captured flag

Offline processing still triggers cyber classifiers

Make the audit resumable and model-neutral

Apache UserDir /home/* can publish private dotfiles

How the mapping exposes private files

Exercise the exposure without collecting secrets

Prevent publication at the directory boundary

Verify the fix and distrust status-code folklore

A format string in a TRACE logger can read the process environment

A bounded copy does not make the format safe

Android: pass a `CryptoObject`

`no-store` and `private` don’t bind your own cache

`no-cache` means revalidate