Discovered and reported that Fiverr uses Cloudinary to serve sensitive client-worker files (PDFs, designs, documents) via public, unsigned URLs with no authentication or expiration. Points out that Cloudinary natively supports signed/expiring URLs — meaning Fiverr actively chose the insecure option for sensitive communication artifacts.
Characterizes this as 'a configuration checkbox — the digital equivalent of leaving your filing cabinet on the sidewalk because the lock was optional and nobody toggled it on.' Emphasizes that every major cloud storage platform (S3, Cloudinary, Azure Blob) offers signed URL capabilities specifically for this use case, making the oversight inexcusable.
Frames the Fiverr incident as part of a recurring class of vulnerability seen 'dozens of times before' — companies choosing public URLs for convenience and cacheability without considering whether the content is meant to be public. Notes that S3 presigned URLs, Cloudinary authenticated URLs, and Azure SAS tokens all exist because the need for access control is universal, yet companies keep falling into the same trap.
Emphasizes that the exposed files include final work deliverables — designs, documents, code files, business plans — the exact artifacts clients are paying for and expecting to remain confidential. This directly undermines the trust model that a gig marketplace like Fiverr depends on, since clients expect private messaging to actually be private.
A Hacker News user discovered that Fiverr, the freelance gig marketplace with over 4 million active buyers, uses Cloudinary to process and serve PDFs and images exchanged between freelancers and clients in private messages. This includes final work deliverables — designs, documents, code files, business plans — the exact artifacts that clients are paying for and expecting to remain confidential.
The problem: Fiverr configured Cloudinary to serve these files via public, unsigned URLs instead of using Cloudinary's built-in support for signed, expiring URLs. This means every file exchanged through Fiverr's messaging system is accessible to anyone who has or can guess the URL. There's no authentication check, no expiration, no access control. The files sit on Cloudinary's CDN, publicly reachable, indefinitely.
The post, titled "Tell HN: Fiverr left customer files public and searchable," hit 553 points on Hacker News — a signal that this resonated deeply with a community that has seen this exact class of vulnerability dozens of times before.
This is not a sophisticated attack. There's no zero-day, no buffer overflow, no supply chain compromise. This is a configuration checkbox — the digital equivalent of leaving your filing cabinet on the sidewalk because the lock was optional and nobody toggled it on.
Cloudinary, like AWS S3, offers two modes for serving assets: public URLs and signed URLs. Public URLs are stable, cacheable, and convenient for content that's meant to be public — product images on an e-commerce site, blog post thumbnails, marketing assets. Signed URLs add a cryptographic signature and optional expiration, ensuring only authorized parties can access the content within a defined time window. S3 has presigned URLs. Cloudinary has authenticated URLs. Azure Blob Storage has SAS tokens. Every major cloud storage and CDN platform offers this capability because the need is universal.
The pattern Fiverr fell into is distressingly common. During development, someone chooses the simpler integration path — public URLs require no token management, no signature computation, no cache invalidation strategy. The feature ships. It works. Nobody flags it in code review because the Cloudinary docs don't scream "WARNING: THIS IS INSECURE FOR PRIVATE CONTENT" on the public URL examples. Months or years pass. Millions of files accumulate. The exposure compounds silently.
What makes this particularly damaging is the nature of Fiverr's content. Unlike a photo-sharing app where most uploads are intended to be semi-public, Fiverr's messaging attachments are inherently private business transactions. Logo designs before they're trademarked. Business plans shared with a hired consultant. Legal documents sent to a freelance paralegal. Financial spreadsheets given to a bookkeeper. The sensitivity of these files is categorically different from a social media upload.
The HN community reaction was predictable but telling. Developers immediately recognized the pattern because many have either made this mistake themselves or caught it during security reviews. The discussion quickly turned to how widespread this class of misconfiguration is across the SaaS industry — and the consensus was: far more common than anyone is comfortable admitting.
The fix itself is almost trivially simple, which makes the exposure harder to excuse. In Cloudinary's Node.js SDK, the difference between a public and signed URL is essentially one parameter:
```javascript // Public (what Fiverr is doing) cloudinary.url('user-file.pdf', { type: 'upload' })
// Signed (what Fiverr should be doing) cloudinary.url('user-file.pdf', { type: 'authenticated', sign_url: true, expires_at: Math.floor(Date.now()/1000) + 3600 }) ```
The implementation cost is real but manageable: you need to generate signed URLs server-side on each request, which means your frontend can't cache asset URLs indefinitely, and you need to handle URL expiration gracefully in the UI. But these are solved problems. Every team that uses S3 presigned URLs for private content has already built this pattern.
The harder question is remediation for existing files. Millions of already-served public URLs are cached in browsers, bookmarks, link-sharing tools, and potentially search engine indexes. Changing the URL scheme going forward doesn't retroactively protect files that have already been accessed or indexed. Fiverr would need to migrate existing assets to authenticated delivery types in Cloudinary, which effectively invalidates all existing URLs — a breaking change that requires careful coordination with the frontend.
If you use Cloudinary, S3, Azure Blob Storage, GCS, or any CDN for user-uploaded content, ask yourself one question: are any of these files private? If the answer is yes — and it almost always is — verify that you're using signed or authenticated URLs for those assets.
Here's a quick audit checklist:
1. Inventory your upload paths. Every place in your app where a user can upload a file. Profile pictures might be fine as public. Message attachments, invoices, contracts, and work deliverables are not. 2. Check your CDN/storage configuration. Look for `type: 'upload'` (Cloudinary), public bucket policies (S3), or container access levels (Azure). Any private content served via public URLs is a finding. 3. Grep for unsigned URL generation. Search your codebase for calls to your storage SDK that don't include signing parameters. This is a five-minute audit. 4. Test with an unauthenticated browser. Copy a file URL from your app, open an incognito window, paste it. If it loads without authentication, you have the same bug Fiverr has.
The broader lesson is that convenience defaults in storage SDKs are optimized for the common case (public content), not the secure case (private content). SDK authors could do more here — defaulting to signed URLs for uploaded content and requiring an explicit `public: true` flag would catch this class of bug at development time. But until that happens, the burden falls on application developers to understand the security model of every service they integrate.
Fiverr will almost certainly fix this now that it's front-page news. The more interesting question is how many other platforms have the same misconfiguration sitting quietly in production. Cloudinary alone serves over 1 million developers and handles billions of assets. The intersection of "uses Cloudinary for private content" and "didn't enable signed URLs" is unlikely to contain only Fiverr. If you're a security researcher looking for impactful work, this is a pattern worth scanning for across major SaaS platforms — and if you're a developer reading this, your five-minute audit starts now.
Fiverr (gig work/task platform, competitor to Upwork) uses a service called Cloudinary to process PDF/images in messaging, including work products from the worker to client.<p>Besides the PD
→ read on Hacker NewsTop 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.