In this post, I’ll walk you through how I discovered a way to access original, high-resolution photos from a photoshoot—photos you’re normally required to pay extra for. While this isn’t your typical “hack” with terminal commands and fancy exploits, it does highlight a critical flaw in how some web apps handle access control.
⚠️ Disclaimer: The image below (blurred for privacy) shows watermarked preview photos. I did not access or download photos belonging to others. My actions were limited to my own account
The concept of the web app is simple: after a photo session, you’re given access to an online portfolio. From there, you can select a set number of photos to download—based on your studio package—or purchase additional digital copies or physical prints. But here’s the catch: a single high-res digital copy costs €35. That’s steep, especially when you consider you could print them yourself elsewhere for much cheaper—if you had access to the original files. That’s where I started digging.
Sniffing
Each user’s portfolio is accessed via a URL that includes a portfolio ID and a 4-digit token for “protection.” Out of curiosity, I typed ../../ in the URL path—and to my surprise, I could access a page listing other user portfolios, were you can enter a token. Yep. That easy. While I chose not to explore or open any of them (not my scope, not my interest), the fact that this was even possible is a major red flag in terms of access control and product design.
Since I was only interested in my own files, I opened the browser developer tools to inspect the HTML and network activity. Within 5 minutes, I noticed something interesting:
Each watermarked image had a special CSS class applied to it. By simply removing or modifying that class in the frontend, the watermark disappeared—and the image became fullscreen width. This meant I could screenshot the photo in high quality, but I wanted to go further. If the frontend could render the image in high quality, it meant the full-resolution file was already being loaded in the background.
I didn’t even need to fire up tools like Burp Suite or OWASP ZAP. Just by watching the network tab in my browser’s dev tools while loading the portfolio, I found that each image was being loaded as a blob file—uncompressed and in full resolution.
I downloaded several of them and checked the metadata. They were original quality. And yes, I compared them to legally downloaded versions—no visible difference.
Is This Hacking?
Good question.
I didn’t brute-force any credentials, inject SQL, or exploit a server vulnerability. The files were already delivered to me, unprotected. The only thing “hidden” was the watermark overlay in the frontend, and the lack of a proper download mechanism didn’t stop the original images from being accessible. So in that sense, yes, this is a form of unauthorized access—not through malicious action, but through poor design. To top it off, I also found hardcoded JavaScript functions that kept track of how many downloads a user had left—on the frontend. That means this could easily be manipulated too.
The aftermath
After discovering this issue, I responsibly disclosed the vulnerability to the company and waited 30 days before writing this post. This isn’t meant to shame the developers—it’s a lesson on why frontend-only protection is never enough when dealing with paid digital content. Always assume the user can see, modify, or capture whatever is rendered in their browser.