API Security Hardening For An Open Banking Platform

Before testing, we needed a complete picture of every API the platform exposed. We combined the official documentation with traffic analysis and code review to build a full inventory of 180 endpoints across four API versions. Nothing was left out of scope, including older API versions.

The inventory revealed several undocumented endpoints left over from earlier development, including an old version of the payments API that was still live and still accepting requests. These forgotten endpoints lacked many of the protections added to newer versions, making them an obvious and attractive target for any attacker looking for an easy way in.

Every endpoint was mapped to the data it handled, the users allowed to call it and the business risk if it failed. This gave the test plan a clear focus, with the most time spent on the endpoints that handled money and personal financial information. Unused and outdated endpoints were retired, shrinking the attack surface before a single partner went live.

Broken authorisation is the most common and damaging API flaw, so it was our main focus. We created test accounts with different roles and permissions, then tried to access each other's data through every single endpoint on the platform. Every endpoint was tested with several different user roles.

Several endpoints checked that a user was logged in but not whether the account or transaction they were requesting actually belonged to them. By simply changing an ID in the request, one customer could view another customer's balances, transaction history and saved payees, a flaw that would have been catastrophic after the public launch.

We worked with the engineering team to add consistent authorisation checks through a shared middleware layer rather than patching each endpoint individually. That approach closed every instance of the flaw and made it much harder to accidentally reintroduce it in future releases. Automated tests now check authorisation on every endpoint with each release, so the same flaw cannot quietly return.

Open banking depends on strong, standards-based authentication between the platform, its partners and end customers. We reviewed the full OAuth and consent flows, token handling and session management against the relevant financial-grade security standards. Every flow was tested from both the partner and customer side.

The review found tokens that stayed valid far longer than necessary, refresh tokens that could be reused after being revoked and a consent screen that could be bypassed in one specific flow. Each of these could have allowed a malicious partner or attacker to keep accessing customer accounts long after permission had been withdrawn by the customer.

Token lifetimes were shortened, revocation was enforced properly across every service and the consent flow was redesigned to close the bypass completely. The authentication model now meets financial-grade standards, which was a key requirement for regulatory approval of the launch. Partners received clear guidance on the updated flows, making the changes smooth for everyone connecting.

Many APIs return more information than the calling app actually needs, trusting the front end to hide the rest. We examined every response to see exactly what data was exposed and whether each field was genuinely required by partners. Every response was reviewed carefully, field by field.

Several endpoints returned full account objects, including internal identifiers, risk scores and details of other account holders on joint accounts. Although partner apps did not display this information, anyone inspecting the traffic could easily read it, creating an unnecessary privacy risk and a potential breach of data protection rules.

We helped the team introduce response schemas that define exactly which fields each endpoint may return. Sensitive internal data is now stripped out by default, reducing the amount of personal information shared with partners by more than half without breaking any existing integration. Partners welcomed the change, as smaller, cleaner responses also made their own integrations simpler to maintain.

Without limits, attackers can hammer an API with millions of requests, guessing passwords or scraping data at scale. We tested how the platform behaved under heavy, automated use and found almost no protection in place across its endpoints. All testing ran safely in a dedicated, isolated environment.

Login and one-time passcode endpoints could be attacked with unlimited guesses, and account lookup endpoints could be used to confirm whether a person held an account with the bank. We simulated credential stuffing attacks using realistic breached password lists to show just how quickly real customer accounts could be compromised this way.

We designed a layered rate limiting model covering users, partners, IP addresses and individual endpoints, with stricter limits on sensitive actions. It was rolled out across all 180 endpoints and tuned carefully so genuine partner traffic was never blocked by mistake. Limits are reviewed every month using real traffic data, keeping protection strong as partner usage grows.

With more than 40 partners connecting, the platform had to assume that some would be less secure than others. We reviewed how partners were onboarded, what they could access and how the platform would respond if one of them was compromised. Onboarding documents and partner contracts were reviewed as well.

All partners had been given the same broad permissions regardless of what their products actually did. We also found that partner credentials were shared by email during onboarding and never rotated, meaning a single leaked message could have given an attacker long-lasting, trusted access to the platform's APIs and customer data.

Partners now receive scoped permissions matched to their approved use case, credentials are issued securely and rotated automatically, and unusual partner behaviour triggers an alert. If a partner is compromised, their access can be suspended in seconds without affecting anyone else. Partner access is reviewed every quarter, with unused permissions removed automatically to keep risk low.

With 23 high-severity findings and a fixed launch date, a traditional report would not have been enough. We embedded two consultants with the engineering team for a focused three-week remediation sprint to get every issue fixed properly. Speed mattered, but so did getting every single fix right.

Findings were prioritised by risk and effort, and our consultants joined daily stand-ups, paired with developers on the trickiest fixes and reviewed code before it was merged. Shared solutions, such as the authorisation middleware and response schemas, fixed whole groups of issues at once instead of one endpoint at a time.

All 23 high-severity issues were fixed within the three-week sprint, alongside most of the medium-severity findings. The engineering team also gained practical API security skills that it now applies to every new feature, reducing the chance of similar issues in future. The shared security components created during the sprint are now used by default in every new API.

Before launch, every fix had to be proven, not just promised. We retested all findings against the final release candidate, confirming that each vulnerability was closed and that no new issues had been introduced during the remediation work. Retesting covered every one of the 180 endpoints once again.

We then produced a formal assessment report for regulators and investors, mapping the platform's controls against the OWASP API Top 10 and relevant open banking standards. The report explained the testing approach, the issues found and the evidence of remediation in clear, non-technical language that decision-makers could easily understand and trust.

The platform received full regulatory sign-off and launched on its original date, with zero critical or high-severity API vulnerabilities remaining. It now runs regular API security testing as part of every major release, keeping its security strong as partners and features grow. Regulators and investors both cited the thoroughness of the assessment as a key reason for their confidence.