FinTech
Series B fintech, $2B+ annual transaction volume
94%
of critical vulnerabilities eliminated
47
findings identified across the API surface
60 days
from findings to remediation
The Challenge
The client is a rapidly growing Series B fintech company processing over $2 billion in annual transactions through a modern API-driven payment platform. With a product team shipping code multiple times per day across RESTful payment APIs, a consumer-facing mobile app, and a merchant dashboard, engineering velocity had far outpaced the organization's security practices.
During a routine due diligence review initiated by a prospective institutional investor, several surface-level security concerns were flagged. The company had never undergone a formal penetration test, and internal security capability was limited to a single security engineer focused primarily on infrastructure compliance. The API ecosystem had grown to over 200 endpoints without consistent authentication patterns, input validation standards, or access control enforcement.
Leadership recognized the urgency: a single breach of the payment infrastructure could trigger regulatory action under PCI DSS, loss of merchant confidence, and potentially catastrophic reputational damage. They needed a thorough, adversarial assessment of the entire attack surface before the investor's security review.
The Approach
I designed a multi-phase engagement combining black-box external testing with grey-box internal assessments, to maximize coverage while simulating both external attacker and authenticated adversary scenarios.
Phase 1: Reconnaissance and Attack Surface Mapping
I began with comprehensive external reconnaissance: enumerating all publicly accessible API endpoints, subdomains, and third-party integrations, mapping the full OAuth 2.0 and JWT authentication flows, identifying API versioning patterns, and cataloguing mobile application network traffic using intercepting proxies.
Phase 2: Black-Box Penetration Testing
Starting from an unauthenticated perspective, I attempted to bypass authentication mechanisms, escalate privileges, and access data belonging to other merchants and consumers, focusing on the payment processing APIs, the merchant onboarding flow, and the mobile app's local data storage.
Phase 3: Grey-Box API Deep Dive
With access to API documentation, source code for two critical microservices, and test merchant credentials, I conducted a methodical review of business logic, authorization enforcement, and data handling across the transaction lifecycle, including race conditions in payment processing, amount manipulation, and currency conversion edge cases.
Phase 4: Remediation Support
Rather than delivering a static report and walking away, I embedded with the client's engineering team for two weeks of guided remediation: code review support, validation testing for each fix, and architectural recommendations to prevent similar issues in the future.
Key Findings
Over the course of the engagement I identified 47 security findings, of which 12 were rated critical and 15 rated high severity. The most impactful discoveries:
Insecure Direct Object References (IDOR) in Account APIs
The account management API used sequential integer IDs in URL parameters without server-side authorization checks. By simply incrementing account ID values, an attacker could enumerate and access the full profile data of any user on the platform, including KYC documents, bank account details, and transaction history. This single vulnerability affected over 800,000 user accounts.
Broken Authentication on Admin Endpoints
The internal merchant administration portal exposed API endpoints that accepted requests with expired or invalid JWT tokens. Token validation middleware had been accidentally bypassed during a recent microservice migration, leaving endpoints for merchant account suspension, refund approval, and fee configuration accessible to anyone who could guess or brute-force the endpoint paths.
SQL Injection in Transaction Search
The transaction search API, processing thousands of queries per minute from the merchant dashboard, was vulnerable to blind SQL injection through the date range filter parameter. An attacker could extract the full contents of the production database, including payment card data token references, user credentials, and internal API keys stored in a configuration table.
Excessive Data Exposure in Mobile API Responses
The mobile app's API responses returned significantly more data than the UI displayed, including internal fraud scoring values, raw processor response codes, and other merchants' aggregated transaction volumes: information leakage that could provide competitive intelligence and reveal internal risk assessment models.
Solution and Remediation
I worked directly with the client's engineering leadership to prioritize remediation based on exploitability and business impact. Critical and high-severity findings were addressed in weekly sprints with real-time validation.
- Implemented UUID-based resource identifiers with mandatory server-side authorization checks on every API endpoint, eliminating the entire class of IDOR vulnerabilities.
- Deployed a centralized API gateway with standardized JWT validation, rate limiting, and request schema enforcement across all microservices.
- Refactored database queries to use parameterized statements and established a secure coding standard requiring ORM usage for all new database interactions.
- Introduced response filtering at the API gateway layer so mobile and web clients receive only the fields required for their specific use case.
- Established a continuous API security testing pipeline integrated into the CI/CD workflow, catching regressions before they reach production.
Results
Within 60 days of the initial engagement, the client had resolved 94% of all critical vulnerabilities and implemented architectural changes that dramatically reduced ongoing attack surface. The remaining findings were lower-severity items scheduled for the following development cycle.
Kishin didn't just find problems: working with them made our engineering team fundamentally better at security. Six months later, we're catching issues in code review that would have reached production before. Our investors were impressed, and we closed our funding round with security as a strength rather than a liability.
The client passed their investor security review, maintained PCI DSS compliance throughout the process, and established a sustainable application security program that continues to mature. Their engineering team now includes security champions in every squad, and I run quarterly penetration tests to validate ongoing improvements.