Security issues with FinTech APIs and integrations

This post is a continuation of my last blog post on crypto startups’ front-end security. After my post on common security issues with crypto website and APIs, I had the opportunity to work with more crypto and fintech startups.


Most fintech and crypto startups rely on third-party integrations. Looks like most of these integrations happen without verifying security practices of each other.

I’ll try to make a small list of issues I found multiple times during my recent security audits.


Negative amounts and zero checkout validation: Though it might seem like common sense to validate a transaction against negative amounts and zero, you would be amazed how many developers are missing on this.


Here’s an example of a negative balance checkout:

I was able to change crypto borrowing percentage rate to negative in another audit.

In one case, the ‘amount’ parameter was transferred in the GET request from the client’s website to the payment gateway without validation. The URL looked like this:

[testmerchant].com/category/[product]/bike/128?amount=10000

Insecure storage of customer’s KYC data:

KYC stands for Know Your Customer and most fintech and crypto startups have to collect government issued IDs from customers for regulatory purposes.

In one audit, I came across the insecure storage of KYC data in the S3 bucket. The URL looked like this:

https://s3.ap-south-1.amazonaws.com/%5Bwebsitename%5D/dev/user/602/kyc/%5BID_type%5D/%5BID%5D.pdf

In the above URL, 602 looks like a user ID so I tried different numbers in auto-increment and was able to access KYC documents for different users.

All you need was one AWS S3 link for format and you could have the personal data of almost all users on the platform.


Changing restricted user settings:

Most platforms don’t allow users to change certain settings after KYC. For example, you can’t change your name, address after your KYC is done.

In the image below, most of these JSON fields in the response header were not part of the request header.
But you could add these fields in request body and modify those (‘KYCSkip’ changed from 0 to 1).

After submitting the request, profile (response field) gets updated.

An attacker can bypass restricted settings this way!


Insecure third-party integrations:

In one of my audits, a client had an integration with a card issuance service. The communication between client and service provider used to happen through a URL like this:

[serviceproviderURL].com/?auth_token=[xyz]&card_ID=[encrypted_card_number]

this URL itself looks insecure and on top of that these parameters(auth_token/card_id) are fixed parameters.

These links were used to change the PIN of the card with no ratelimit on this endpoint. Attackers can bruteforce the PIN number in this case (on mutiple cards if encryption/encoding is not strong).


Along with these issues, XSS, access control, IDOR are still very common in fintech APIs.


These days just securing yourself is not enough, you should also verify the security of every partner you are integrating with and make sure they follow best security practices.

That’s all for now, hope this short post was useful for you from the security perspective.

If you run a crypto or FinTech startup and looking for security audits – we should talk 🙂

Have questions, suggestion regarding this post – feel free to reach out on my Twitter.

P.S. Can’t name websites as per our working agreements!





Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s