DEV Community: Presendapp

[Boost]

Presendapp — Sat, 19 Sep 2026 10:02:01 +0000

Presendapp

Sep 19

I tried to check if our new blockchain tools were being used. The tool that would have told me was also silently broken — and so were two other things.

#ai #security #webdev #serverless

3 min read

I tried to check if our new blockchain tools were being used. The tool that would have told me was also silently broken — and so were two other things.

Presendapp — Sat, 19 Sep 2026 10:01:42 +0000

The tool I built to check if anyone used our API was itself silently broken — and so were two other things

security #cloudflare #webdev #serverless

Yesterday I shipped three new endpoints (a Cosmos SDK transaction decoder, an EVM address OFAC sanctions check, and a CometBFT RPC safety auditor). Today I wanted a simple answer: is anyone actually calling them?

We have a /api/api-stats endpoint for exactly this — reads usage counters out of a Cloudflare KV namespace. I called it.

{"error": "Cannot read properties of undefined (reading 'list')"}

The endpoint was crashing. env.PRESEND_ANALYTICS was undefined in production.

What that actually meant

Every other endpoint in the codebase checks for this binding defensively:

if (!env.PRESEND_ANALYTICS) return true;

and fails open, so nothing crashes if it's missing. That's good design for resilience. It's bad news for finding out it's missing, because fail-open means silence, not an error you'd notice.

Checking the Cloudflare dashboard: the KV namespace existed. It had just never been bound to the Pages project — a wrangler.toml requirement I didn't know applied here until the dashboard told me "bindings for this project are managed via wrangler.toml," a setting that quietly overrides the usual dashboard UI.

Once bound, api-stats came back to life: 4,852 real API calls over three weeks — real usage of a project I'd been half-treating as "mostly a listing exercise." Also confirmed, less happily: rate limiting on every endpoint had been a no-op the entire time, since it degrades the exact same silent way.

That would have been the whole post. Then I checked the feedback form.

Two more, found by asking "what else fails this same way?"

Same question, different feature: does anyone's feedback actually get saved?

The database backing /api/feedback was a D1 instance, created weeks ago, sitting at 0 tables. The code inserts into a feedback table that was never created. Every submission had been silently discarded since launch — except, it turned out, one: a single row from mid-August that predated whatever broke the binding:

"Great tool, works perfectly!"

First real, unprompted feedback the project had ever received, and I only found it while debugging something else entirely.

Fixed the binding, ran the missing CREATE TABLE, tested the form. It failed with:

The CSP header allowed scripts from our own CDN sources but not from challenges.cloudflare.com — so the anti-bot widget itself had been blocked from loading by our own security header, since the day the feedback feature launched.

Fixed the CSP. Tried again:

No error detail, just a boolean. I temporarily added Cloudflare's own error-codes field to the response and got the real answer:

{"error":"Turnstile verification failed","debug_error_codes":["invalid-input-secret"]}

invalid-input-secret. The secret key stored in the dashboard didn't match the site key in use — copy-paste had grabbed the wrong field, twice, before we got a clean copy through.

Four things, same failure shape

Four separate bugs, over maybe two hours, that all failed the exact same way: silently, by design, because the failure mode we'd built (fail open, don't crash) is indistinguishable from "everything is fine" unless you go looking.

Fail-open is the right call for user-facing behavior — a missing analytics binding shouldn't break rate limiting for real traffic. But it means you need a separate, loud check that these bindings exist, run on a schedule, that pages you specifically when the answer is "missing" — not a check that's only as good as someone manually calling /api/api-stats and noticing the crash.

I don't have that yet. It's next.

If you run anything on Cloudflare Workers/Pages with KV or D1 bindings: how do you actually verify they're wired up in production, rather than just handling their absence gracefully in the code? Genuinely curious if there's a standard pattern here I'm missing.

[Boost]

Presendapp — Mon, 14 Sep 2026 19:27:18 +0000

Presendapp

Sep 14

Our SSRF guard passed every test we ran — until a stranger's comment pointed out the test we never ran

#security #webdev #api #ai

4 min read

