BI SNAP API penetration test: a bank case study
A large Indonesian bank was about to open its payment services to four fintech partners through SNAP, Bank Indonesia’s national open API payment standard. An automated scan had reported no critical problems. Our manual test found a flaw that let a partner redirect a customer’s transfer to a different account.
What was the bank launching?
The bank was publishing 27 SNAP endpoints (the individual functions partners can call). They covered balance checks, transfers and virtual accounts, the reference numbers companies use to collect payments.
It had three weeks to complete its self-assessment for OJK (Indonesia’s Financial Services Authority) and Bank Indonesia, and to pass its partners’ due diligence. It also needed test evidence for its QSA, the qualified assessor who checks compliance with the PCI DSS card-data standard.
Why test by hand when the scan was clean?
SNAP sets strict rules for how partners prove who they are, sign their requests and obtain customer consent. Each bank builds those rules into its own systems, and implementations differ. A scanner checks each function on its own. It rarely notices when a request that looks valid is doing something it should not be allowed to do.
What did the testers do?
We started with a 90-minute scoping workshop with the bank’s engineers. We walked through how partners sign in, how each request is signed and time-stamped, and how customer consent is recorded.
We then tested all 27 endpoints and the four partner test environments. We acted as a partner and tried to reach accounts, data and functions that partner should not have. We also reviewed the certificates and key storage that protect the connection. The work followed the OWASP API Security Top 10 and the OWASP Web Security Testing Guide, and was carried out by CREST-certified testers.
What did they find?
The critical issue sat in the transfer function. It checked that the partner’s access token was valid, but not that the account in the request belonged to the customer who had given consent. By changing the account number in transfer, a partner could send funds to an account it controlled. Testers call this broken object-level authorization, or BOLA. It came from chaining two issues that each looked minor on their own, and we supplied a working proof.
A high-severity issue allowed request replay. The SNAP X-SIGNATURE stayed valid for a period, requests carried no one-time value (a nonce) and the server tolerated clock differences. A captured transfer request could therefore be sent again and processed a second time.
A medium issue let one partner download another partner’s settlement report from the admin settlementReport endpoint. Testers call this broken function-level authorization (BFLA).
We reported 18 findings: 1 critical chain, 2 high, 6 medium and 9 low. Each was ranked by CVSS score and how easily it could be exploited. A short board narrative explained the regulatory and fraud impact.
What happened next?
The bank shipped fixes in four days, and our retest confirmed they worked. The QSA and OJK accepted the evidence, and partner onboarding went ahead as planned. The bank now runs automated penetration testing on every SNAP release. It also shares the report with fintech partners during their due diligence.
The technical scope also included mass assignment, IDOR, rate limiting, consent bypass, certificate pinning and log leakage. Findings were mapped to the OWASP API Top 10, OWASP ASVS 4.0, PCI DSS 4.0 Requirements 6.2 and 11.3, and ISO/IEC 27001 A.8. The report was delivered within 10 days of testing.
What should other banks take from this?
A clean scan of an API is a useful starting point, but it cannot tell you whether one partner can act on another customer’s account. If you publish SNAP or other partner APIs, ask your testers to work through the full sign-in and consent flow as a partner would. We can scope that with you.