This is a disclosure of a vulnerability found in getlynko.com under their VDP programme, which has since been resolved.

Lynko is a UK-based provider of premium NFC (Near Field Communication) smart business cards that instantly share a digital profile, contact details, social links, and booking tools with a single tap on any iPhone or Android device.

The vulnerability discussed below is a classic case of Information Disclosure and Broken Access Control (OWASP Top 10 A01:2025), specifically mapped to CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-540 (Inclusion of Sensitive Information in Source Code).

Prologue

I was casually sipping my morning coffee, mentally prepared for a six-hour pentest (because that’s my threshold) when, within the first fifteen minutes of recon, I discovered something I shouldn’t have been able to

Methodology

Robots.txt: Hunting Hidden Endpoints

Like always, I started by checking robots.txt to get a general idea of what the site was trying to hide from crawlers. There were a bunch of endpoints listed (/api, /admin, and others). To narrow things down, I decided to start with the admin paths.

There were two admin paths:/admin and /lynko/admin. The second one stood out the most and I decided to dig further into it.

Reading JS: Static Code Analysis

Visiting /lynko/admin redirected me to the /auth endpoint. Before touching the login form, I stuck to my recon schedule and started digging through the source files in Developer Tools, looking for JavaScript files that might expose API endpoints or internal logic.

There were plenty of minified JS files in the assets directory and I had no interest in reading through all of them, so I filtered down to files with interesting names, specifically ones containing the word admin. The one that stood out was a file starting with lynko.admin.

Going through it I started to get a picture of what was sitting behind that login portal at /lynko/admin. What wasn't obvious was what came next.

As I scrolled through the code, what initially looked like a developer comment was actually an entire internal compliance document hardcoded as a Markdown string directly inside a variable.

The variable was referenced by a front-end function designed to let users download the compliance document on click. The correct approach is to fetch it from the server only after the user has been authenticated and authorized. This function did neither. Anyone with access to the admin dashboard could download it, and as I had just found out, you didn’t even need dashboard access. Anyone could read the JS file directly and extract the internal compliance document straight from the source.

This exposed two problems:

1. Sensitive information like this should never be hardcoded into a client-side file. It belongs on the server.
2. A broken access control issue allowed an unauthorised user to access the JS file containing sensitive information that was meant strictly for internal users.

Remediation

The vulnerability has been fixed since I reported it. The document now resides on the server as it should, and proper authorisation and access controls have been implemented to ensure only authorised internal users can access it.

Lessons Learned

• Never hardcode sensitive information or documents into client-side source code. Always plan what should live on the server and what should be exposed to users.
• Always scan code for sensitive information or hard-coded secrets before deployment. Security should be embedded into every stage of the SDLC, not bolted on at the end.
• And for fellow testers, this is a good reminder of why recon matters. The most interesting findings often show up before you even touch the application.