API Penetration Testing for Banks and Fintech: Endpoints, Tokens, and Partner Integrations
If an API of yours moves money or hands out customer data, this page is for you. That covers banks and fintechs, and just as much the insurer with a claims API, the lender with a partner portal and the payments company with a mobile backend. Chances are your API has been through a scanner and a code review, and the reports came back clean. The question those reports can’t answer is whether one customer, or one partner, can make the API act on somebody else’s account. An API penetration test is how you find out before someone else does.
Start with the endpoints nobody listed
In one engagement the client’s documentation listed 84 API endpoints. We found 121. Among them were flaws that let users view other people’s balances and trigger reversals they should never have been able to reach. When we retested, the critical issues were closed. You can read the API security testing case study for the rest.
A gap like that is easy to end up with. APIs grow by release, an old version is easy to leave running, and the document that describes them runs a little behind the system. So scope is the first thing we work out with you, in writing: the customer-facing APIs behind your web and mobile apps, the partner and open banking APIs, and the internal service APIs behind both. A review that starts from the list you have can only be as complete as the list.
Tokens, and what a signature really proves
Most of an API’s security rests on small objects passed back and forth: access tokens, session tokens, signed requests. We spend a lot of time on them. How long does a token stay good after it should have stopped? Does one issued to a customer also work on another customer’s data? And if an ordinary user changes a single field in a request, can they reach an admin action?
Signatures deserve a harder look than they usually get. A signature tells you a request came from the partner who holds the key. It doesn’t tell you whether you’ve seen that request before. In the open banking API penetration test of 27 endpoints for a bank, we found that signed requests could be replayed, which means a request that was valid once could be sent again and still be accepted.
Whose money is this request about?
The bugs that worry us most aren’t about getting in. The caller is logged in, the token is valid, the request is well formed, and the API still does something it shouldn’t. This is what people call object-level authorization: the check that the account named in the request really belongs to the person asking.
In that same 27-endpoint test, one flaw let a user divert funds from another account. The critical chain was fixed in 4 days.
A scanner rarely flags this kind of problem, because from where it sits everything looks fine. It gets a correct answer to a correct request. It has no way of knowing that account 1042 isn’t yours. A tester has to work that out, by using the API the way a customer does and then the way an attacker would, trying the requests neither should be allowed to make.
The partner on the other side
Open banking and payment APIs have a second reader: the partner connecting to you. You can’t see inside their systems, and they can’t see inside yours. We test your side of the connection, from the position of a partner that is careless or one whose key has been stolen. What sits on the partner’s side is out of scope unless it’s in the written agreement, and we say so up front.
Testing while the service runs
Many of the APIs we test are live, or about to be. The rules are agreed in writing before we start. Testing is paced so live systems keep running, and anything that could affect availability is agreed with you first.
What you hold at the end
Each finding comes with the request that triggers it and the response that proves it, so an engineer can reproduce it and your auditor can see what was actually tested. Every finding is proven. If we can’t show it’s real, it isn’t in the report. The report arrives within 10 business days of testing, and a retest is included, so you can show the fixes held. Leadership gets a plain summary of what it means for the business, in the same document.
In the open-banking engagement above, the auditor accepted the evidence. That is what happened in that engagement; whether an auditor accepts any particular report is the auditor’s decision. Where an API sits in the cardholder data environment, PCI DSS requirement 11.4 is the penetration testing requirement, and the report is evidence toward it. Our penetration testing for compliance guide covers what auditors usually look for. For how an engagement runs from the first call to the retest, see the penetration testing page.
What this page doesn’t cover
This isn’t load or stress testing. It isn’t a line-by-line source code review either; that’s a separate service. Anything outside the rules we agree in writing is out too. If your risk is mostly in the screens people click through rather than in the API behind them, web application penetration testing is the better starting point.
Questions we get about API testing
How is this different from a web application test? A web application test follows what people do in a browser: logging in, filling in forms, moving between roles. An API test goes straight to the requests underneath, including ones no screen ever sends. Some APIs expose functions no screen offers, so many teams test both. If your scope only needs one, we’ll say so while we scope it.
Can you test an API that has no documentation, or an old one? Yes. Where a document exists we use it as a starting point and check it against what the system actually answers to. Where there isn’t one, we map the API ourselves first.
Can we test before a partner connects? You can, and it’s the better time. In a digital bank’s payment module, 23 endpoints were tested, the critical issues were fixed in 3 days, the retest confirmed them, and the launch went ahead on the planned date. The payment module case study has the rest.
Doesn’t our API gateway or WAF already cover this? It covers a lot. A gateway typically checks that a request is well formed, that the caller is known and that traffic stays within limits. It doesn’t know whose account the request is for. That check lives in your application, and it’s the one we try to break.
Talk it through first
If you’re deciding what to test, or whether to test now, a conversation is an easier first step than a purchase order. Book a free 90-minute scoping session and we’ll go through your APIs, your partners and your launch date. We can sign an NDA before you share any details, and you’ll have a scoped proposal within 24 hours. These API penetration testing services work the same way whatever your sector. If your APIs sit in banking and financial services or in fintech and digital payments, the open banking API security page goes deeper on partner connections.
Book a free 90-minute scoping session · Request a scoped proposal