Transparent history of every code review.

Caught by Auditor 2 when reviewing the patch produced by Auditor 1. The patched route ran redis.incr(attemptsKey) unconditionally before the timingSafeEqual proof comparison, meaning every correct password access burned the global counter. A paste with maxViews=50 shared with 50 recipients would lock permanently after the 20th correct access, leaving 30 recipients with ERR_PASTE_LOCKED despite knowing the correct password. Fixed by moving the increment to the failure path only: correct accesses no longer touch the counter.

The server trusts cf-connecting-ip as the first-priority IP source. Cloudflare sets this legitimately, but the Vercel origin URL is discoverable via certificate transparency logs (crt.sh), DNS history tools, and Vercel deployment URL patterns. An attacker who finds the Vercel origin bypasses Cloudflare entirely and injects an arbitrary cf-connecting-ip header. Vercel has no reason to strip it. This collapses all IP-based rate limits: anonymous paste creation (3/day becomes unlimited), password brute-force per-IP gate (5/15min becomes bypassed), paste read limits (20/min becomes unlimited). Fixed via Cloudflare Authenticated Origin Pulls, enforcing mTLS at the Vercel origin so any request not arriving through Cloudflare is rejected at the TLS layer.

Every password-protected paste stored passwordProof = HMAC-SHA256(password, passwordSalt) in Redis alongside the ciphertext. The intent was cheap online rate-limiting. The side effect was an offline attack oracle: a GPU running HMAC-SHA256 at ~1 billion operations per second cracks a 4-digit PIN in under 1 millisecond. The 310,000-iteration PBKDF2 key stretching provides no offline protection once the proof is available. Combined with L3 (passwordSalt returned unauthenticated from the public GET endpoint), an attacker with Redis access has everything needed for an instant offline attack. Fixed by removing passwordProof from paste records entirely and relying solely on the existing global Redis attempt counter for brute-force protection.

Both webhook files contained source comments explicitly flagging that LEMONSQUEEZY_WEBHOOK_SECRET was a weak placeholder string, with a note to replace it using `openssl rand -hex 32` before deployment. If production ran with a default or guessable secret, an attacker could compute the correct HMAC-SHA256 signature for a forged body and send a fabricated subscription_created event with meta.custom_data.userId set to any Clerk user ID, triggering syncClerkMetadata with isPro=true. Free Pro access for any account. Fixed: secrets rotated to cryptographically random 32-byte values before deployment.

Every HTTP response included the Sentry org ID in the CSP connect-src directive and the public DSN key in the meta-baggage header. Combined, these gave an attacker the full Sentry ingest URL. An attacker could POST forged error events in a loop, exhausting the project error quota in minutes. Real production errors (crashes, auth failures, security violations) would be silently dropped. Operational visibility is destroyed during the exact moment an incident is happening. Fixed via a Sentry project-level ingest rate limit and routing all Sentry traffic through the existing /monitoring tunnel endpoint, removing the DSN from public response headers entirely.

The CSP report endpoint is public, performs JSON parsing and isNoise() filtering on every call, and always returns 204. There was no rate limiting of any kind. Sustained bombardment consumed Vercel serverless concurrency slots, causing real user requests to queue or fail. Fixed by adding a per-IP sliding window rate limit matching the healthLimit pattern already used in ratelimit.ts.

Both webhook handlers were completely unrated despite being publicly reachable. HMAC-SHA256 signature verification and Postgres idempotency checks ran on every request. Sustained bombardment forced repeated cryptographic operations and database queries. Fixed by adding per-IP rate limits appropriate for legitimate provider delivery rates.

Payment gateway routing (Razorpay vs LemonSqueezy) and pricing tier selection were based on x-vercel-ip-country. This header is set by Vercel edge, but like cf-connecting-ip it can be injected by any attacker who bypasses Cloudflare and hits the Vercel origin directly. An international user could force Indian pricing by spoofing country: IN. Shares the same root cause as C1. Fixed by the same Authenticated Origin Pulls solution: the Vercel origin refuses any connection not arriving through Cloudflare edge.

