When a “Secret” S3 Link Isn’t So Secret: IDOR in a Whistleblowing System

A whistleblowing channel exists for exactly one reason: so a reporter can say what happened without fear of being identified. So what happens when the attachment they upload — a document, a photo, evidence — ends up sitting behind a link that anyone can open, no login required? That's the bug this write-up walks through: a straightforward IDOR that turned an S3 bucket into an open filing cabinet for confidential reports.

Note: identifying details (bucket name, domain, object paths) have been redacted since remediation is still in progress. This post focuses on the vulnerability class and the methodology, not on reproducing it against the live target.

The Target

The application under scope included a whistleblowing mechanism — a form where employees or external parties can submit reports of misconduct, optionally attaching supporting files such as PDFs.

Like most modern web apps, file uploads here were offloaded to an S3 bucket rather than stored on the application server itself. That's a sane architectural choice — if access to the bucket is actually controlled. The question I wanted to answer: once a file is uploaded, who can see it afterward?

Finding the Bug

I filled out the whistleblowing form and attached a harmless test file (Hello world.pdf) just to see how the upload flow behaved. With Burp Suite sitting in the middle, I intercepted the request and looked at the response body.

Sitting right there in the response was a field called attached_file_path — a full, direct S3 URL pointing at the uploaded object:

The server answered:

…and handed back the full PDF, byte for byte. No prompt for credentials, no 403, nothing. The file was served purely because I had the URL — and that URL is handed to the client on every upload, visible to anyone who can intercept traffic, check a browser history, or read a server/proxy access log.

That's the whole bug, and that's exactly what makes it dangerous: it took no exploitation technique more advanced than reading the response.

Why This Matters

It's tempting to file this under "just an IDOR" and move on, but the context is what raises the stakes:

• For the application — the storage model relied entirely on the URL being secret rather than on actual access control. Once a link leaks — through a log, a Referer header, a shared screen, browser history — access is permanent and unauthenticated. There's no revoking it.
• For the reporters — these aren't marketing assets or product screenshots. They're evidence attached to reports of misconduct. If that attachment leaks, it can expose who filed the report and what they reported, which can translate directly into retaliation: job loss, harassment, or worse.
• For the organization — whistleblower protection is a legal and regulatory obligation in most jurisdictions, not just a nice-to-have. A confidentiality failure here isn't only a reputational problem; it can be a compliance one, and it erodes the one thing a whistleblowing channel depends on — trust that people can actually use it safely.

Thanks for reading