Verify a Cloudinary media url is our asset, not just a Cloudinary url

[renrenmimi]

TRUSTED_MEDIA_URL_HOSTS is ["res.cloudinary.com"], and validateTrustedHttpsUrl checked the protocol and the hostname and nothing else.

A hostname proves the bytes are served by Cloudinary. It does not prove they are ours.

The attack

Register a free Cloudinary account. https://res.cloudinary.com/<their-cloud>/image/upload/... passes a host allowlist unchanged. Call createPostCallable directly with that url — without ever requesting an upload signature — and the entire pipeline is skipped: the 10 MB / 80 MB size caps, the per-user petnote/users/{uid} folder, the signature rate limit.

The worse half is ownership. The asset stays under the attacker's control, so anything that survives a moderation pass can be replaced afterwards, at the same url, on every post, avatar, cover image and check-in referencing it. The same primitive lets one user publish another user's asset url as their own media.

The fix

Two checks, and only for res.cloudinary.com:

1. the first path segment is our cloud name
2. the path runs through the petnote/ folder that userFolder() in media.ts creates

api.dicebear.com and lh3.googleusercontent.com are untouched — generated default avatars and Google sign-in photos aren't ours to fingerprint by path, and rejecting them would blank the avatar of every user who never uploaded one.

Two deliberate non-goals

Not enforcing that the folder's uid matches the caller. Family members co-edit a pet's avatar, so uploader and writer are legitimately different people. Reuse inside our own bucket is a far smaller problem than a foreign bucket, and the strict version would break a shipped flow.

isTrustedHttpsUrl stays host-only. It's the read path — getNotificationActor, on triggers as well as callables — and it isn't an authorization decision, it chooses between a stored avatar and a generated default. Ownership is enforced where the url is written. Urls stored before this change are not re-checked; that needs a backfill, not a read-path change.

How the cloud name reaches the validator — and the gap in the tests

Read from process.env.CLOUDINARY_CLOUD_NAME rather than CLOUDINARY_CLOUD_NAME.value(), so shared.ts doesn't have to import a secret param. A bound secret is an env var at runtime.

Eleven callables now bind it — createPost, createPet, updatePet, createMeetup, updateMeetup, addPlace, addLocationPhotos, submitReview, checkIn, ensureUserProfile, updateUserProfile. A callable that reaches the validator without it throws internal rather than degrading to host-only checking, because a silent downgrade would reopen the hole invisibly.

Worth knowing before merge: the emulator tests cannot catch a missing binding. They drive handlers through .run(), which bypasses secret mounting entirely, and setup.ts sets CLOUDINARY_CLOUD_NAME directly — so a callable I forgot would pass CI and fail in production on the first upload. I derived the list by grepping every transitive path to the four validator entry points rather than by testing, and updatePostCallable is deliberately absent (it copies an already-validated petData.avatarUrl and never validates a url itself).

A follow-up worth considering: the cloud name is not actually a secret — it appears in every image url the app serves. Moving it to a plain param alongside CLOUDINARY_FOLDER in platform.ts would remove the binding requirement and this whole class of mistake. That's a config change, so I haven't done it.

Tests

functions/src/__tests__/media-url-ownership.test.ts, 7 tests.

Four fail on the old validator, pass on this one:

× refuses an identical path in someone else's cloud     ← the attack, one line
× refuses our cloud outside the petnote folder
× refuses a foreign cloud in the thumbnail as well as the url
× applies to pet avatars too, not just post media

Three pass on both, as guardrails: our own cloud still accepted, a never-allowed host still rejected, a dicebear avatar still works.

Local run: functions test:emulator 80/80, rules 57/57, lint / build / typecheck:test / typecheck:scripts clean.

Deploy

Functions only — no rules change. The eleven callables gain a secret binding, so they do need redeploying for the check to take effect.

firebase deploy --only functions

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pet-note	Ready	Preview	Sep 4, 2026 7:25am UTC

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 768cf65737

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Require upload delivery before trusting the folder

When Cloudinary fetch delivery is enabled, callers of createPostCallable and the other media-writing callables can still submit a URL such as https://res.cloudinary.com/<our-cloud>/image/fetch/https://attacker.example/petnote/x.jpg. It satisfies both string checks, but Cloudinary serves an attacker-controlled remote asset without using the signed upload pipeline, preserving the size/rate-limit bypass and post-moderation replacement risk this change is intended to close. Validate the Cloudinary resource and delivery segments as an expected image/upload or video/upload URL and verify petnote in the uploaded asset's public ID rather than accepting it anywhere in the pathname.

Useful? React with 👍 / 👎.