Application security is no longer a box-ticking exercise – it is the difference between winning enterprise contracts and losing them. This is the story of how Data Mammoth helped a fast-growing fintech secure its payment platform before a single attacker, or a single enterprise auditor, could find a way in.

The client

Our client was a UK-based fintech startup with around 40 employees, building a payment portal that businesses use to collect and reconcile card payments. They had strong product-market fit and a growing customer base – but they were also about to sign their first large enterprise customers, each of whom would put the platform through a rigorous security review before going live. A single serious vulnerability could sink those deals.

The challenge

The team had grown quickly, and security had not kept pace with the code. There had been a near-miss months earlier when a customer reported seeing data that was not theirs – an incident that was patched in a hurry but never fully understood. With enterprise security questionnaires landing and a PCI-aligned audit on the horizon, the founders needed certainty: where were they exposed, how bad was it, and how fast could it be fixed?

How we investigated

We started where every solid application security engagement should: with scope and context, not tools. Over an initial workshop we mapped the platform’s architecture, identified the highest-risk areas – authentication, payment flows, and anything touching cardholder data – and built a lightweight threat model so our testing focused on what actually mattered to the business.

From there we ran a layered assessment:

• Grey-box penetration testing of the live application, aligned to the OWASP Top 10, using both authenticated and unauthenticated accounts.
• Static analysis (SAST) across the codebase to surface insecure patterns at scale.
• Manual secure code review of the authentication, session, and payment logic – the areas where automated tools routinely miss the most damaging flaws.

What we found

The near-miss had not been a fluke. Our testing uncovered a small number of high-impact issues hiding in plain sight:

• An insecure direct object reference (IDOR) that let an authenticated user view another customer’s transactions by changing a single value in a request – the root cause of the earlier incident.
• Stored cross-site scripting (XSS) in the support-ticket feature, which could be used to hijack an administrator’s session.
• Weak token validation in the session layer that did not properly verify how authentication tokens were signed.
• An outdated third-party dependency carrying a publicly known, exploitable vulnerability.

How we fixed it

Finding problems is the easy part. We worked directly with the client’s developers – pairing on fixes rather than throwing a report over the wall – to remediate every issue and, just as importantly, to make sure the same classes of bug could not return:

• Rebuilt access-control checks so every request is authorised against the logged-in user, closing the IDOR.
• Introduced consistent output encoding and input validation to eliminate the XSS.
• Hardened token signing and validation in the session layer.
• Upgraded the vulnerable dependency and added automated dependency scanning to the build.
• Added security checks into their CI pipeline, so risky code is now caught before it ships.

We then re-tested everything to confirm the fixes held under the same attacks that had succeeded before.

The results

The retest came back clean on every previously identified issue. More importantly for the business:

• The platform passed its first enterprise security review without a single critical finding outstanding.
• The deal that depended on that review closed on schedule.
• The team now ships with security gates in place, turning a one-off audit into an ongoing standard.

Frequently asked questions

What is application security?

Application security is the practice of finding and fixing weaknesses in software – web portals, APIs, and mobile apps – before attackers can exploit them. It combines penetration testing, secure code review, and secure development practices so security is built in rather than bolted on.

How long does an application penetration test take?

It depends on the size and complexity of the application, but a focused engagement on a single web platform typically runs from one to three weeks, including scoping, testing, reporting, and a retest of the fixes.

Will testing disrupt our live service?

No. We scope every engagement carefully and, where needed, test against staging environments or during agreed windows so your customers never feel a thing.

Securing customer-facing software often goes hand in hand with building it well from the start – see how we approach custom web application development, or read about our managed IT services. Ready to find out where you stand? Talk to our security team.