Financial services security assessment: what automated scanning misses
Amara OkaforApril 29, 2026
Key takeaways
Financial services security assessments consistently find exploitable authentication flaws on API endpoints that pass automated scanning, because scanners test whether authentication is present, not whether it enforces the correct scope and privilege boundaries.
JWT algorithm confusion is the most reliable manual finding in fintech API assessments: servers configured to accept both RS256 and HS256 allow an attacker to forge tokens by signing with the public key as a symmetric secret. Scanners do not test this because it requires understanding token structure, not just presence.
Step-up authentication in financial applications is routinely enforced at the UI layer and absent at the API layer. An attacker who sends a direct request to the high-value transaction endpoint bypasses step-up entirely. This is the most commonly missed authentication gap in banking application assessments.
Open Banking API implementations routinely expose internal account endpoints through the same base URL structure as customer-facing APIs, with scope validation that covers the documented endpoints but not the undocumented ones visible through JavaScript source analysis.
Race conditions in payment processing flows produce double-spend windows between 120 and 600 milliseconds in assessed environments. Sequential penetration testing never hits this window. The finding requires concurrent request tooling and knowledge of which endpoints share state.
The gap between what a financial services compliance audit accepts as evidence and what an attacker can actually exploit is widest at the API authentication layer. Passing PCI DSS or SOC 2 does not require demonstrating that scope validation holds across all API surfaces.
TL;DR
Financial services security assessments that rely primarily on automated scanning produce findings lists that satisfy compliance requirements and miss the authentication and authorization flaws that attackers actually exploit. The gap is structural: scanners verify that controls are present, not that they hold under conditions an attacker creates. Manual assessment of API authentication flows, token validation, and concurrent request behavior closes the findings that automated tooling cannot see and that financial sector threat actors reliably target.
The authentication flow the scanner passed and the tester broke
A payments fintech had completed a penetration test six months before engaging for a vulnerability assessment. Clean report on authentication. The application used JWTs with RS256 signing for its customer API. The assessment team spent 20 minutes on the token validation endpoint before finding the issue: the server also accepted HS256. Sent a token signed with the RS256 public key as a symmetric HS256 secret. Server accepted it. The attacker could forge any token for any account with no knowledge of the private key. The public key was available in the JWKS endpoint, as it is supposed to be. The penetration test had verified that authentication was required. It had not verified that the token validation rejected algorithm substitution.
Algorithm confusion attacks against JWT implementations are documented. They appear in OWASP guidance. They require a tester who understands JWT structure and sends requests that deviate from what the application expects to receive, not requests that deviate from what the scanner knows to look for. The scanner had seen a JWT. It had authenticated. Test passed.
Why automated scanning passes the authentication flaws that matter
Automated scanners test for the presence of authentication controls and for common injection patterns. They authenticate to the application, confirm that unauthenticated requests are rejected, and move on. They do not test whether the authentication control enforces the correct privilege boundaries, whether token validation rejects algorithmically manipulated inputs, or whether authentication that is enforced in the UI is also enforced at the underlying API endpoint. These are behavioral questions that require an understanding of how the application is supposed to work, which is context the scanner does not have.
Example
An open banking application implements OAuth 2.0 with scopes: accounts:read, payments:initiate, and admin:internal. The scanner authenticates with a test account that has accounts:read scope. It confirms that unauthenticated requests are rejected and that endpoints requiring authentication return 401 without a token. What it does not test: whether the admin:internal endpoints are actually enforcing scope validation, or whether they accept any valid token regardless of scope. In three separate open banking assessments, the admin endpoints were reachable with customer-scoped tokens because scope validation was implemented at the API gateway for the documented endpoints and was absent on the internal endpoints that had been added directly to the backend service.
The underlying pattern is trust boundary mismatch between the API gateway and the backend service. The gateway enforces scope on routes it knows about. The backend service exposes routes the gateway does not proxy. An attacker who sends requests directly to the backend service URL bypasses the gateway entirely. This is not a configuration error in the scanner. It is a finding class that requires knowing to look for routes that exist in the backend but are absent from the gateway routing table.
What hands-on financial services assessment actually finds
Assessment base: Vulnox vulnerability assessment data, 2024, across payments fintech, open banking, and consumer lending environments
JWT algorithm confusion in payment and lending APIs
In fintech API assessments, servers accepting both asymmetric (RS256, ES256) and symmetric (HS256) JWT algorithms are a consistent finding. The exploitation path: retrieve the RS256 public key from the JWKS endpoint, construct a token signed with that public key as a symmetric HS256 secret, submit to the server. Servers that do not pin the expected algorithm accept the token as valid. The finding allows complete authentication bypass for any account without access to the private signing key. Every assessed server that exhibited this behavior had passed automated penetration testing.
The JWKS endpoint is public by design. The public key is not secret. Organizations that assume their JWT implementation is secure because authentication is required have not verified the algorithm validation logic. The scanner confirms tokens are required. It does not forge them.
Step-up authentication enforced at the UI layer only
Banking and payments applications that implement step-up authentication for high-value transactions routinely enforce it through frontend routing logic: the UI checks the transaction amount, presents the additional authentication challenge, and then proceeds. The API endpoint that processes the transaction does not independently verify that step-up authentication was completed. An attacker who sends a direct POST to the transaction endpoint with a valid session token from the lower-assurance authentication flow completes the high-value transaction without step-up. In assessed environments, this was the most consistent gap between what the compliance documentation described and what the API layer actually enforced.
Compliance auditors review authentication documentation and test through the UI. They confirm that step-up is triggered for qualifying transactions. They do not test whether the underlying API endpoint enforces step-up independently of the UI flow. The gap between the documented control and the implemented control is invisible to audit and to automated scanning.
Race conditions in payment processing with exploitable windows
Concurrent request submission against payment endpoints that read and write shared balance state produced exploitable race windows in assessed fintech environments. The window ranged from 120 milliseconds at the short end to over 600 milliseconds in environments with database-level locking absent or implemented inconsistently across service replicas. The exploitation requires sending 8 to 20 concurrent requests within the window. Sequential penetration testing, which sends requests one at a time and waits for responses, never reaches the race condition. The finding requires concurrent request tooling and knowledge of which endpoint pairs share state.
Payment systems that implement idempotency keys at the API layer but not at the database transaction layer are vulnerable to race exploitation that bypasses the idempotency mechanism. The idempotency key prevents duplicate requests from the same client session. It does not prevent concurrent requests from different sessions targeting the same account. This is a design-level gap that compliance frameworks do not specifically test for.
Mobile API endpoints with weaker authentication than web API counterparts
In assessments of fintech applications with both web and mobile frontends, the mobile API endpoints consistently exhibited weaker authentication enforcement than the web API. The pattern: mobile API authentication was implemented separately, often earlier in the development timeline, and had not been updated to match subsequent web API hardening. Certificate pinning bypass in the mobile application exposed API responses that revealed endpoint structures not present in web API documentation. Several mobile-specific endpoints accepted authentication tokens from the web API without mobile-specific validation, allowing session portability that was not intended.
Security reviews of financial applications that focus on the web interface miss the mobile API surface. The mobile endpoints are not hidden; they appear in traffic capture once certificate pinning is bypassed. They are simply not in scope for most assessment engagements because the scope was defined around the web application.
The authentication control that makes exploitation easier
Common belief
Multi-factor authentication is the most reliable defense against unauthorized account access in financial applications. Organizations that implement MFA across all authentication flows have addressed the primary authentication risk.
What we found
In one lending platform assessment, the application enforced MFA on all login flows. The assessment team created a borrower account, completed MFA, obtained a valid JWT, and then modified the account ID parameter in the loan retrieval endpoint. The server returned loan details for other borrowers. The MFA requirement was real. The authorization enforcement on the data retrieval endpoint was absent. The security documentation listed MFA as a primary control. It was not the control that mattered for this attack path.
MFA protects the authentication step. It does not protect the API endpoints that are accessible once a valid session is established. In financial applications with complex API surfaces, the more important question is not whether the attacker can authenticate, but what they can do once they have any valid session token. An attacker who creates a free account, authenticates legitimately, and then manipulates their token or traverses the API surface with their valid token has bypassed MFA entirely, because they completed MFA to get the token they are now misusing. The authentication strength at login does not determine the authorization enforcement on every subsequent API call.
Where financial services assessments consistently miss findings
Internal API endpoints exposed through the same base URL
Open banking and payments platforms frequently have internal service endpoints accessible under the same domain as customer-facing APIs. These endpoints were added directly to the backend service and are not routed through the API gateway that enforces authentication and scope validation. They are not in API documentation. They appear in JavaScript source bundles, mobile application traffic captures, and occasionally in error responses that reveal internal service URLs. Assessments scoped to the documented API surface miss them entirely.
Webhook signature validation absent or bypassable
Fintech applications that receive payment event webhooks from processors implement signature validation to confirm the webhook origin. In assessed environments, webhook signature validation was frequently present for the production processor endpoint and absent for a test or sandbox endpoint that remained active in production configuration. An attacker who can send requests to the sandbox webhook endpoint can trigger payment completion events without a valid processor signature.
Token refresh endpoints with weaker validation than initial authentication
JWT refresh flows in financial APIs frequently enforce MFA and strong validation on the initial authentication endpoint and apply significantly weaker validation on the token refresh endpoint. The refresh endpoint accepts the refresh token without re-validating the device fingerprint, IP range restrictions, or fraud scoring that applied at initial login. Attackers who obtain a refresh token through phishing or credential theft can maintain session access indefinitely without triggering re-authentication controls.
Partner and third-party integration endpoints with elevated privileges
Financial institutions that expose integration APIs to partners or aggregators implement those endpoints with elevated privileges to support partner use cases. The partner authentication is typically API key-based. API key rotation policies are weaker than user credential policies. Partner endpoints sometimes expose account-level data or transaction capabilities that are not available through the customer-facing API. Assessments that do not include partner API surfaces miss the highest-privilege endpoints in the environment.
What fintech and banking assessments require differently
Fintech and neobank environments
API-first architecture means the entire attack surface is the API. Mobile application is the primary client, requiring certificate pinning bypass as a prerequisite for API surface mapping. Rapid deployment cycles produce authentication drift between services. Third-party integrations (payment processors, KYC providers, fraud scoring) introduce trust boundaries that are rarely assessed. OAuth 2.0 and OIDC implementations vary in quality across services built by different teams at different times.
Assessment scope must explicitly include mobile API traffic capture, OAuth scope validation testing, and partner integration endpoints. Defining scope around the web application or the documented API surface will miss the highest-risk findings in a fintech environment.
Traditional banking and legacy financial infrastructure
Legacy systems often run authentication mechanisms that predate modern token standards. Core banking APIs may use session-based authentication with predictable session identifiers. The attack surface includes integration points between legacy core systems and newer digital banking frontends, where authentication model mismatches create privilege escalation paths. Audit trails exist but are often not monitored for behavioral anomalies.
Assessment scope must include the integration layer between legacy core systems and digital frontends. The most exploitable findings in traditional banking assessments are at this boundary, where authentication models do not align and trust assumptions are inconsistent.
Where financial services attack surface is heading
Open Banking API mandates will produce a measurable wave of authorization bypass findings within 18 months as financial institutions expose standardized API surfaces that their internal authorization models were not designed to protect at scale.
Regulatory open banking mandates (EU PSD2, UK Open Banking, various APAC equivalents) require financial institutions to expose APIs to third-party providers. The authorization models governing who can access which data through these APIs are implemented by institutions whose internal systems were built for direct customer access, not for delegated third-party access with fine-grained scope enforcement. The gap between the regulatory requirement and the implementation reality is already visible in assessment data and will produce publicly attributable incidents within the forecast window.
Confidence: highNo publicly attributable open banking authorization bypass incident affecting account data or payment initiation by end of 2026.AI-assisted transaction fraud detection will create a new class of adversarial input attack specific to financial services, where attackers craft transaction sequences designed to train fraud models toward false negative classification. This will not be widely named or documented before the first confirmed exploitation.
Fraud detection models in financial services are trained on historical transaction data. Attackers who can send transactions that are processed and settled before being flagged can influence the training distribution over time. The attack is slow, does not require exploiting a code vulnerability, and produces no observable signal until the model's false negative rate has shifted enough to be detectable through outcome analysis. The preconditions exist now in every financial institution using online learning fraud models.
Confidence: mediumNo documented adversarial input attack against a financial services fraud detection model by end of 2027.
Why financial services security assessments stay shallow
Financial services security assessments are scoped to pass compliance requirements, not to find what attackers exploit. PCI DSS requires penetration testing. SOC 2 Type II requires evidence of security testing. Neither requires that the testing methodology include JWT algorithm confusion, step-up authentication bypass at the API layer, or concurrent request race condition testing on payment flows. Organizations commission assessments sized to produce the evidence their auditors will accept. Assessors produce reports sized to match the scope they were given. The result is a security assessment industry that is optimized for compliance artifact production and not for finding the API authentication flaws that financial threat actors reliably exploit. This is not anyone's fault individually. It is the structural outcome of scoping security work to regulatory minimums.
Counterargument
The counterargument is that financial institutions face real resource constraints and must prioritize. Scoping assessments to compliance requirements ensures the highest-priority regulatory obligations are met. That is reasonable for institutions that are not yet meeting baseline compliance requirements. For institutions that are PCI DSS certified and SOC 2 attested, the compliance baseline is already satisfied. The question is what the additional risk surface looks like beyond the compliance perimeter, and the answer is consistently: authentication and authorization flaws that the compliance-scoped assessment was not designed to find.
One test for this week
Take any JWT used in your financial application and decode the header. Note the algorithm. Then send the same request with a modified token where the algorithm field has been changed from RS256 to HS256 and the token has been re-signed using your RS256 public key as a symmetric secret. If the server returns a valid response, you have a JWT algorithm confusion vulnerability that your last penetration test almost certainly did not test for. The public key needed to forge the token is available in your JWKS endpoint. This is a 15-minute test that produces a critical finding in a meaningful percentage of financial API environments.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
vulnerability assessment servicesWhat is SOC 2 Compliance
SOC 2 compliance frameworkPCI Security Standards Council
PCI DSS standardsNIST Vulnerability Assessment Definition
NIST vulnerability assessment definition
Frequently Asked Questions
What does a financial services security assessment find that automated scanning misses?
Automated scanning confirms authentication is present but does not test whether authorization holds across all API surfaces. Manual financial services security assessment finds JWT algorithm confusion vulnerabilities, step-up authentication enforced only in the UI and absent at the API layer, race conditions in payment flows requiring concurrent request tooling, and internal API endpoints accessible through the same base URL but outside the API gateway scope.
What is JWT algorithm confusion and how does it affect fintech API security?
JWT algorithm confusion occurs when a server accepts both asymmetric (RS256) and symmetric (HS256) JWT signing algorithms. An attacker retrieves the public key from the JWKS endpoint, then forges a token signed with that public key as a symmetric HS256 secret. Servers that do not pin the expected algorithm accept the forged token as valid, allowing complete authentication bypass for any account. This is a consistent finding in fintech API assessments that passes automated penetration testing.
How does step-up authentication fail in banking application security assessments?
Step-up authentication in banking applications is frequently enforced through frontend routing logic but not at the underlying API endpoint. The UI detects high-value transactions, presents the additional authentication challenge, and then calls the API. An attacker who sends a direct POST to the transaction API endpoint with a valid standard-assurance session token bypasses step-up entirely, because the API does not independently verify that step-up was completed. This is the most consistent gap between documented controls and implemented enforcement in banking application assessments.
What race condition vulnerabilities appear in payment API security testing?
Payment endpoints that read and write shared balance state without atomic database-level locking produce race windows between 120 and 600 milliseconds. An attacker sends 8 to 20 concurrent requests within this window, producing double-spend or duplicate transaction outcomes. Sequential penetration testing never hits this window. Idempotency keys implemented at the API layer but not the database transaction layer do not prevent this, because the keys block duplicate requests from the same session, not concurrent requests from different sessions.
How do fintech and banking security assessments differ in scope and methodology?
Fintech assessments require mobile API surface mapping through certificate pinning bypass as a prerequisite, OAuth scope validation testing across all endpoints including undocumented ones, and partner integration API coverage. Banking assessments require focus on the integration boundary between legacy core systems and digital frontends, where authentication model mismatches produce privilege escalation paths. Both require manual API authentication testing that automated scanning does not perform.
What are the most commonly missed findings in financial services API security testing?
Internal API endpoints exposed under the same base URL but outside the API gateway routing table. Webhook signature validation absent on sandbox or test endpoints that remain active in production. Token refresh flows with weaker validation than initial authentication. Partner integration endpoints with elevated privileges and weaker API key rotation policies than user credential policies. All of these appear in assessment data and are outside the scope of compliance-minimum penetration testing.
Does passing PCI DSS penetration testing mean financial API authentication is secure?
No. PCI DSS penetration testing requirements do not specify that testing must include JWT algorithm confusion, step-up authentication bypass at the API layer, concurrent request race condition testing, or OAuth scope validation across undocumented endpoints. Assessors produce reports matching the scope they are given, which is typically sized to the compliance minimum. Financial institutions with PCI DSS certification regularly carry exploitable API authentication flaws that their compliance-scoped assessments were not designed to find.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.