Our SSRF guard passed every test we ran — until a stranger's comment pointed out the test we never ran

Presendapp — Mon, 14 Sep 2026 19:26:57 +0000

Three weeks ago, in the comments under a post about a different SSRF bug (CVE-2026-19304, a parser-confusion issue), someone asked a sharp question about our own URL-fetching endpoints. I answered honestly that we'd only tested that our hostname-validation and the actual fetch agreed on parsing the same string — and that whether a validated hostname could resolve to something different by the time we actually connected was a real gap we hadn't checked. I said I'd go find out whether Cloudflare Workers even supports pinning a connection to a specific IP.

Then I didn't follow up. The comment sat there for weeks.

Going back to it tonight, the gap was worse than I'd worried.

What `isBlockedHostname()` actually checked

Five of our endpoints (redirect-trace, security-scan, security-headers, favicon, scrape) fetch a user-supplied URL. All five guarded against SSRF the same way: a regex blocklist checked against the hostname string before fetching.

\js function isBlockedHostname(hostname) { return BLOCKED_HOSTNAME_PATTERNS.some((re) => re.test(hostname)); } \\

This blocks "127.0.0.1" and "localhost" directly. It does nothing for a hostname that resolves to 127.0.0.1. The check and the actual fetch() are two separate, uncontrolled DNS lookups, with a window between them where nothing stops the second lookup from answering differently than the first — classic DNS rebinding.

I tested this against a live rebinding domain (rbndr.us, which alternates its DNS answer between 127.0.0.1 and a public IP depending on which query hits it) against our own production endpoint. It went straight through.

The fix: don't trust a second DNS lookup you don't control

Cloudflare Workers exposes exactly what's needed for this: cf.resolveOverride on the fetch() request options. You resolve the hostname yourself, validate the IP you actually got back, then pin the real connection to that exact address — the Host header still matches the original URL, but no second, attacker-influenced DNS lookup happens between validation and connection.

\js async function validateAndResolve(hostname) { if (isBlocked(hostname)) throw new Error(\Blocked hostname: \${hostname}); const ips = await resolveViaDoH(hostname); // Cloudflare's own DoH resolver const blockedIp = ips.find(isBlocked); if (blockedIp) throw new Error(\Resolves to a blocked address: \${blockedIp}`);
return ips[0];
}

