How I Found an Internal Compliance Document in Client-Side Code

On a morning coffee, while preparing for a six-hour penetration test, the reporter stumbled upon an internal compliance document within the client-side code of getlynko.com. The company specializes in NFC smart business cards that instantly share a digital profile with a single tap on either iPhone or Android devices. The vulnerability uncovered was a classic Information Disclosure and Broken Access Control, which falls under OWASP Top 10 A01:2025, and is specifically mapped to CWE-200 and CWE-540.

To begin their investigation, the reporter started with the robots.txt file, which provided insight into what the site was trying to hide from crawlers. They found several endpoints, including /api, /admin, and others. The reporter then proceeded to investigate the /admin paths, focusing on /lynko/admin due to its promising name. Upon visiting this path, they were redirected to the /auth endpoint, which prompted them to dig through the source files in Developer Tools.

During their search, they discovered a file named lynko.admin.js in the assets directory, containing a hardcoded Markdown string within a variable. This variable was referenced by a front-end function designed to allow users to download the compliance document on click. However, this function failed to authenticate or authorize the user before granting access, allowing anyone with access to the admin dashboard to download the sensitive document.

The reporter emphasized two critical issues in their findings: sensitive information should never be hardcoded into client-side files and broken access control issues allow unauthorized users to access sensitive information meant for internal users. The vulnerability was addressed and remediated after the reporter reported it. The compliance document now resides on the server, with proper authorization and access controls implemented to ensure only authorized internal users can access it.

The reporter provided several key takeaways from their experience: never hardcode sensitive information or documents into client-side source code, plan what should live on the server versus what should be exposed to users, and always scan code for sensitive information or hard-coded secrets before deployment. They also stressed the importance of embedding security into every stage of the software development life cycle (SDLC) rather than adding it as an afterthought.