replaysOnErrorSampleRate was set to 1.0, recording 100% of error-triggering sessions. The paste viewer decrypts content into the DOM client-side. If a JavaScript error fires while decrypted content is displayed (a highlight.js crash, a React re-render exception, a race condition), Sentry Replay captures a DOM snapshot. maskAllText: true is set, but this relies on Sentry's masking implementation being complete and correct. More fundamentally, Replay stores session recordings on Sentry's infrastructure under a separate data pipeline from beforeSend scrubbing. This is a philosophical conflict with the zero-knowledge model regardless of masking. Fixed by disabling Replay for /p/* routes via the shouldSampleForReplay callback.

While encryptedBlob and the IV had proper format validation (isValidBase64Url, exact length checks), passwordSalt and passwordProof were only checked as non-empty strings. No character set validation. No length validation. A malicious paste creator could submit passwordProof: "x" (1 byte). The server stores it. Legitimate recipients compute a real 43-char HMAC-SHA256 output. The length guard in verify-password correctly rejects it, but the paste is permanently broken. After 20 failed attempts from legitimate recipients, the global counter locks the paste for everyone. Fixed by adding isValidBase64Url checks and exact length assertions (43 chars for HMAC-SHA256 output, minimum 16 chars for the salt).

MAX_GLOBAL_PASSWORD_ATTEMPTS was set to 20. Per-IP limit: 5 attempts per 15 minutes. With only 4 distinct IPs (easily available via any VPN), an attacker who knows a paste URL can exhaust the global counter and lock the paste permanently for the intended recipient. The URL only needs to be known or intercepted; the attacker does not need the password. Fixed by raising MAX_GLOBAL_PASSWORD_ATTEMPTS and ensuring the counter only increments on failed attempts (addressed together with PATCH-1).

An authenticated Pro user could call POST /api/checkout again without the server preventing duplicate session creation. No active subscription lookup occurred before issuing a new checkout URL. This polluted Razorpay and LemonSqueezy dashboards with pending sessions and could trigger provider-level fraud detection. Fixed by checking for an existing active subscription and returning 409 if one is found.

Authenticated users could create unlimited pending checkout sessions in rapid succession, burning Razorpay and LemonSqueezy API quota and polluting provider dashboards. Fixed by adding a per-userId sliding window rate limit.

Response time differed measurably between a Redis miss (~2ms), a password-protected hit (~8ms), and a non-password hit (~12ms). An attacker enumerating paste IDs could distinguish "exists" from "does not exist" by timing alone, without a decryption key. Practical impact is low given the 72-bit ID space, but the oracle is real. Fixed by adding artificial response delay normalization.

For password-protected pastes, the public GET endpoint returned passwordSalt to any caller by design (the client needs it for PBKDF2 derivation). Combined with H1 (passwordProof in Redis), this gave an attacker with Redis access both components needed for an instant offline attack: the salt from the free public API and the proof from Redis. Addressed when H1 was resolved by removing passwordProof from paste records entirely.

No CAPTCHA on the sign-up flow. An attacker could create N free accounts, each providing 10 daily paste slots. Clerk has its own bot detection layer but it is not a hard technical gate. Fixed by enabling Clerk bot protection and device-level fingerprinting limits.

Every other sensitive route in the codebase was rate-limited. This one was not. While post-first-delete the DB record is gone and subsequent calls return early, the subscription cancellation block (razorpay.subscriptions.cancel() and cancelSubscription()) fired on every call until the user record was deleted, creating a burst of outbound API calls to payment providers. Fixed by adding a per-userId sliding window limit.

The sanitizeString and sanitizeHtml functions contained: if (typeof window === "undefined") return dirty. Currently harmless because both functions are only called from use client components. But the silent passthrough is a footgun: if either function is ever called from a server component, API route, or utility, DOMPurify is skipped with no warning and the output appears sanitized but is not. Fixed by replacing the silent return with a loud throw that fails fast with a clear error message.

HTML pastes render inside <iframe sandbox="" srcDoc={sanitizeHtml(content)}>. The sandbox attribute correctly blocks JavaScript, but DOMPurify with USE_PROFILES: { html: true } does not strip style blocks or CSS. The parent page CSP does not apply inside sandbox="" iframes (they run with a null origin). A paste creator could embed a CSS tracking pixel: body { background-image: url("https://tracker.attacker.com/hit") }. The browser fires that outbound GET, revealing the viewer's IP address and exact viewing timestamp to the creator's server. Fixed by adding FORBID_TAGS: ["style"] to the sanitizeHtml DOMPurify call for HTML pastes.

The /monitoring route proxies requests to Sentry's ingest endpoint. Low risk because Sentry validates the target DSN server-side and refuses requests for unknown projects. Accepted as a known characteristic of the Sentry tunnel architecture.

The password is held in Zustand in-memory state, not persisted to localStorage or sent anywhere. Browser extensions with broad content script permissions can read in-memory JS state. Not fixable at the application level without hardware security keys. Accepted. Users handling high-sensitivity passwords are advised to use a browser profile with no extensions.

eraseKeyFromUrl is called after decryption completes. During the fetch and decryption phase (roughly 100-500ms), the AES key lives in window.location.hash. The Sentry scrubFragmentFromEvent hook handles the error reporting pipeline. This window is acceptable for most threat models. Accepted as a known characteristic of the zero-knowledge URL fragment architecture.

The Build step env block defined SENTRY_AUTH_TOKEN twice. YAML last-key-wins means the real token was always shadowed by the empty string override. The comment indicated this was intentional (source map upload disabled in CI), but the dead first definition was a silent trap for anyone who later tried to re-enable CI source map uploads. Fixed by removing the dead first definition and keeping only the empty string with an explanatory comment.