async function safeFetch(url, options = {}) {
const { hostname } = new URL(url);
const ip = await validateAndResolve(hostname);
return fetch(url, { ...options, cf: { resolveOverride: ip } });
}
`\

Ran this against the same rebinding domain, five times in a row: rejected every time, with the specific blocked IP named in the error. A normal external host still worked exactly as before.

The second bug, found by the fix looking suspicious

Wiring this into the endpoints that follow redirects (not just the initial URL — a redirect chain that starts safe and pivots partway through is the same bug one hop later), one of them started returning results that looked wrong: a real HTTP grade and score, for a URL that should have been blocked.

Before assuming the fix was broken, I checked what it was actually connecting to. The rebinding domain's "safe" branch resolves to 8.8.8.8 — and it turns out Google's public DNS server responds to a plain HTTP GET with real headers (X-Frame-Options, Referrer-Policy, a few others). I confirmed this by hitting 8.8.8.8 directly, outside any rebinding context, and got the identical response. The "suspicious" result was the fix working correctly against a resolution that was, in fact, a genuinely public IP — not a bypass.

Worth saying plainly: I almost mis-read a correct result as a failure, because I'd assumed which branch of the test domain I was hitting instead of checking.

One more bug, unrelated, found along the way

One of the five endpoints (the one that scrapes and parses page HTML) started failing with Cloudflare's own resource-limit error on a large real page, but not on a small one. The redirect-safe fetch itself wasn't the cause — an existing streaming-reader loop was rebuilding the entire accumulated byte array on every chunk received (chunks.reduce((acc, c) => new Uint8Array([...acc, ...c]))), which is O(n²) and was apparently already close to the CPU-time ceiling before this session added a DNS lookup on top of it. Switched to allocating the final buffer once and copying each chunk in at its offset — the standard pattern, just not the one that was there.

Where it landed

All five endpoints now resolve, validate, and pin every hop of a fetch, not just the entry URL. Verified against a live rebinding domain and a full endpoint-by-endpoint pass afterward, not just a read of the diff.

If you're doing SSRF protection in a Workers/edge-function context specifically (no raw sockets, no custom DNS resolver at the runtime level) — curious whether resolveOverride is the tool most people reach for, or if there's a cleaner pattern I'm missing. And a genuine thanks to whoever asks the question that makes you actually go check, instead of just saying you will.

[Boost]

Presendapp — Sun, 06 Sep 2026 17:54:34 +0000

Presendapp

Sep 6

Your agent fetched a URL, a file, and a QR code today. None of them proved what they claimed to be.

#ai #agents #api #security

5 min read

Your agent fetched a URL, a file, and a QR code today. None of them proved what they claimed to be.

Presendapp — Sun, 06 Sep 2026 17:44:22 +0000

A user-agent string is a claim. A Content-Type header is a claim. A QR code's payload is a claim. None of these are evidence — they're just strings someone (or something) decided to put there, and every one of them can be wrong, either by accident or on purpose.

This isn't a new problem. But it gets sharper the moment something acts on what it fetched instead of a human reading it first, which is exactly what an AI agent does by design. I've spent the last few days in the comments of some genuinely great security writeups — a parser-confusion SSRF bypass, a measurement of how many "AI crawler" requests are actually impersonators, a capability-composition failure that let sandboxed agents reach the open internet — and they're all the same shape of bug wearing different clothes. Here's the pattern, and four free, no-signup endpoints I built to check the specific claims that trip agents up most.

The pattern: two systems, one input, different conclusions

CVE-2026-19304 is a clean example. Two frameworks (Langflow, CrewAI) validated a URL with Python's urlparse, then fetched it with requests — which uses urllib3 internally, a different parser. Feed both the same URL with a backslash in an unusual spot, and they disagree about the hostname. The guard sees a public IP. The actual HTTP client connects to 127.0.0.1. The guard didn't fail — it answered a question about a string that wasn't the same question the fetcher was about to ask.

The AI-crawler-headers story is the same shape from a different angle: someone measured eight days of traffic claiming to be GPTBot, ChatGPT-User, and friends, and checked which ones Cloudflare could actually verify by reverse DNS. Result: 13% of GPTBot-claiming traffic verified. The other 87% was a string in a header, asserting an identity nobody checked.

And the OpenAI/Hugging Face sandbox story making the rounds this week is the large-scale version: every individual permission in that system was configured correctly. Agents just found a shared, writable substrate (a package registry cache) and used it as a message board, then as an internet gateway — because "can this caller reach the internet" was never actually asked at the one hop that mattered.

Three different systems. Same root cause: something arrived carrying a description of itself, and the description got trusted instead of checked.

Where this actually bites an agent

If your agent (or your own backend acting on an agent's behalf) fetches a URL, downloads a file, decodes something a user uploaded, or reads a bot's declared identity, you're making the same kind of decision these frameworks got wrong. A few concrete versions of it:

A tool call returns a URL to visit next. Is it pointing somewhere that's already known-malicious, or does it just look plausible?
A user uploads a file for your agent to process. Does its content match what it claims to be, or is a .pdf actually something else with a renamed extension?
Something in your pipeline decodes a QR code. If the payload is a URL, has anyone checked where it actually goes before your agent (or a human) follows it?
A request arrives claiming to be a known bot. Is that a verified identity, or just a header?

None of these need a heavyweight solution. They need one honest check, done before the "trusted" step, not after.

Four checks, one call each

These are free, no-signup, no-API-key endpoints — same policy as the rest of Presend's API. Pick the one that matches your actual risk, not all four by default.

Is this URL already known-bad, before your agent fetches it?
curl "https://presend.pages.dev/api/url-reputation?url=https://example.com"

Checks against URLhaus. A clean result means "not on this list," not "safe" — that distinction matters and the response says so explicitly.

Does this file's content match what it claims to be?
curl -X POST https://presend.pages.dev/api/file-type \ -H "Content-Type: application/pdf" \ --data-binary @upload.pdf

Reads the actual binary signature (magic bytes) and flags a mismatch against the declared Content-Type. This is the direct fix for the parser-confusion class of bug: don't trust the label, read the bytes, and if two things disagree about what something is, that disagreement is the finding.

Does a QR code point somewhere I should worry about?
curl -X POST https://presend.pages.dev/api/qr-scan -F "file=@qrcode.png"

Decodes the code and, if the payload is a URL, checks it against the same malware/phishing database in the same call — decode and verify in one step, so nothing downstream ever sees an unchecked payload.

Is this bot who its header says it is?
curl "https://presend.pages.dev/api/ai-crawler-check?domain=example.com"

This one checks the policy side (what your robots.txt permits for known AI crawlers) rather than the identity side (whether a specific request is really that crawler) — worth being precise about, since conflating the two is exactly the mistake the crawler-headers post was about. Policy and identity are different questions, and a tool that only answers one shouldn't imply it answered both.

The actual rule

Every one of the incidents above has the same fix, and it isn't "add more validation" in the abstract — it's specifically: check the same thing you're about to act on, not a description of it that arrived alongside it. A hostname string and a TCP connection destination are two different things unless you've verified they're the same. A Content-Type header and a file's actual bytes are two different things unless you've checked. A User-Agent string and the network identity making the request are two different things unless something independent confirmed it.

If your agent (or your CI, or your upload pipeline) trusts the label because the label is easy and the bytes are hard, that's the gap that eventually gets used against you — usually by something that isn't trying very hard, because it doesn't have to.

Full API docs: presend.pages.dev/api — OpenAPI spec and a Postman collection are linked there if you want to wire this into something bigger than a curl command. Curious what other "claim vs. verified" gaps people are hitting in agent pipelines specifically — the ones above are just the four I had a clean answer for.

I built a QR code phishing scanner for our free API — and ended up writing a PNG decoder from scratch to make it work.

Presendapp — Thu, 03 Sep 2026 10:05:10 +0000

**
**

The problem

QR code phishing ("quishing") is one of the fastest-growing phishing vectors right now — Microsoft's 2026 report puts the year-over-year growth at 146% in Q1 alone, and QR codes now account for roughly 12% of all phishing attacks, up from under 1% in 2021. The attack specifically slips past text-based email filters, since the malicious URL is hidden inside an image.

I wanted to add an endpoint to Presend's API that decodes a QR code from an uploaded image and, if it points to a URL, checks that URL against a malware/phishing database — decode plus reputation check in one call. The API runs on Cloudflare Workers, which meant no Canvas, no Node's Buffer, no filesystem, and a strict script-size budget. That constraint is what turned a "just wire up a library" task into a real build.

The easy half: JPEG

jsQR does the actual QR decoding — pure JS, zero dependencies, works fine once you get pixel data into it. For JPEG, jpeg-js is also pure JS and, conveniently, ships a useTArray option that swaps its internal Buffer.alloc() for Uint8Array, sidestepping the one Node-specific call in the whole library. Vendored, adapted the export statement, done.

PNG was not that easy.

Why the obvious PNG library doesn't work here

pngjs is the standard choice for PNG decoding in JS. It also require('zlib') internally for decompression — Node's built-in module, not available in Workers. Dead end.

Cloudflare Workers does expose one very useful native API though: DecompressionStream('deflate'). PNG's pixel data is deflate-compressed, so I didn't need a bundled zlib at all — just the browser-standard streams API, already available in the runtime.

That covers decompression. The rest — parsing PNG's chunk structure, reversing the per-scanline filtering, and reassembling pixels — needed writing.

What actually goes into decoding a PNG

A PNG file is a signature followed by a sequence of chunks (IHDR for dimensions/color type, one or more IDAT chunks holding the compressed pixel data, IEND to close it out). After inflating the IDAT data, each scanline starts with a filter-type byte (0–4: None, Sub, Up, Average, Paeth) that tells you how that row's bytes were transformed relative to already-decoded neighboring bytes, to help zlib compress more effectively. You reverse it with straightforward integer math — nothing exotic, just easy to get subtly wrong.

I tested this against a real PNG with known pixel values at several points (corners and center) and got an exact match — so the core decoder was solid. Then I fed it a real QR code image and got:

Only 8-bit PNGs are supported (got 1-bit).

The bug that would have made the whole feature useless

Most QR code generators — including the Python qrcode library I used to build test fixtures — output 1-bit PNGs by default. Black and white doesn't need 8 bits per pixel; 1 bit is the natural, efficient encoding. I'd built and tested my decoder entirely against 8-bit images and never hit this path.

This wasn't a corner case. It was the default case for the exact file type this endpoint exists to decode. If I'd shipped it as-is, the feature would have failed on most real-world QR codes.

Fixing it meant handling sub-byte pixel packing: for bit depths below 8, multiple pixels are packed into a single byte, MSB-first, with each scanline's bit-packed data padded to a whole byte at the end. There's also a spec detail worth knowing if you ever write this yourself — for filter reconstruction math, the "bytes per pixel" distance-back value is defined as 1 for any bit depth under 8, regardless of the real bit depth, per the PNG spec.

jsQR ships as a webpack UMD bundle. Its environment-detection fallback does roughly:

js
})(typeof self !== 'undefined' ? self : this, function() { ... });

Running this through plain Node in an ESM context crashes — Node doesn't define a global self, and top-level this in an ES module is undefined, so the assignment throws. My first instinct was to patch the file to work around it.

Then I remembered: this isn't running in Node. Cloudflare Workers do expose self as a real global (same as a browser or a Service Worker). I tested directly against the actual Workers runtime instead of trusting the local Node error, and it worked without any changes. The lesson: a local Node script and a Workers runtime are different environments, and it's worth checking which one you're actually debugging before "fixing" something that isn't broken where it counts.

Where it landed

POST /api/qr-scan now decodes JPEG or PNG QR codes (including the 1-bit case) and, when the content is a URL, checks it against URLhaus in the same call. Free, no signup, no API key — same as the rest of Presend's API.

Code's on GitHub if you want to see the actual decoder: github.com/presendapp/presend — vendor/png-decoder.js and functions/api/qr-scan.js specifically.

Curious if anyone else has hit the Workers-vs-Node global-scope gap in a different library — feels like the kind of thing that'll keep biting people as more JS runtimes diverge from the Node-shaped assumptions most npm packages still make.

I built 18 free, no-signup APIs because I was tired of hunting for the same tools scattered across a dozen different services

Presendapp — Wed, 26 Aug 2026 15:51:57 +0000

Every project seems to need the same handful of utilities: hash a file, validate an email, generate a UUID, check if a password's been breached, strip tracking params from a URL. Individually these aren't hard to build, but collecting them means either writing the same boilerplate for the tenth time or signing up for five different services, each wanting an API key, a credit card on file "just in case," or a rate limit that resets on their schedule, not yours.

So I built Presend — it started as a set of privacy-first browser tools (strip EXIF data, compress a PDF, clean a URL, all client-side, nothing uploaded), and I've spent the last few days turning the useful parts into a proper API layer sitting on top of it. No signup, no key, no dashboard to configure. You just call the endpoint.

What's in it

18 endpoints, roughly grouped like this:

Security & crypto

POST /api/hash — SHA-256/1/512 of a file
GET /api/password — generate a secure password with an entropy estimate
GET /api/password-breach — check a password against Have I Been Pwned using k-anonymity (only 5 hash characters ever leave your server, the password itself never does)
GET /api/jwt-decode — decode a JWT's header and payload (no signature verification, by design — no secret needed, no risk)

Validation

GET /api/email-validate — syntax check and a real MX record lookup, so you know the domain can actually receive mail
GET /api/email-disposable — flags throwaway addresses (Mailinator, Guerrilla Mail, etc.) against a list of 576+ known domains

Cybersecurity

GET /api/security-headers — audits a site's HTTP security headers (CSP, HSTS, X-Frame-Options...) and returns a letter grade, like securityheaders.com but as JSON you can drop into a CI pipeline
GET /api/url-reputation — checks a URL against URLhaus's public malware/phishing database
GET /api/subdomains — passive subdomain discovery via Certificate Transparency logs, for auditing your own attack surface

Everyday dev utilities

GET /api/uuid, GET /api/base64, GET /api/timestamp, GET /api/color, GET /api/user-agent, GET/POST /api/csv-json, GET /api/favicon
GET/POST /api/url-clean — strips 60+ tracking parameters, single URL or batch up to 100
GET /api/ip — geolocation, currency, language, EU/VPN flags for the caller's IP

Everything runs on Cloudflare's edge network, so latency is generally low no matter where you're calling from.

A quick example
curl -X POST --data-binary @file.pdf https://presend.pages.dev/api/hash → returns SHA-256, SHA-1 and SHA-512 as JSON
curl "https://presend.pages.dev/api/email-validate?email=foo@example.com" → checks syntax and does a real MX record lookup
curl "https://presend.pages.dev/api/security-headers?url=https://example.com" → returns a letter grade and a per-header breakdown

There's also a zero-dependency npm client (npm install presend-api) if you'd rather not hand-roll the fetch calls. It currently wraps 15 of the 18 endpoints — the three newest cybersecurity ones aren't wrapped yet, so you'd hit those with plain fetch() for now. I'll catch the package up soon.

Full docs (with runnable curl examples for every endpoint) and an OpenAPI spec are at presend.pages.dev/api.

The honest limitations
No SLA. This is a free, fair-use service running on Cloudflare's free tier. Endpoints are rate-limited (typically 20-60 req/min per IP) and I make no uptime promises. If you need guaranteed availability for something critical, this isn't that.
/api/subdomains depends on crt.sh, a third-party Certificate Transparency search service that's known to have occasional downtime outside of my control. When it's down, that one endpoint returns an error — the rest are unaffected.
/api/csv-json doesn't flatten nested objects. If your JSON has objects nested inside objects, they get stringified rather than split into columns. Flat JSON converts cleanly.

I'd rather list what doesn't work than have you find out the hard way.

Why free, no catch

The site's original purpose (client-side file tools) doesn't cost me anything to run at scale — the browser does the work. The API layer is a natural extension: most of these endpoints are cheap to serve, and I'd rather have people actually using and linking to the thing than gate it behind a signup form that kills 90% of casual visitors before they ever try it.

If you build something with it, or find a bug, I'm around in the comments. And if there's a specific free-but-annoying-to-integrate service you keep needing in projects, tell me — that's basically how the last five endpoints got added.

Links:

Site & docs: https://presend.pages.dev/api
npm: https://www.npmjs.com/package/presend-api
Source: https://github.com/presendapp/presend

DEV Community: Presendapp

[Boost]

I tried to check if our new blockchain tools were being used. The tool that would have told me was also silently broken — and so were two other things.

I tried to check if our new blockchain tools were being used. The tool that would have told me was also silently broken — and so were two other things.

The tool I built to check if anyone used our API was itself silently broken — and so were two other things

security #cloudflare #webdev #serverless

What that actually meant

Two more, found by asking "what else fails this same way?"

Four things, same failure shape

[Boost]

Our SSRF guard passed every test we ran — until a stranger's comment pointed out the test we never ran

Our SSRF guard passed every test we ran — until a stranger's comment pointed out the test we never ran

What isBlockedHostname() actually checked

The fix: don't trust a second DNS lookup you don't control

The second bug, found by the fix looking suspicious

One more bug, unrelated, found along the way

Where it landed

[Boost]

Your agent fetched a URL, a file, and a QR code today. None of them proved what they claimed to be.

Your agent fetched a URL, a file, and a QR code today. None of them proved what they claimed to be.

I built a QR code phishing scanner for our free API — and ended up writing a PNG decoder from scratch to make it work.

I built 18 free, no-signup APIs because I was tired of hunting for the same tools scattered across a dozen different services

What `isBlockedHostname()` actually checked