Case Study: The Free Sign-Up Page Was an Open Door
A small business had outsourced its web application’s development to an offshore team, with a single local technical contact overseeing the work and keeping the app running day to day. When we suggested an application penetration test, the answer was no — more than once.
“We were told it was secure”
This client wasn’t ignoring security. They’d asked their developers about it directly, more than once, and been assured the application was solid. For a while, that assurance was enough. An outside penetration test felt like an unnecessary expense for a problem they’d already been told didn’t exist.
That’s a reasonable position for a small business to take. Most owners aren’t equipped to independently verify a claim like “it’s secure” — they’re trusting the people who built the thing. The problem is that a developer’s confidence and a tester’s evidence aren’t the same thing, and there’s usually no way to tell the difference from the outside.
After a long delay, the client agreed to move forward with an application penetration test.
What our tester found — on the sign-up page
Our lead application penetration tester started where any real attacker would: the parts of the application open to the public. That included the free sign-up wizard — the page anyone on the internet can use to create an account, no invitation or approval required.
While working through the sign-up process, our tester found that a value tied to the new account’s ID could be altered before the account was created. Changing it didn’t just create an odd account — it created an administrator account. No credentials to steal, no insider access needed, and no interaction with the offshore development team’s systems. Just the public sign-up form, used in a way it was never supposed to allow.
From there, the administrator privileges were enough to reach the application’s stored data — all of it, in principle. In practice, our tester pulled a small sample to confirm and document the exposure, rather than downloading everything. Proving the door was open didn’t require walking through the whole house.
Why we remember this project
What made this finding notable wasn’t just the severity — full administrative access from an anonymous sign-up form is about as bad as application security findings get. It’s that this is exactly the kind of flaw a verbal assurance from a development team can’t catch. The offshore developers weren’t being dishonest; they likely believed the application was secure. But belief isn’t a test, and a determined attacker doesn’t ask permission before trying the sign-up form a second, unusual way.
The client’s initial hesitation is one we hear often, and we understand it. A penetration test is a real cost, and it’s natural to want to trust the people who built the software. This engagement is a straightforward illustration of the gap between “our developers say it’s fine” and “someone tried to break it and told us what happened.”
What happened next
We reported the finding immediately, with clear reproduction steps so the client’s technical contact and offshore developers could fix it without ambiguity. The rest of the engagement continued as scoped, and the final report gave the client additional security issues to fix and something they hadn’t had before: independent, evidence-based confirmation of where their application actually stood — not where they’d been told it stood.
If a development team — offshore, in-house, or somewhere in between — has told you your application is secure, an application penetration test is the way to find out if that’s true before someone with worse intentions does. Talk to a founder directly — no sales process, no obligation.
Terry Bradley, CISSP, is the President and Founder of Mile High Cyber, with over 30 years of experience in cybersecurity. A CISSP since 2008, he specializes in penetration testing, vulnerability management, and virtual CISO services, helping small and mid-sized organizations identify, remediate, and verify their most critical security risks.